關(guān)于StoryBoard

iOS5之后Apple提供了一種全新的方式來制作UI，那就是StoryBoard。簡單理解來說，可以把StoryBoard看做是一組viewController對應(yīng)的xib，以及它們之間的轉(zhuǎn)換方式的集合。在StoryBoard中不僅可以看到每個ViewController的布局樣式，也可以明確地知道各個ViewController之間的轉(zhuǎn)換關(guān)系。相對于單個的xib，其代碼需求更少，也由于集合了各個xib，使得對于界面的理解和修改的速度也得到了更大提升。減少代碼量就是減少bug量，這也是程序開發(fā)中的真理之一。
 
在Xcode5之后，StoryBoard已經(jīng)成為新建項目的默認配置，這也代表了Apple對開發(fā)者的建議和未來的方向。WWDC2013的各個Sample Code中也基本都使用了StoryBoard來進行演示?？梢灶A(yù)見到，之后Apple必定會在這方面進行繼續(xù)強化，而反之純代碼或者單個xib的方式很可能不會再得到增強。
 
如果不考慮iOS版本的支持（其實說實話現(xiàn)在已經(jīng)很少還見到要從iOS4開始支持的app了吧），現(xiàn)在StoryBoard面臨的最大問題就是多人協(xié)作。因為所有的UI都定義在一個文件中，因此很多開發(fā)者個人或企業(yè)的技術(shù)負責(zé)人認為StoryBoard是無法進行協(xié)作開發(fā)的，其實這更多的是一種對StoryBoard的陌生所造成的誤解。雖然Apple并沒有在WWDC明確提及，但是沒有人規(guī)定整個項目只能有一個StoryBoard文件。一種可行的做法是將項目的不同部分分解成若干個StoryBoard，并安排開發(fā)人員對自己的部分進行負責(zé)。簡單舉例比如一個有4個tab功能相互獨立的基于UITabBarViewController的應(yīng)用，完全可以使用4個StoryBoard來分別代表4個tab，并在相互無干擾的情況下完成開發(fā)。這樣一來就不會存在所謂的沖突問題了。StoryBoard的API是如此簡單，現(xiàn)在的SDK中一共方法數(shù)量一只手就能數(shù)過來，所以具體方法在這里就不再羅嗦了。
 
StoryBoard的另外的挑戰(zhàn)來源于ViewController的重用和自定義的view的處理。對于前者，在正確封裝接口以及良好設(shè)計的基礎(chǔ)上，其實StoryBoard的VC重用與代碼的VC重用是沒有本質(zhì)區(qū)別的，在StoryBoard中添加封裝良好需要重用的Scene即可解決。而對于后者，因為StoryBoard中已經(jīng)不允許有單個view的存在，因此很多時候我們還是需要借助于單個的xib來自定義UI。這一點可以說是由于StoryBoard的設(shè)計思路所造成的，StoryBoard更強調(diào)的是一種層次結(jié)構(gòu)，是在全局的視角上來組織UI設(shè)計和遷移。而對于單個的view，更多的會注重于重用和定制，而與整個項目的流程沒有太大關(guān)系。相信抓住這一要點，就能很好地了解什么時候使用xib，什么時候使用StoryBoard。
 
關(guān)于StoryBoard最后要說的是，現(xiàn)在會有一些對于StoryBoard性能上的擔(dān)憂。因為相對于單個xib來說，StoryBoard文件往往更大，加載速度也相應(yīng)變慢。但是其實隨著現(xiàn)在設(shè)備的更新?lián)Q代，在iPhone4都難覓的今天，這點性能上的差距幾乎可以忽略了。而再之后的設(shè)備，不論讀取還是解析，只會越來越快。所以性能上的問題完全是沒有擔(dān)心的必要的。

使用storyboard創(chuàng)建導(dǎo)航控制器以及控制器的生命周期
一、基本過程

新建一個項目，系統(tǒng)默認的主控制器繼承自UIViewController，把主控制器兩個文件刪掉。

在storyboard中，默認的控制器是View Controller，而我們需要的是導(dǎo)航控制器，那么就把系統(tǒng)的給刪掉，拖一個導(dǎo)航控制器進來，導(dǎo)航控制器中默認的第一個子控制器是一個tableview controller，這里不需要，把它刪掉，重新拖三個View Controller到界面上進行連線，簡單的設(shè)置就可以了。

按鈕連線，按住ctrl，右邊界面選擇push。

完成基本設(shè)置后的界面如下:

經(jīng)過這么幾步簡單的設(shè)置，就可以實現(xiàn)一個簡單的多頁面切換。為開發(fā)提供了極大的方便，但storyboard也不是萬能的，要注意在開發(fā)中，如果在最后一個頁面添加一個按鈕，讓它直接跳轉(zhuǎn)到上一個頁面會出現(xiàn)問題。

提示：storyboard能做的事情，使用代碼都能做，但是代碼能夠做的事情，storyboard不一定能夠做。

通過拖拉控件即可完成簡單的界面設(shè)置。

下面這樣的連線會出現(xiàn)問題：（從后面的控制器跳轉(zhuǎn)到前面，只能通過代碼來實現(xiàn)）

產(chǎn)生問題的原因：（當(dāng)點擊返回的時候，不是先把第三個控制器移除棧頂，而是先創(chuàng)建TWO控制器，此時棧里有四個控制器，棧頂?shù)臑門WO）.

二、控制器的生命周期

代碼簡單說明：

三個重要的方法：

兩個內(nèi)存警告的區(qū)別（和代理中得比較）:

代理的內(nèi)存警告:當(dāng)application發(fā)生一些事情的時候（接收到內(nèi)存警告的時候），會先通知它的代理，之后代理會通知它的window,window會通知它的根控制器，根控制器會通知它的子控制器。內(nèi)存警告是由上往下一層一層往下傳的（可以通過在兩個地方打印輸出驗證）。

需要了解它的父類是如何處理內(nèi)存警告的。

模擬內(nèi)存警告：

內(nèi)存警告的處理示意圖：

控制器的view是否可以銷毀？它怎么知道是否可以銷毀呢？如何判斷？它是判斷這個view是否是在windows上面。

當(dāng)前one控制器在棧頂，one控制器對應(yīng)的view顯示在window上，如果此時發(fā)生內(nèi)存警告，那么one因為在window上面，所以不會被銷毀。

若此時再來一個two控制器，它創(chuàng)建對應(yīng)的twoview顯示到window上，one對應(yīng)的view移開了，此時如果發(fā)生內(nèi)存警告，則此時oneview已經(jīng)不再在window上顯示，所以會被銷毀。

特別說明：outlet代表著屬性，當(dāng)控制器創(chuàng)建的時候，屬性一般也是有值的，當(dāng)調(diào)用了- (void)viewDidUnload方法以后，即控制器的view完全銷毀了以后，所有的屬性數(shù)據(jù)會清空。一般在ios5以前，還會在這個方法里面清空里面的所有屬性。

提示：所有的控制器的這些方法其實是一個循環(huán)。

最新評論