XHDPIドローアブルをAndroid app？
近い将来にLDPI、MDPI、HPDI、およびおそらくXHDPIをサポートすることを計画している場合、プロジェクトにXHDPIドローアブルのみを含め、デバイスがそれらを目的の解像度にスケーリングできるようにしてもよいですか？
PhotoshopでドローアブルをMDPIとHDPIにサイズ変更するためにテストし、結果をAndroidでのみサイズ変更されたXHDPIドローアブルと比較したところ、まったく違いがわかりません。このショートカットを取るのは悪いデザインですか？すべてのドローアブルを3つの異なる解像度にサイズ変更する必要がないのはいいことです。
ターゲットSDKの使用計画は2.1または2.2です。
BRエミール
それは良い方法だと思います。私が考えることができる唯一の欠点は、小規模デバイスでのリソースのオーバーヘッドと、ダウンスケーリングのために起こり得るアーティファクトです。実際、今年のGoogleでIO Chris Pruettは、高解像度のアセットのみを埋め込み、openglでスケーリングを処理することを推奨しました。
Android 1.6以降、XHDPIを含むさまざまな密度が処理されます（これは2.2まで正式に追加されませんでした）。アプリは最初にその密度に一致する画像を探しますが、より大きなものを調べることもできますXHDPIのような「バケット」を使用して、スケーリングを実行します。
サポートしたい密度の特定のアセットを含めるのが最善です。 100x100の画像は40kbかかります。 200x200の画像は160k（非圧縮）になります。そのため、MDPIデバイスで使用されるXHDPIアセットには必要なデータ量の4倍があり、アプリが起動してリソースが準備されたときに処理する必要があります。メモリ使用量が少ないほど、効率が高く、OutOfMemoryExceptionが発生する可能性が低くなります。
さらに、特定の種類の画像は、自動的に拡大縮小されると見栄えが悪くなります。特に、細い線や細かいパターンの画像は、細部がぼやけます。画像を手動で縮小する場合、ニーズに最も適したアルゴリズム（線形、双三次、ランチョスなど）を選択できます。
自分でサイズ変更を行うのにかかる時間を心配している場合は、バッチプロセスを組み込むか、Nine Patch Resizerなどのツールを使用できます。 http://code.google.com/p/9patch-resizer /
私はxhdpi画像のみを使用してシンプルなアプリ（Android 2.1用に開発）でテストしました。小、中、高解像度で正常に動作します... Android 2.1（小さな解像度）そしてそれは問題なく画像を開きます。
たぶん、記憶についてのことは真実なので、必要な誰かがこれをテストします。
私は個人的に、xhdpiフォルダーを使用するだけで多くのアプリで非常にうまく機能し、このアプローチの大きなサポーターであることを発見しました。メモリのオーバーヘッドは真実ですが、今日のデバイスでは無視できると思います。また、これが原因で速度が低下したことに気づかなかったため、ダウンスケーリング後にキャッシュが発生していると思います。フォルダーを1つだけ含めると、APKのサイズが劇的に減少する可能性があり、エンドユーザーはこれを高く評価します。一部の画像にはスケーリングのアーティファクト（細かいパターンなど）が発生することを覚えておく必要がありますが、私は自分のアプリで重大な問題に遭遇したことはありません。また、ボタンやその他のものについては、丸みを帯びたコーナーのアーティファクトを減らすために9パッチを必ず使用してください。このアプローチを使用することにより、画像サイズをわずかに減らすこともできます。 drawable-xhdpiはそれをサポートしていないバージョンでは単にdrawableと見なされるため、APIレベルは古いバージョンでは問題になりません。単純なドローアブルをxmlで定義する機会を無視しないでください。たとえば、形状だけでグラデーション背景を作成するのは非常に簡単で、これによりスペースを節約し、アーチファクトのスケーリングのリスクを冒しません。
Xhdpiリソースのみを使用しても問題ありません。ただし、xhdpiはapiレベル9（Gingerbread）で導入されたことに注意してください。つまり、APIレベル<= 8をターゲットにする場合、少なくともhdpiリソースも必要です。
XHDPIは、Android SDK APIレベル9（ジンジャーブレッド）でのみ導入されました（ http://developer.Android.com/reference/Android/util/DisplayMetrics.html#DENSITY_XHIGH）を参照 ）したがって、9未満の最小SDKレベルを計画している場合は、少なくともHDPIドローアブルも提供する必要があります。そうしないと、Froyo以下のデバイスでは何も表示されません。
更新：Gingerbreadより前のバージョンではxhdpi画像が表示されるようです。 https://groups.google.com/d/msg/Android-developers/yjYO91OmoJ4/v3he0ZbKo-UJ
余分なメモリ使用量に関するこのステートメントは間違っています。
XHDPIサイズのドローアブルをMDPIフォルダ内に配置すると、メモリの問題が発生します。
ただし、XHDPIフォルダー内にXHDPIドローアブルを提供すると、Androidは画像の一部をスキップして画像をダウンサンプリングするため、追加のメモリは使用されません。
このskippingは、見栄えをよくするために、サポートする予定のすべての密度に対してドローアブルを提供する必要がある理由です。
一方、ダウンサンプリングした場合、特定の画像だけが見栄えが悪くなります（ほとんどが小さいアイコン）。画像に十分なデータが捨てられる限り、問題はありません。または、グリッドがドローアブルとして使用されている場合は、Imagneになる可能性があります。そのため、潜在的に一部のグリッド線が捨てられ、画像が悪く見える場合があります。
結局のところ、さまざまなデバイスを試してみることをお勧めします。そうすれば、密度のためにどのリソースが代替リソースを必要とするかを判断できます。