Viewのリソースの話。 - なるようになるかも

メモリ管理・レイアウトの観点からみた UIViewController の view の扱い - jarinosuke blog

うーん、ARCについての理解が不十分で、見当外れなコメントを書いてしまいました。

個人的には、そのプロパティがカスタム実装である場合、コードの読み手に意図が伝わるように@dynamicを付けたくなるのですが、この辺は趣味の領域なんでしょうね。

ちょこっとブコメにも書いたのですが、文字数が足りないので補足したいことを書いてみる。

UIViewControllerプログラミングガイドには以下のようにあります。（日本語訳もありますが、ひどく読み辛い。自分も翻訳は得意じゃないので、あれですけど）

The memory used by a view to draw itself onscreen is potentially quite large. However, the system automatically releases these expensive resources when the view is not attached to a window.

The remaining memory used by most views is small enough that it is not worth it for the system to automatically purge and recreate the view hierarchy.

You can explicitly release the view hierarchy if that additional memory is necessary for your app.

「self.viewはその必要があれば、明示的に解放しても構わない」程度の文面です。

その理由として

「ビューを描画するためのメモリ消費量は膨大になる可能性がありますが、ビューがウインドウに表示されていない場合、システムは高コストなビューリソースを自動的に解放する」
「ほとんどのビューが消費するメモリ量は、ビュー階層を開放して再構築するコストに見合わないほど小さい」

と、一見して矛盾したようなことが書いてあります。

つまるところUIViewとはビューを描画するためのモデルクラスであり、実際に画面描画を担当しているCALayerやそれより下位のレイヤにおいて、高コストなビューリソースについて適時確保/解放している、ということなのでしょう。

マルチタスクが前提となりメモリが潤沢となった今となっては、画像や音声や通信によるリソースと比較して、ビュー階層は無視できる程度に小さく、self.viewを神経質に管理する必要はない…という風に自分は解釈しています。

viewDidUnloadがライフサイクルから抹消された理由も、その辺にあると考えていたのですが、エンバグを防ぐためという解釈もあるようで面白い。