ビットマップをデコードするパフォーマンスの問題について読んでいて、OutOfMemoryError「ビットマップが VM の予算を超えています」という問題を受け取りましたが、メモリ不足ではないと予想し、これがフレームワークのバグと呼ばれる一般的な問題であることをオンラインで読みました。多くの開発者。
通常、2 回目のパスで上記のエラーが発生します。かなり大きなビットマップを正常にロードし、それをリサイクルして、ref を null に設定したとしましょう。ビットマップをメモリにロードする作業を行うこの同じメソッドを 2 度目に呼び出すと、クラッシュします。
BitmapFactory.Options を使用して実行できることがいくつかある (たとえば、入力バッファーを明示的に提供する) ことを、ここおよび他のオンラインの以前の投稿で読みました。しかし、私が見つけたものをやみくもに使用する前に、これらのクラスについてより多くの知識を持っている人がもう少し光を当てることができることを願っています.
バイト配列を BitmapFactory.Options.inTempStorage に明示的に提供することと、エンコード プロセス中に BitmapFactory がバイト配列なしで行うことの違いは何ですか? これが OutOfMemoryError に役立つのはなぜですか? デフォルトよりも小さいバッファを提供しているため、メモリが不足する前にクリーンアップする機会が増えていますか?
Bitmap.recycle() を呼び出すと具体的に何が起こっているのでしょうか? Bitmap を null に設定するのとなぜ違うのでしょうか? 注: どちらかまたは両方を実行しても、OutOfMemory エラーが発生するかどうか (およびいつ発生するか) に違いはありません。
この種の問題で GC を明示的に招待する必要がある場合はありますか? 私は常に (Java と .Net の両方で) GC が、メモリを解放するだけでなく、コレクションに対してより多くの影響があるため、GC がどこでいつ実行するかを決定することを信頼する必要があるという仮定の下で操作してきました。 （そして、私は個人的にその決定を下すのに十分なほど精通していません）。
アップデート：
このビデオは、私の質問のほとんどに答えました。
Google I/O 2011: Android アプリのメモリ管理