0

毎回、ドローアブルフォルダにリソースを提供するとき、これが私がしたことです

drawable-xhdpi (96x96 px)
drawable-hdpi  (72x72 px)
drawable-mdpi  (48x48 px)
drawable-ldpi  (36x36 px)

ほとんどの場合、私はGIMPを使用して、からの最大サイズの画像からダミーのスケールダウンを実行するだけdrawable-xhdpiです。縮小した画像に対して、これ以上のピクセル編集は行いません。

最近、最高解像度の画像を1つだけ提供すると、Androidシステムが内部で画像サイズの縮小を実行することに気付きました。

drawable-xhdpi (96x96 px)
drawable-hdpi  (empty)
drawable-mdpi  (empty)
drawable-ldpi  (empty)

2台のデバイスでテストしました。わたしにはできる。これは、非常に多くの異なるサイズの画像を提供するための面倒な作業を回避するための優れた手法であるかどうか疑問に思いました。このテクニックに副作用はありますか？

4

2 に答える 2

1

これは、非常に多くの異なるサイズの画像を提供するための面倒な作業を回避するための優れた手法であるかどうか疑問に思いました。このテクニックに副作用はありますか？

私は（少なくとも）2つあると思います：

  1. これは、特に伸縮可能な領域が1つ以上の単一ピクセルで定義されている場合、9パッチで常に機能するとは限りません。たとえば、xhdpi drawableなどの9パッチを提供する場合、mdpiデバイスでは、その単一のピクセルは事実上「半分」になり、完全に消えるか、周囲の透明なピクセルとブレンドされます。後者は一般的にアップスケール/ダウンスケール操作に当てはまるため、9パッチが意図したとおりに表示されない可能性が非常に高くなります。

  2. 画像が大きいほど、メモリ内のスペースが多くなります。特に、内部メモリの量が制限され、ヒープスペースの制限がかなり厳しいローエンドデバイスでは、表示に必要なサイズよりもはるかに大きい画像をロードすると、メモリがすぐに不足する可能性があります。

コメントについて：xhdpiリソースとしてのみ提供した場合、すべての異なる画面密度で意図したとおりに視覚的に表示されないサンプル9patchを思い付くのはかなり簡単です。次の9パッチを検討してください。

ここに画像の説明を入力してください

可視性のための拡大スナップショット：

ここに画像の説明を入力してください

明らかに、この9パッチが引き伸ばされると、結果は1ピクセルの太さの水平方向の青い線になるという考えです。ここで、この9patchをxhdpiフォルダーだけにドロップし、xhdpiとmdpiの結果を比較します。

ここに画像の説明を入力してください

明らかに、mdpiデバイスはxhdpiフォルダーから9patchを縮小しており、結果は意図したようには見えません。

とにかく、私のポイントは、多くの場合、すべての密度バケットに9パッチを提供しないと、見栄えが良くなる可能性があるということです。望ましい結果が得られない可能性のあるシナリオが確かに存在するという事実に注意してください。また、メモリ引数も考慮に入れてください。

于 2013-03-03T04:58:22.460 に答える
0

使用している手法は、より少ない数のデバイスで機能します。市場には、さまざまな解像度とさまざまなサイズの電話がたくさんあるためです。画面サイズが小さい一部の低解像度デバイスでは、UIが適切に表示されません...ここで、解像度が720 * 1280（xhdpi）のスプラッシュ画面の背景画像を使用してXhdpiに配置した例を取り上げます。サムスンユーオパやHTCワイルドファイアなどのローエンドデバイスでこのドローアブルを表示する場合よりもドローアブルフォルダは、画像がスクイーズされたタイプに見えます。

別の画像セットを使用する必要がある状況は他にもたくさんあります。あなたが言及した手法がすべての携帯電話で機能する場合、Androidが画像セットごとに異なるフォルダを開発したのはなぜですか。 ：P

于 2013-03-03T03:31:13.353 に答える