Android デバイスの UI を設計する際に、どちらがより良い戦略であるかについて、あなたの考えはどうなっているのか疑問に思っています。
どちらが好きですか:
必要に応じて縮小される 1 セットの画像 (xxhdpi 画像) のみを使用して、各密度 (および必要に応じてサイズ) に対して XML ファイル内の要素のサイズを設定します。
長所 - アプリが小さい (リソースが少ない) UI 担当者の画像に関する作業が少なくなります。
短所 - XML ファイルでの作業が増える (場合によっては非常に多くなる)
ほとんどの場合、Wrap_content を使用して、各密度 (および必要に応じてサイズ) の画像を作成します。
長所 - XML レイアウト ファイルは 1 セットのみです。
短所 - より多くの画像とより大きなサイズの apk。UI担当者向けの画像に関する作業が増えました。
他にどのようなアプローチを使用していますか?
ありがとう！
あなたが提供していない画像をスケーリングするときに Android が何をしているのかを誤解していると思います。Android ドキュメントの状態:
デフォルトでは、Android はビットマップ ドローアブル (.png、.jpg、および .gif ファイル) と Nine-Patch ドローアブル (.9.png ファイル) をスケーリングして、各デバイスで適切な物理サイズでレンダリングします。たとえば、アプリケーションがベースラインの中程度の画面密度 (mdpi) に対してのみビットマップ ドローアブルを提供する場合、システムは高密度画面では拡大し、低密度画面では縮小します。このスケーリングにより、ビットマップにアーティファクトが発生する可能性があります。ビットマップが最高の状態で表示されるようにするには、画面密度ごとに異なる解像度の代替バージョンを含める必要があります。
これが意味することは、画像の代替密度バージョンを提供しない場合、Android は提供されたものを使用して不足しているもの (作成された正しい比例サイズ) を埋めますが、画像の品質がいくらか犠牲になるということです。 Android は、Photoshop のように画像を拡大縮小するつもりはありません。アプリケーションのサイズが気になる場合は、.apk を小さくするために、特定の密度のバージョンを省略することによる画質の低下が許容できるトレードオフであるかどうかを検討できます。
したがって、画像を元のサイズよりも大きくしたり小さくしたりする必要がない限り、#1 と #2 は両方とも を使用できwrap_content、どちらも画像のサイズを手動で設定する必要はありません (その場合は、右側に画像を作成するだけです)。サイズ）。＃1もレイアウト作業を必要とせず、必要としません。＃2については、画像をいくつかのサイズで保存することは、それほど余分な作業ではありません.
私は個人的に次のルールに従います。
ldpi/ tvdpi-デバイスが少なすぎることを除いて、画質が低下しても問題ありません）。wrap_content必要に応じてとを画像に使用match_parentします。dpサイズが保証されない、実行時にダウンロードされるイメージにのみ使用します。私の選択は混合です。複雑で、自動圧縮に異常がある可能性があるものについては、別のイメージを作成します。しかし、通常の画像では、最初のアプローチのみを使用しました。