11

皆さん、これは重複しているとは思いませんし、 OOMの質問を避ける方法の 1 つでもありません。これは真の知識の探求なので、反対票は控えてください...

ピクセルがあるJPEGと想像してください。「 」500x500のとおりにロードします。ARGB_8888bad as it gets

私は Android が割り当てることを期待しています500x500x4 bytes = a little under 1MBが、ヒープ ダンプを見ると、Android がかなり多く、多くの場合5-10何倍も多く割り当てていることがわかります。

ここでは、スタック トレースが示すOOMSに関する質問をよく見かけますが、単にイメージのバイトを保持するために必要なサイズよりも常にはるかに大きくなっています。OPは通常、いくつかの反対票をキャッチし、在庫の回答と、メモリの使用量が少ないこと(Romainに感謝します!)とスケーリングに関するコメントで攻撃されます。ここには目に見える以上のものがあると思います。heap request of say 15MB

これがなぜなのか知っている人はいますか?

明らかな答えがない場合は、役立つ場合はSSCCEをまとめます。

PS。バッキングビットマップのメモリ使用量について話しているので、JPEG と PNG などは無関係であると思います。これは単に x 倍 y 倍の BPP です - それとも遅いのでしょうか?

4

1 に答える 1

1

小さなリクエストに分割されたメモリのプールまたはブロックを取得することは、メモリ管理で非常に一般的なトリックでした。私が組み込みシステムを扱っていたとき、さまざまなサイズのメモリのプールを維持するのが一般的であり、プールから要求された量よりも大きなブロックを割り当てただけでした。これは、過度のメモリ断片化を防ぐ便利な方法です。多分これはここで起こっています。

于 2013-11-30T17:19:58.740 に答える