アプリのプロファイリングを行うと、特定のアクション (UIView を含む) を実行するたびに、ライブ バイトが約 250 KB 増加することに気付きました。
オブジェクトのリストを見ると、主な (成長している) 犯人は「malloc 144 バイト」と表示されています。
時折、Allocations インストルメントを使用して、必要以上に長く保持しているオブジェクトを発見しましたが、「malloc」オブジェクトを解釈する方法がわかりません。
ガイダンスをいただければ幸いです。
3305 次
1 に答える
11
いくつかの考え：
割り当てツールは素晴らしいですが、最初にLeaksに焦点を当てます。そこにきれいな健康法案がありますか？
コードを静的アナライザー (「製品」メニューの「分析」) で実行しましたか。特に非 ARC コードでは、多くの問題を特定できます。
ARCを使用していますか？もしそうなら、それは検索を絞り込みます。
ゾンビをオンにしていますか？その結果、メモリが解放されなくなります。必ずゾンビをオフにしてください。
強力な参照サイクル (別名保持サイクル) がありませんか?
NSLogビュー コントローラにブレークポイントを配置またはブレークポイントを設定して、deallocそれが呼び出されていることを確認し、強い参照サイクル (2 つ以上のオブジェクト間の循環参照でどちらも解放されない) が発生しないようにすることができます。(メソッドがない場合は、ステートメントを使用してdeallocメソッドを追加してください。)繰り返しに失敗することは、誤って強い参照サイクルを引き起こす可能性がある素晴らしい例です。重要な問題は、それが行われていることを確認する必要があるということです。NSLoginvalidateNSTimerdealloc他のView Controllerの別のコピーをプッシュ/提示するのではなく、確実にView Controllerをポップ/却下していますか? (前のポイントで説明した強い参照サイクルに加えて、メソッド
NSLogで /breakpoint が表示されないのは、これが原因である可能性があります。)dealloc256 (!) の画像ビューで、プロパティ
imageNamedを設定していますか?image画像をキャッシュするimageNamedメソッドは、メモリ警告が表示されるまでメモリを解放しません (ただし、既存の画像を再取得するのではなく、新しい画像を取得するときにのみメモリを消費します)。
要するに、考えられる問題は山ほどある可能性があり、あなたの質問には問題を診断するのに十分な情報がありません。あなたは私たちが問題を絞り込むのを手伝わなければなりません.
ただし、コントローラーを調べて、必要なように割り当てが解除されていることを確認してください。私は 144 バイトmallocの問題についてあなたの苦痛を感じていますが、それが毎回 250kb を消費する原因である可能性は低いです。これmallocは、問題の原因ではなく、問題の症状である可能性が高いため、呼び出しの原因を突き止めるのに時間をかける前に、上記のより基本的な事項に焦点を当てmallocます。
于 2013-02-07T05:27:06.097 に答える