0

最近、プロジェクトを ARC に移植しました。これは、クラッシュに問題があり、リークや保持サイクルなどの原因を実際に特定するのに苦労していたためです。アクティビティモニターを通過できなかったため、アプリケーションがこれを実行していることを示すと、heeby jeebies が表示されます (アクティビティモニタープロファイラー)

活動モニター

一方、割り当てツールでは次のようになります

割り当て

その実際のメモリ使用量は最悪でもありません。ある時点で約 90 MB に達しました。ここに記載されている情報をどうするか 100% 確信が持てないため、どうすればよいかわかりません。私は何かをドンしているかもしれません, 非常に間違っています. また、リークインストゥルメントも実行しました. いくつかありますが、それらは最小限であり、すべてバイト単位です.

誰か説明がありますか？または、少なくとも私が見ている可能性があるものを明確にすることができますか? real memory usageとlive bytesとはどう違いoverall bytesますか？また、これらの結果は、まったく同じアクションを 1 回実行し、その最後に表示されます。

ARC変換前にメモリ警告とサイレントクラッシュが頻繁に発生していたため、実際のメモリ使用量を削減しようとしていましたが、変換後にこれらに再び遭遇することはありませんでしたが、いつ試しても想像できないため、長時間のテストは行っていません実際のメモリ使用量はそのように見えます。これは実際にはARCの前よりもはるかに高く見えます.ライブバイトはARCの後は低く見えますが.狂気!

4

1 に答える 1

1

しばらくの間私を混乱させたのは、ARC は (それ自体は素晴らしいものですが) 必ずしも必要を回避しないということです@autoreleasepool。

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html

誰かが提案するまで、アプリで非常に大量のメモリを使用しました。

@autoreleasepool {

    // lots of allocating of objects returned from methods then discarded

} // and the closing brace of the autoreleasepool block causes their memory to be recovered here

多分それはあなたを助けるでしょう。

プロファイラーのさまざまな列の意味についての適切な説明は、Instruments ObjectAlloc: ライブ バイトと全体のバイトの説明にあります。

于 2012-12-11T09:15:57.753 に答える