6

アプリの 1 つにメモリの問題があり、Instruments > Activity monitor で定義されている「実メモリ」が原因の可能性があることを特定しました。

私のアプリは、 UIScrollViews 内に大きな UIImages を割り当てます。画像の 1 つに適用される CIImageFilter があります。アクティビティ モニターは、大きな画像を含むスクロール ビューを含むビュー コントローラーを最初に押すと、実際のメモリ使用量が約 300 MB に跳ね上がることを示しています。後続のプッシュ/ポップにより、約 500mb に上昇します。

「Live Bytes」はテクスチャと CALayers によって使用されるメモリをカウントしないことを読んだので、私の質問は次のとおりです。画像/Scrollviews の CALayers によって使用されるメモリを適切に解放するにはどうすればよいですか?

右側の実際のメモリ使用量の青い円グラフを参照してください。

ここに画像の説明を入力

このプロセスでは、実メモリと仮想メモリの両方が最高です。

ここに画像の説明を入力

私が気になるのは、そのコントローラーをポップするときに大きなスクロールビューと画像をクリーンアップしようとしていることです.「ライブバイト」の数値は約5mbに減少しますが、「リアルメモリ」はとてつもなく高いままです（〜500 mb） :

ContainerScrollView* container = ...;
[container.view removeFromSuperview];
container.view = nil;

割り当てのプロファイリングは次のとおりです。 ここに画像の説明を入力

4

1 に答える 1

1

ここで同様の問題を経験している人を見つけました：

ARC を使用した謎の CoreImage メモリ リーク

答え（そうであることを本当に願っています）は、使用を開始しNSData dataWithContentsOfFile: てから作成するように見えますUIImage imageWithData:. ユーザーが選んだ画像はありますか? 一時ファイルに書き込み、読み戻します。iOS 6.1.2 での 12 時間のテストでは、大きな画像ビューに対して不合理な動作をしているように見えるため、他の画像メソッドは信頼していません。

于 2013-04-04T04:28:14.777 に答える