私のアプリは、ldpi から xhdpi までのさまざまな画面密度をサポートしています。すべての密度で適切に表示する必要があるいくつかのドローアブル (画像) が含まれています。Androidランタイムが適切な密度のリソースを見つけられないときにリソースをスケーリングしていることを考えると、ドローアブルのさまざまな解像度を実際に提供する必要があるかどうか疑問に思っています。
mdpi ドローアブルのみを提供する場合、それらは hdpi/xhdpi (ぼやけた) 上で拡大され、ldpi 画面上で縮小されます。
ただし、xhdi リソースのみを提供すると、すべての低密度画面で縮小されます。縮小してもぼやけず、きれいに見えます。
では、なぜわざわざ xhdpi 以外の密度のドローアブルを提供するのでしょうか?
事前にスケーリングされたドローアブルを使用する理由はいくつかあります。
低解像度にスケールダウンすると、リソース（CPU時間、メモリ、バッテリーの消耗が早くなります）が必要になります。特に、画像が多い場合は、これは望ましくない場合があります。
大きな画像を縮小すると、「事前調整された」小さな画像を使用するよりも品質が低下する可能性があります。特に、画像がベクターオリジナルに基づいている場合。または、非常に細い線や詳細が含まれているため、スケーリングが原因で失われます。
例：これらの画像のソースとスケーリングアーティファクトの詳細については、こちらを
参照し
てください。
低解像度では、画像のピクセルが大きくなる（または画像が小さくなる）ため、画像を鮮明/わかりやすくするために、画像の特定の側面を削除する必要がある場合があります。
リソースのスケーリングに関するあなたの仮定は正しくありません。一部の大きな画像は、縮小しても見栄えがよい場合がありますが、これは一般的なケースではありません。画像の遷移がスムーズでグラデーションがない場合は、適切に縮小されます。たとえば、シャープなトランジションを含む画像やテキストを含む画像は、低解像度では見苦しくなります。
自分でスケールダウンを行うと、自動スケーリングに比べて結果が良くなる可能性があります。さらに、ドローアブルが準備されている場合、アプリはスケーリングのためのリソースを消費しません。
必須ではありませんが、たとえば、さまざまな画面解像度に対してさまざまなドローアブルでさまざまなレイアウトを使用できます。あなたにはそれを行うオプションがあります。あなたとあなたのユーザーが結果に満足しているなら、クールです。異なる密度と解像度で異なる動作が必要な場合、この機能は非常に便利です。