重複の可能性:
さまざまな密度に複数のドローアブルを提供するのはなぜですか?
常にフルスクリーンに合うように拡大縮小されたスプラッシュスクリーンがあるとしましょう。同じ画像の4つの異なる密度バージョンをパッケージ化することは意味がありますか?Androidにダウンスケーリングを処理させてみませんか?
もう1つの例は、ボタンアイコンです。パッケージ化だけxhdpi
でAndroidに作業を任せてみませんか?それはメモリの問題ですか?
重複の可能性:
さまざまな密度に複数のドローアブルを提供するのはなぜですか?
常にフルスクリーンに合うように拡大縮小されたスプラッシュスクリーンがあるとしましょう。同じ画像の4つの異なる密度バージョンをパッケージ化することは意味がありますか?Androidにダウンスケーリングを処理させてみませんか?
もう1つの例は、ボタンアイコンです。パッケージ化だけxhdpi
でAndroidに作業を任せてみませんか?それはメモリの問題ですか?
同じ画像の4つの異なる密度バージョンをパッケージ化することは意味がありますか?Androidにダウンスケーリングを処理させてみませんか?
それは、ダウンスケーリングの結果が好きかどうかによって異なります。もしそうなら、それを使用してください。そうでない場合は、それを必要とする密度に合わせて他のアートワークを提供してください。
それはメモリの問題ですか?
部分的には、ダウンサンプリングにはCPU時間がかかるため(したがって、バッテリーが少し増えるため)、速度の問題が発生します。
部分的には、Androidが行うダウンサンプリングは、画像がどのように見えるかを最終的に制御できないことを意味するため、品質の問題です。画像のダウンサンプリングに満足しているかもしれません。他の開発者は、画像のダウンサンプリングに満足していない可能性があります。
たとえば、Nexus7は-tvdpi
デバイスです。ただし、Googleは画像を気にしません-tvdpi
。Androidに画像をダウンサンプリングさせ-xhdpi
ます。画像は私には完全に合理的であり、Googleにとっても明らかに合理的です。OTOH、Googleは、デバイス用だけでなく、のダウンサンプリングの基礎として機能する-mdpi
画像を出荷しています。-mdpi
-ldpi