快捷導(dǎo)航

詳解iOS開發(fā)中使用storyboard創(chuàng)建導(dǎo)航控制器的方法

更新時(shí)間：2016年01月22日 09:21:36 作者：文頂頂

這篇文章主要介紹了iOS開發(fā)中使用storyboard創(chuàng)建導(dǎo)航控制器的方法,包括對控制器聲明周期的控制介紹,代碼基于傳統(tǒng)的Objective-C,需要的朋友可以參考下

關(guān)于StoryBoard

iOS5之后Apple提供了一種全新的方式來制作UI，那就是StoryBoard。簡單理解來說，可以把StoryBoard看做是一組viewController對應(yīng)的xib，以及它們之間的轉(zhuǎn)換方式的集合。在StoryBoard中不僅可以看到每個(gè)ViewController的布局樣式，也可以明確地知道各個(gè)ViewController之間的轉(zhuǎn)換關(guān)系。相對于單個(gè)的xib，其代碼需求更少，也由于集合了各個(gè)xib，使得對于界面的理解和修改的速度也得到了更大提升。減少代碼量就是減少bug量，這也是程序開發(fā)中的真理之一。

在Xcode5之后，StoryBoard已經(jīng)成為新建項(xiàng)目的默認(rèn)配置，這也代表了Apple對開發(fā)者的建議和未來的方向。WWDC2013的各個(gè)Sample Code中也基本都使用了StoryBoard來進(jìn)行演示?？梢灶A(yù)見到，之后Apple必定會(huì)在這方面進(jìn)行繼續(xù)強(qiáng)化，而反之純代碼或者單個(gè)xib的方式很可能不會(huì)再得到增強(qiáng)。

如果不考慮iOS版本的支持（其實(shí)說實(shí)話現(xiàn)在已經(jīng)很少還見到要從iOS4開始支持的app了吧），現(xiàn)在StoryBoard面臨的最大問題就是多人協(xié)作。因?yàn)樗械腢I都定義在一個(gè)文件中，因此很多開發(fā)者個(gè)人或企業(yè)的技術(shù)負(fù)責(zé)人認(rèn)為StoryBoard是無法進(jìn)行協(xié)作開發(fā)的，其實(shí)這更多的是一種對StoryBoard的陌生所造成的誤解。雖然Apple并沒有在WWDC明確提及，但是沒有人規(guī)定整個(gè)項(xiàng)目只能有一個(gè)StoryBoard文件。一種可行的做法是將項(xiàng)目的不同部分分解成若干個(gè)StoryBoard，并安排開發(fā)人員對自己的部分進(jìn)行負(fù)責(zé)。簡單舉例比如一個(gè)有4個(gè)tab功能相互獨(dú)立的基于UITabBarViewController的應(yīng)用，完全可以使用4個(gè)StoryBoard來分別代表4個(gè)tab，并在相互無干擾的情況下完成開發(fā)。這樣一來就不會(huì)存在所謂的沖突問題了。StoryBoard的API是如此簡單，現(xiàn)在的SDK中一共方法數(shù)量一只手就能數(shù)過來，所以具體方法在這里就不再羅嗦了。

StoryBoard的另外的挑戰(zhàn)來源于ViewController的重用和自定義的view的處理。對于前者，在正確封裝接口以及良好設(shè)計(jì)的基礎(chǔ)上，其實(shí)StoryBoard的VC重用與代碼的VC重用是沒有本質(zhì)區(qū)別的，在StoryBoard中添加封裝良好需要重用的Scene即可解決。而對于后者，因?yàn)镾toryBoard中已經(jīng)不允許有單個(gè)view的存在，因此很多時(shí)候我們還是需要借助于單個(gè)的xib來自定義UI。這一點(diǎn)可以說是由于StoryBoard的設(shè)計(jì)思路所造成的，StoryBoard更強(qiáng)調(diào)的是一種層次結(jié)構(gòu)，是在全局的視角上來組織UI設(shè)計(jì)和遷移。而對于單個(gè)的view，更多的會(huì)注重于重用和定制，而與整個(gè)項(xiàng)目的流程沒有太大關(guān)系。相信抓住這一要點(diǎn)，就能很好地了解什么時(shí)候使用xib，什么時(shí)候使用StoryBoard。

關(guān)于StoryBoard最后要說的是，現(xiàn)在會(huì)有一些對于StoryBoard性能上的擔(dān)憂。因?yàn)橄鄬τ趩蝹€(gè)xib來說，StoryBoard文件往往更大，加載速度也相應(yīng)變慢。但是其實(shí)隨著現(xiàn)在設(shè)備的更新?lián)Q代，在iPhone4都難覓的今天，這點(diǎn)性能上的差距幾乎可以忽略了。而再之后的設(shè)備，不論讀取還是解析，只會(huì)越來越快。所以性能上的問題完全是沒有擔(dān)心的必要的。

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

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

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

201612291541018.png (523×199)

201612291605416.png (842×513)

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

201612291625780.png (549×126)

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

201612291644524.png (1081×452)

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

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

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

201612291704800.png (591×360)

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

201612291722767.png (604×561)

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

201612291742618.png (304×246)

二、控制器的生命周期

代碼簡單說明：

復(fù)制代碼代碼如下:

@interface NJOneViewController ()

@property (nonatomic, strong) NSArray *foods;
@end

@implementation NJOneViewController

// 當(dāng)控制器的view加載完畢就調(diào)用
- (void)viewDidLoad
{
[super viewDidLoad];
NSLog(@"1控制器的view加載完畢");
}

// 控制器的view即將顯示的時(shí)候調(diào)用
- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:YES];
NSLog(@"1控制器的view即將顯示");
}

// 控制器的view完全顯示的時(shí)候調(diào)用
- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
NSLog(@"1控制器的view完全顯示");
}

// 控制器的view即將消失的時(shí)候調(diào)用
- (void)viewWillDisappear:(BOOL)animated
{
    [super viewWillDisappear:animated];
    NSLog(@"1控制器的view即將消失");
}
// 控制器的view完全消失的時(shí)候調(diào)用
- (void)viewDidDisappear:(BOOL)animated
{
    [super viewDidDisappear:animated];
    NSLog(@"1控制器的view完全消失");
}

// 控制器的view即將銷毀的時(shí)候調(diào)用
- (void)viewWillUnload
{
    [super viewWillUnload];
}
// 控制器的view完全銷毀的時(shí)候調(diào)用
- (void)viewDidUnload
{
    [super viewDidUnload];
    // 清空不需要的屬性
//    [self.foods release];
    self.foods = nil;
}

//- (void)setFoods:(NSArray *)foods
//{
//    if (_foods != foods) {
//        [foods release];
//        _foods = [foods retain];
//    }
//}

// 接收到內(nèi)存警告的時(shí)候調(diào)用
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
}
/**/

@end

打印結(jié)果如下

201612291801287.png (941×478)

三個(gè)重要的方法：

復(fù)制代碼代碼如下:

// 控制器的view即將銷毀的時(shí)候調(diào)用
- (void)viewWillUnload
{
    [super viewWillUnload];
}
// 控制器的view完全銷毀的時(shí)候調(diào)用
- (void)viewDidUnload
{
    [super viewDidUnload];
    // 清空不需要的屬性
//    [self.foods release];
    self.foods = nil;
}

// 接收到內(nèi)存警告的時(shí)候調(diào)用
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
}

補(bǔ)充：

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

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

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

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

201612291819030.png (579×309)

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

201612291835999.png (1219×1409)

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

201612291854451.png (603×312)

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

201612291911204.png (801×297)

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

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

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

201612291930242.png (2010×786)