3

多数のフルスクリーン ビットマップ背景が必要なアプリケーションを作成しています。Android ドキュメントのSupporting Multiple Screens[ small, normal, large, xlarge ]を単純に読んだことに基づいて、すべてのベースをカバーするには、おそらく各ビットマップの 16 バージョンが必要[ ldpi, mdpi, hdpi, xhdpi ]です。これにより、CPU が画像をスケーリングするために必要な作業を減らすことができますが、ストレージ コストが大きくなります。

ただし、これは次の 2 つの理由から非常に非効率的です。

  1. これらの組み合わせのすべてが実際に見られるわけではありません。
  2. 各物理サイズ (DPI を考慮せずに) のベクター アートをレンダリングしているだけなので、large/mdpi と normal/hdpi (どちらも ~ 480x854 ピクセル) のようなペアは重複ファイルです。

では、本当に大きな画像を提供して、システムに縮小させるべきでしょうか? 弾丸を噛んで、多くの重複画像を提供しますか? 問題を完全に回避し、未加工のリソースを使用してコード ソリューションを石畳にしますか? 他のアイデアはありますか？ありがとう。

編集:どうやら、実際のビットマップをエイリアス化する XML ビットマップ ドローアブルを作成できるようです。これにより、2 番目の非効率性に関する議論が解決されます。それでも、他の人が実際にこれらのどのような組み合わせを提供しているのだろうか?

4

2 に答える 2

0

表示される画面の dpi に関係なく、芸術作品を一定のサイズにしたい場合にのみ、異なる解像度の画像を提供します。アイコンやボタンがその例です。

ここで説明する背景画像の場合、画像の dpi が何であるかは気にしません。関心があるのは x * y の寸法だけです。したがって、サイズと dpi のクロス積を生成する必要はありません。4 つの画面サイズ カテゴリのみを考慮する必要があります。

また、4 つの画面サイズ カテゴリの中で、より大きなサイズ (xlarge または large) の 1 つだけを保存する必要があり、必要に応じてフレームワークがそれを拡大または縮小します。背景の縦横比を変更したりトリミングしたりしないように、プログラムでスケーリングを行うこともできます。

うまくいけばより良い答えを引き付けるすべての画面サイズで動作するAndroidゲームも参照してください。

于 2013-03-28T18:07:44.793 に答える
-1

ldpi、mdpi、hdpi、およびオプションで xhdpi のイメージを提供することをお勧めします (ターゲット ユーザーによって異なります)。これにより、最も一般的に使用される解像度を問題なくカバーできます。

(考えられるすべての画像サイズを追加するか、その他の理由で) アプリケーションが大きくなりすぎていると感じた場合は、アプリケーションを SD カードに移動できるようにすることも検討できます。そうすれば、ストレージはもう問題になりません。( http://developer.android.com/guide/appendix/install-location.html )

于 2011-03-22T15:32:37.170 に答える