59

私が取り組んでいるプロジェクトでは、いくつかの「高解像度」の背景を使用しています (引用に注意してください)。状況を説明すると、そのうちの 1 つは 640x935 の 1.19M PNG ファイルです。私の知る限り、Androidが画像を生データとしてメモリに解凍したとしても、これは次のようになります。

640 x 935 x 4 バイト = 2.39M

私は自分のプロジェクトで本当に理解できないメモリの問題を抱えています.誰かがこの問題に光を当ててくれることを願っています. 私が開発している 2 つのデバイスとその結果のいくつかを挙げます。

これが二次的な問題ではないことを確認するために、最初に作成したときにバックグラウンドを読み込まないようにアクティビティを作成し、ユーザーがボタンを押したときに行うことは次のとおりです。

findViewById(R.id.completed_block_background).setBackgroundResource(R.drawable.blockbackgroundbottom1);

次に、プロセスで「ヒープの更新」を使用して DDMS を使用し (そして、これが問題にならないことを確認するために最初に GC を強制します)、次のメモリ結果が得られます。

Nexus S: 18M から 26M へ (8M の差)

Galaxy Nexus: 28M から 39M へ (11M の差)

ご覧のとおり、理論的には 2.39M の非圧縮画像を背景に配置すると、実際にはメモリ使用量が 8M と 11M 増加します。誰かがこれがなぜなのか、解決策があるかどうかを説明できますか?

私が見つけた唯一の解決策は、ビットマップを使用して解像度を半分にするか、チャネル形式を下げることです (これまでのところ、これは私が行ったことであり、565 RGB に切り替えましたが、これにより、受け入れられないバンディングの問題が発生します)。

また、何もできない場合に備えて、なぜこれが起こっているのかの説明を受け入れます. 前もって感謝します。

4

1 に答える 1

116

それが画像をとても大きくしている理由ですか?

さて、何が起こっているのかというとsetBackgroundResource(R.drawable.blockbackgroundbottom1)、Androidは最初BitmapFactory.decodeResource()に実験したことを実行しますが、次にレンダリングロジックで画像をスケーリングして背景として適用します。したがって、たとえば、GalaxyNexusとNexusSの3MBの違いは、のレンディション間のサイズの違い(ピクセル単位)を反映している可能性がありLinearLayoutます。

リソースツリーのどこにこの画像を保存したかによっては、画面密度に基づいてリサンプリングが行われる場合もあります。

元の画像サイズを維持する方法はありますか?

カフから外して、最初にそれを入れてみてres/drawable-nodpi/(自動密度ベースのリサンプリングを防ぐため)、次に手動でそのBitmapバージョンを介して取得します。これにより、読み込まれているときにスケーリングできます。 Androidは画像の拡大縮小されていないコピーを保持しようとする可能性があるため、あまり役に立たないようです。PNGを描画可能なリソースから未加工のリソースに移動する必要がある場合があります。自分で直接使ってもいいとは思いませんが、除外することはできません。BitmapFactory.decodeResource()BitmapFactory.OptionsBitmapFactory.decodeResource()

于 2012-10-29T11:42:38.647 に答える