Android-Bitmap-OOM に関するもう 1 つの質問です。
バックグラウンド
私たちのアプリケーションをストレステストしている間、持続的で大量の使用 (モンキーランナーのような) の後、OutOfMemory例外が後続のスタックトレース内に記録された後、アプリのプロセスメモリ割り当てを最大化することが可能であることが指摘されました。の下のページを選択すると、アプリは画像を (一度に約 3 つ) ダウンロードしますViewPager。アプリの長さと息吹が行使されると、280 以上の画像をダウンロードできる場合があります。このアプリケーションは、画像ダウンロードの抽象化にSquare の Picasso を使用します。特に、私たちのアプリケーションのコードでは、ビットマップを直接操作している箇所はありません... 非常に才能のある Square Inc. の従業員が、私たちよりもうまくやっていると信じています。
ここに写真があります
dalvikvm-heap以下のプロットは、ログ メッセージの下に記録された時間の経過に伴うヒープ割り当てを示しています。赤い点は、未処理の作業量を増やしてアプリにストレスをかけるために、ユーザーが新しい一連の記事をアプリケーションに持ち込んでいることを示しています...
DALVIKVM のヒープ割り当て http://snag.gy/FgsiN.jpg 図 1: Nexus One のヒープ割り当て。OOM は 80MB 以上で発生します
これまでの調査
Nexus S、Nexus 4、Wildfire、HTC Incredible、およびその他の無数のテスト デバイスに対して、事例テストでは、DVM GC がアプリによって完了される重労働作業に「追いつく」ことで、メモリ管理が十分であることが示されました。ただし、Galaxy S II、III、IV、HTC One などのハイエンド デバイスでは、OOM が普及しています。実際、やるべきことが十分にあるとすれば、最終的にはすべてのデバイスで障害が発生するだろうと想像できます。
質問
画面密度 (要求された画像サイズは ImageView のサイズに基づいています)、プロセス メモリの割り当て、特定のサイズでの画像の数の間には明確な関係があり、アプリがそのヒープ制限を超えることになります。私はこの関係の定量化に着手しようとしていますが、SO コミュニティにこの問題に目を向けてもらい、(a) この関係を構築する価値があることに同意または反対し、(b) この関係を作成する最善の方法を示す文献を提供してもらいたいと考えています。
画質を壊すと OOM はすべて消えてしまいますが、残念ながら UX は貧弱です。
補足: 以下は、レイアウトされたビューにこれらの画像をロードするコードの一部です。
picassoInstance.load(entry.getKey())
.resize(imageView.getMeasuredWidth(),
imageView.getMeasuredHeight())
.centerCrop()
.into(imageView);
上記の「画質のダッシング」は、単にimageView.getMeasured...「4」のような数で割ったものです。