關于StoryBoard

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

使用storyboard創建導航控制器以及控制器的生命周期
一、基本過程

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

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

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

完成基本設置后的界面如下:

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

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

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

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

產生問題的原因：（當點擊返回的時候，不是先把第三個控制器移除棧頂，而是先創建TWO控制器，此時棧里有四個控制器，棧頂的為TWO）.

二、控制器的生命周期

代碼簡單說明：

三個重要的方法：

兩個內存警告的區別（和代理中得比較）:

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

需要了解它的父類是如何處理內存警告的。

模擬內存警告：

內存警告的處理示意圖：

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

當前one控制器在棧頂，one控制器對應的view顯示在window上，如果此時發生內存警告，那么one因為在window上面，所以不會被銷毀。

若此時再來一個two控制器，它創建對應的twoview顯示到window上，one對應的view移開了，此時如果發生內存警告，則此時oneview已經不再在window上顯示，所以會被銷毀。

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

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