2

画面のサイズに合わせて拡大縮小する必要がある画像があります。画像には、第 2 言語に翻訳する必要があるテキストも含まれます。したがって、開始する各イメージには 2 つのバージョンがあり、言語ごとに 1 つです。

Google では、密度ごとに画像リソースを用意することをお勧めしています。そこで、2 つの画像を取り、xhdpi、hdpi、mdpi、ldpi の 4 倍にします。しかし、その後、Google は、画面サイズごとに異なる画像リソースを持つように言っています。これにより、画像が再び 4 倍になります: xlarge、large、normal、small です。すべての画像を 32 枚も作成したくありません。

特大画面と xhdpi 密度のみの画像を作成することに問題があるかどうか疑問に思っています。IE – 最高品質。Android の dp 単位の基準に従って、密度を下げるために画像を縮小します。小さな画面に描画するときは、Canvas クラスを使用してさらに縮小できます。結果として得られるスケーリングされた Bitmap オブジェクトをキャッシュして、ビットマップを再描画する必要があるたびに使用できるようにすることで、コストのかかるスケーリング計算が何度も実行されるのを回避できます。

これを行うことに欠点はありますか?または、同じ画像のコピーを何度も作成しないようにするためのより良い方法はありますか?

4

2 に答える 2

0

小さい (ローエンドの) デバイスで大きな画像を縮小すると、パフォーマンスが低下します。これが目立つかどうかは、表示する必要がある画像の数によって異なります。
同じことは、必要な変更を加えて、記憶にも当てはまります。

于 2012-04-04T14:35:33.173 に答える
0

最高の xhdpi ピクセル密度のビットマップのみを作成し、他の画面タイプでテストします。

低密度の画面でビットマップが見栄えが悪い場合は、その密度専用に作り直します。そして、これはめったに起こりません...

また、さまざまな画面サイズ (小/特大) 用に特別なビットマップを作成する必要はありません。ImageView を小さく/大きくするだけです。画像のスケーリングは低速な操作ではないため、ほとんどの場合、心配する必要はありません。 (ビットマップが画面全体を覆っている場合を除きます)。

于 2012-04-04T14:50:25.173 に答える