標籤:sub 指標 釋放 str add like 多個 interface one
最近有一個小師弟問我生命週期和程式執行順序的問題,話不多少,這就分享一篇文章.非常詳細.
當一個視圖控制器被建立,並在螢幕上顯示的時候。 代碼的執行順序
1、 alloc 建立對象,分配空間
2、init (initWithNibName) 初始化對象,初始化資料
3、loadView 從nib載入視圖 ,通常這一步不需要去幹涉。除非你沒有使用xib檔案建立視圖
4、viewDidLoad 載入完成,可以進行自訂資料以及動態建立其他控制項
5、viewWillAppear 視圖將出現在螢幕之前,馬上這個視圖就會被展現在螢幕上了
6、viewDidAppear 視圖已在螢幕上渲染完成
當一個視圖被移除螢幕並且銷毀的時候的執行順序,這個順序差不多和上面的相反
1、viewWillDisappear 視圖將被從螢幕上移除之前執行
2、viewDidDisappear 視圖已經被從螢幕上移除,使用者看不到這個視圖了
3、dealloc 視圖被銷毀,此處需要對你在init和viewDidLoad中建立的對象進行釋放
關於viewDidUnload :在發生記憶體警告的時候如果本視圖不是當前螢幕上正在顯示的視圖的話, viewDidUnload將會被執行,本視圖的所有子視圖將被銷毀,以釋放記憶體,此時開發人員需要手動對viewLoad、viewDidLoad中建立的對象釋放記憶體。 因為當這個視圖再次顯示在螢幕上的時候,viewLoad、viewDidLoad 再次被調用,以便再次構造視圖。
當我們建立一個UIViewController類的對象時,通常系統會產生幾個預設的方法,這些方法大多與視圖的調用有關,但是在視圖調用時,這些方法的調用順序如何,需要整理下。
通常上述方法包括如下幾種,這些方法都是UIViewController類的方法:
- (void)viewDidLoad;
- (void)viewDidUnload;
- (void)viewWillAppear:(BOOL)animated;
- (void)viewDidAppear:(BOOL)animated;
- (void)viewWillDisappear:(BOOL)animated;
- (void)viewDidDisappear:(BOOL)animated;
下面介紹下APP在運行時的調用順序。
1)- (void)viewDidLoad;
一個APP在載入時會先通過調用loadView方法或者載入IB中建立的初始介面的方法,將視圖載入到記憶體中。然後會調用viewDidLoad方法來進行進一步的設定。通常,我們對於各種初始資料的載入,初始設定等很多內容,都會在這個方法中實現,所以這個方法是一個很常用,很重要的方法。
但是要注意,這個方法只會在APP剛開始載入的時候調用一次,以後都不會再調用它了,所以只能用來做初始設定。
2) - (void)viewDidUnload;
在記憶體足夠的情況下,軟體的視圖通常會一直儲存在記憶體中,但是如果記憶體不夠,一些沒有正在顯示的viewcontroller就會收到記憶體不夠的警告,然後就會釋放自己擁有的視圖,以達到釋放記憶體的目的。但是系統只會釋放記憶體,並不會釋放對象的所有權,所以通常我們需要在這裡將不需要在記憶體中保留的對象釋放所有權,也就是將其指標置為nil。
這個方法通常並不會在視圖變換的時候被調用,而只會在系統退出或者收到記憶體警告的時候才會被調用。但是由於我們需要保證在收到記憶體警告的時候能夠對其作出反應,所以這個方法通常我們都需要去實現。
另外,即使在裝置上按了Home鍵之後,系統也不一定會調用這個方法,因為IOS4之後,系統允許將APP在後台掛起,並將其繼續滯留在記憶體中,因此,viewcontroller並不會調用這個方法來清除記憶體。
3)- (void)viewWillAppear:(BOOL)animated;
系統在載入所有資料後,將會在螢幕上顯示視圖,這時會先調用這個方法。通常我們會利用這個方法,對即將顯示的視圖做進一步的設定。例如,我們可以利用這個方法來設定裝置不同方向時該如何顯示。
另外一方面,當APP有多個視圖時,在視圖間切換時,並不會再次載入viewDidLoad方法,所以如果在調入視圖時,需要對資料做更新,就只能在這個方法內實現了。所以這個方法也非常常用。
4) - (void)viewDidAppear:(BOOL)animated;
有時候,由於一些特殊的原因,我們不能在viewWillApper方法裡,對視圖進行更新。那麼可以重寫這個方法,在這裡對正在顯示的視圖進行進一步的設定。
5) - (void)viewWillDisappear:(BOOL)animated;
在視圖變換時,當前視圖在即將被移除、或者被覆蓋時,會調用這個方法進行一些善後的處理和設定。
由於在IOS4之後,系統允許將APP在後台掛起,所以在按了Home鍵之後,系統並不會調用這個方法,因為就這個APP本身而言,APP顯示的view,仍是掛起時候的view,所以並不會調用這個方法。
6) - (void)viewDidDisappear:(BOOL)animated;
我們可以重寫這個方法,對已經消失,或者被覆蓋,或者已經隱藏了的視圖做一些其他動作。
上述方法的流程圖可以簡單用如下表示:
運行APP —> 載入視圖 —> 調用viewDidLoad方法 —> 調用viewWillAppear方法 —> 調用viewDidAppear方法 —> 正常運行
aaaaaaaaA |
aaaaaaaa| |
aaaaaaaa| 載入新的View |
aaaaaaaa| |
aaaaaaaa| V
釋放對象所有權 <— 調用viewDidUnload <— 收到記憶體警告 <— 調用viewDidDisappear <— 調用viewWillDisappear <— APP需要調用另一個view
IOS程式啟動執行順序
http://www.yifeiyang.net/iphone-developer-advanced-3-iphone-application-startup-process/
IOS 開發 loadView 和 viewDidLoad 的區別
iPhone開發必不可少的要用到這兩個方法。 他們都可以用來在視圖載入的時候,初始化一些內容。 但是他們有什麼區別呢?
viewDidLoad 此方法只有當view從nib檔案初始化的時候才被調用。
loadView 此方法在控制器的view為nil的時候被調用。 此方法用於以編程的方式建立view的時候用到。 如:
-(void)loadView{
UIView *view =[[UIView alloc]initWithFrame:[UIScreen
mainScreen].applicationFrame];
[view setBackgroundColor:_color];
self.view = view;
[view release];
}
你在控制器中實現了loadView方法,那麼你可能會在應用啟動並執行某個時候被記憶體管理控制調用。 如果裝置記憶體不足的時候, view 控制器會收到didReceiveMemoryWarning的訊息。 預設的實現是檢查當前控制器的view是否在使用。如果它的view不在當前正在使用的view hierarchy裡面,且你的控制器實現了loadView方法,那麼這個view將被release, loadView方法將被再次調用來建立一個新的view。
--------------------------------------------------------------------------------------------------------------------------------------------
Don‘t read self.view in -loadView.Onlysetit, don‘tgetit.
The self.view property accessorcalls-loadView if the view isn‘t currently loaded. There‘s your infinite recursion.
The usual way to build the view programmatically in -loadView, as demonstrated in Apple‘s pre-Interface-Builder examples, is more like this:
UIView*view=[[UIViewalloc]init...];...[view addSubview:whatever];[view addSubview:whatever2];...self.view=view;[view release];
And I don‘t blame you for not using IB. I‘ve stuck with this method for all of Instapaper and find myself much more comfortable with it than dealing with IB‘s complexities, interface quirks, and unexpected behind-the-scenes behavior.
ObJective-C UIViewController生命週期及iOS程式執行順序