ビットマップの背景画像には、どの画面サイズ/密度の組み合わせをサポートする必要がありますか？

Question

私はいくつかのフルスクリーンビットマップの背景が必要なアプリケーションを書いています。 AndroidのマニュアルでSupporting Multiple Screensの私の素朴な読書に基づいて、私はおそらく各ビットマップの16バージョンを持っている必要があります：[ small, normal, large, xlarge ]と[ ldpi, mdpi, hdpi, xhdpi ]のすべてのペアをカバーするために。これにより、画像を拡大するためにCPUが行う作業が削減されますが、大きなストレージコストがかかることになります。

しかし、これは、2つの理由のために乱暴に非効率です：

1. これらの組み合わせの全てが実際に発見されていません。
2. 私は、物理的なサイズ（DPIを考慮しない）ごとにベクトルアートをレンダリングしているので、large/mdpiとnormal/hdpi（どちらも〜480x854ピクセル）のペアは重複ファイルです。

本当に大きな画像を提供して、システムのスケールを下げればいいですか？弾丸に噛み付き、重複した画像をたくさん提供しますか？問題をまったく避けて、生のリソースを持つコードソリューションを手に入れてください。他のアイデア？ありがとう。

EDIT：明らかに実際のビットマップのエイリアスとなるXMLビットマップドロワブルを作成できます。それは2番目の非効率的な議論を解決します。それでも、他の人たちが実際にどのような組み合わせを提供しているのでしょうか？

Answer 1

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

アプリケーションのサイズが大きくなりすぎると考えられる場合は（可能な限りすべての画像サイズを追加するなど）、アプリケーションをSDカードに移動することもできます。そうすれば、ストレージはもはや大きな問題にはなりません。 （http://developer.android.com/guide/appendix/install-location.html）

Answer 2

表示される画面のdpiにかかわらず、アートのサイズを一定にしたい場合は、異なる解像度でイメージを提供します。アイコンやボタンがこの例です。

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

4つの画面サイズのカテゴリでは、大きいサイズ（xlargeまたはlarge）のうちの1つを保存し、必要に応じてフレームワークで拡大または縮小することができます。また、スケーリングをプログラムで実行して、背景のアスペクト比を変更しないで、切り抜かないようにすることもできます。

Android game working on all screen sizesも参照してください。より良い回答が得られることを願っています。