iOS viewDidUnload方法

在iOS6中，viewDidUnload回調方法被Deprecated掉了。查看蘋果的文檔，可以看到如下的說明。

那麼，原本在viewDidUnload中的代碼應該怎麼處理？在iOS6中，又應該怎麼處理記憶體警告？帶著這些問題，我尋找了一些資料，在此分享給大家。

分析

在iOS4和iOS5系統中，當記憶體不足，應用收到Memory warning時，系統會自動調用當前沒在介面上的ViewController的viewDidUnload方法。 通常情況下，這些未顯示在介面上的ViewController是UINavigationController
Push棧中未在棧頂的ViewController，以及UITabBarViewController中未顯示的子ViewController。這些View
Controller都會在Memory Warning事件發生時，被系統自動調用viewDidUnload方法。

在iOS6中，由於viewDidUnload事件在iOS6下任何情況都不會被觸發，所以蘋果在文檔中建議，應該將回收記憶體的相關操作移到另一個回呼函數：didReceiveMemoryWarning 中。但是如果你僅僅是把以前寫到viewDidUnload函數中的代碼移動到didReceiveMemoryWarning函數中，那麼你就錯了。以下是一個 錯誤的範例程式碼 ：

[html] view
plaincopy

1. <span style="font-size:18px;">- (void)didReceiveMemoryWarning {  
2.     [super didReceiveMemoryWarning];  
3.     if([self isViewLoaded] && ![[self view] window]) {  
4.         [self setView:nil];  
5.     }  
6. }</span>  

這篇文章解釋了iOS6不推薦你將view置為nil的原因（連結開啟需要翻牆）, 翻譯過來如下：

UIView有一個CALayer的成員變數，CALayer是具體用於將自己畫到螢幕上的。如所示：

CALayer是一個bitmap圖象的容器類，當UIView調用自身的drawRect時，CALayer才會建立這個bitmap圖象類。

具體占記憶體的其實是一個bitmap圖象類，CALayer只佔48bytes, UIView只佔96bytes。而一個iPad的全屏UIView的bitmap類會佔到12M的大小！

在iOS6時，當系統發出MemoryWarning時，系統會自動回收bitmap類。但是不回收UIView和CALayer類。這樣即回收了大部分記憶體，又能在需要bitmap類時，通過調用UIView的drawRect: 方法重建。

記憶體最佳化

另外文章中還提到蘋果的作業系統對此做的一個記憶體最佳化技巧，解釋如下：

當一段記憶體被分配時，它會被標記成“In use“, 以防止被重複使用。當記憶體被釋放時，這段記憶體會被標記成”Not inuse”，這樣，在有新的記憶體申請時，這塊記憶體就可能被分配給其它變數。

CALayer包括的具體的bitmap內容的私人成員變數類型為CABackingStore， 當收到MemroyWarning時，CABackingStore類型的記憶體區會被標記成volatile類型（這裡的volatile和 C以及Java語言的volatile不是一個意思），volatile表示，這塊記憶體可能被再次被原變數重用。

這樣，有了上面的最佳化後，當收到Memoy Warning時，雖然所有的CALayer所包含的bitmap記憶體都被標記成volatile了，但是只要這塊記憶體沒有再次被複用，那麼當需要重建bitmap記憶體時， 它就可以直接被複用，而避免了再次調用 UIView的 drawRect: 方法。

總結

所以，簡單來說，對於iOS6，你不需要做任何以前viewDidUnload的事情，更不需要把以前viewDidUnload的代碼移動到 didReceiveMemoryWarning方法中。

引用WWDC 2012 中的一段話來給viewDidUnload說再見：

The method viewWillUnload and viewDidUnload. We’re not going to call them anymore. I mean, there’s kind of a cost-benifit equation and analysis that we went through. In the early days, there was a real performance need for us to
ensure that on memory warnings we unloaded views. There was all kinds of graphics and backing stores and so forth that would also get unloaded. We now unload those independently of the view, so it isn’t that big of a deal for us for those to be unloaded, and
there were so many bugs where there would be pointers into。