最近、画面Aから画面Bに移動しているときに問題が発生しました。画面Bから画面Aに戻ったときに、アプリケーションのライブバイトが初期値に戻っていませんでした。さらに調査した結果、複数回呼び出されたいくつかのメソッドでいくつかのグローバルオブジェクトを保持していることがわかりました。そのため、メソッドの呼び出しメカニズムを修正する必要がありました。
問題を修正しましたが、別の解決策を考えていました。保持カウントの値に応じて実行されるdeallocでforループを使用した場合はどうなりますか。このようなアプローチを使用することはお勧めできませんが、ファイルの外部からオブジェクトにアクセスしないことが確実な場合、このアプローチの正確な問題は何ですか。
前もって感謝します。
保持カウントの値に応じて実行されるdeallocでforループを使用した場合はどうなりますか。
Xcodeがそのようなコードを検出し、MacBookProのアルミケースに数アンペアの電力を供給しても驚かないでしょう。
このようなアプローチを使用することはお勧めできませんが、ファイルの外部からオブジェクトにアクセスしないことが確実な場合、このアプローチの正確な問題は何ですか。
あなたは正しいです-お勧めできません。少なくとも2つの問題があります。
これは、Objective-Cのメモリ管理パラダイムを完全に破ります。他のオブジェクトが自分のオブジェクトの1つを保持していないことを実際に確認することはできません。ほんの一例です-dealloc。ivarが参照するオブジェクトのいずれかが自動解放されたかどうかがメソッドでわかりません。
それは間違った修正です。あなたが提案したことをすることはあなたのコードのバグを修正するのではなく、それらをカバーするだけです。オブジェクトは、使用するオブジェクトを正しく管理する必要があり、他のオブジェクトが保持している場合と保持していない場合があることを心配する必要はありません。その単純な式に従うと、オブジェクトが「ファイルの外部」からアクセスされるかどうかを心配する必要はありません。すべてが正常に機能します。
-retainCount保持の数を0まで実行するために使用しないだけでなく、をまったく見ないでください-retainCount。
保持カウントはあなたが信頼するためのものではありません。知らないうちに保持カウントを増減する内部実装がいくつかあるため、それを使用することはお勧めできません。
オブジェクトが保持され、解放されないコード内の場所につながるメモリリークを見つけるには、xcodeインスツルメントを使用する必要があります。
または、ARCを有効にして、メモリを管理させることもできます。