viewDidUnload は非推奨です。したがって、ARC に関係なく、必要ないだけでなく、使用するべきではありません。述べられている正当な理由は、メモリ不足の警告でビューが削除されなくなったことです (おそらく、応答性のヒットに値するほどビューが合計にほとんど貢献していないためです)。viewDidLoad多くの人が内部で作成されたすべてのリソースを解放できviewDidUnload、それだけでリークを防ぐことができると想定していたことが正当化の一部であったとしても、私は驚かない. メモリ不足の警告のためにviewDidUnloadビューがアンロードされた場合にのみ呼び出されるため、これは正しくありません。通常のライフサイクルでは呼び出されません。
ARCの新しい規則の下で:
インスタンス変数の解放以外のリソースを管理する必要がある場合は、dealloc メソッドを実装できます。インスタンス変数を解放する必要はありません (実際には解放できません)。
編集: 特に 4.3+ についてコメントするには...
ARC は のバージョンを実装しviewDidUnloadません。viewDidLoad/viewDidUnloadサイクルのポイントは、retain何らかの理由でビュー階層の一部である場合、メモリ不足の警告で自動的に解放されないようにすることですが、そうしてもメリットはありません。ビューは次にロードされ、保持しているものはすべて新しいコピーに置き換えられます。したがって、とにかくstrong IBOutletその下の階層内にあるビューへの s がある場合はself.view、理想的には の間にそれらを nil しますviewDidUnload。参照がある場合でもweak、ぶら下がっているポインターを持ち越さないようにするのに適した場所です。
iOS 5 の時点で、自己ゼロ化の弱い参照を持つことができるので、viewDidUnload5 以上をサポートしている場合は、それらを使用して実装しないことをお勧めします。4.3 では、強力な参照を使用して省略viewDidUnloadした場合、Apple が望んでいるメモリ不足の警告に対する応答を徹底的に防止することになる可能性がありますが、メモリ リークは発生しません。弱い参照を使用する場合は、ビューを持っていない可能性があるとき (つまり、表示されていないが、ビューが以前に読み込まれたとき) にこれらのオブジェクトを参照しないように少し注意する必要があります — セッタービューを調整するが、別のビューの影響を受けるコントローラは典型的な例です; たとえば、キー値を観察してフィールドを更新していた場合など)。
シミュレーターの「Simulate Memory Warning」を使用して、そのようなものをある程度テストおよびデバッグできます。
deallocARC が提供する は、iOS のバージョンに関係なく同じです。ただし、Objective-C オブジェクトのみをカバーします。releaseインスタンス変数を解放できないと彼らが言うとき、彼らはメッセージを彼らに送るというまさに文字通りの意味でそれを意味します。Core Foundation オブジェクトがある場合、または純粋な C メモリ割り当てを実行した場合dealloc、それらすべてを破棄する を実装する必要があります。
明らかに、Instruments と Leaks ツールは、その領域をテストおよびデバッグする方法です。メモリ リークが発生した場合は常に注意して、そのメモリを作成したオブジェクトの型もリークしていないかどうかを確認してください。dealloc即時オブジェクトは問題ない可能性がありますが、他の誰かがリークしたために割り当てられなかった場合、その割り当てはリークされたリストに表示されます。