MVC 具有什么樣的優(yōu)勢(shì)，各個(gè)模塊之間怎么通信，比如點(diǎn)擊 Button 后 怎么通知 Model？
[iOS] MVC 設(shè)計(jì)模式
MVC 是一種設(shè)計(jì)思想，一種框架模式，是一種把應(yīng)用中所有類(lèi)組織起來(lái)的策略，它把你的程序分為三塊，分別是：
M（Model）：實(shí)際上考慮的是“什么”問(wèn)題，你的程序本質(zhì)上是什么，獨(dú)立于 UI 工作。是程序中用于處理應(yīng)用程序邏輯的部分，通常負(fù)責(zé)存取數(shù)據(jù)。
C（Controller）：控制你 Model 如何呈現(xiàn)在屏幕上，當(dāng)它需要數(shù)據(jù)的時(shí)候就告訴 Model，你幫我獲取某某數(shù)據(jù)；當(dāng)它需要 UI 展示和更新的時(shí)候就告訴 View，你幫我生成一個(gè) UI 顯示某某數(shù)據(jù)，是 Model 和 View 溝通的橋梁。
V（View）：Controller 的手下，是 Controller 要使用的類(lèi)，用于構(gòu)建視圖，通常是根據(jù) Model 來(lái)創(chuàng)建視圖的。
要了解 MVC 如何工作，首先需要了解這三個(gè)模塊間如何通信。
[圖片上傳中。。。（1）]MVC通信規(guī)則
Controller to Model
可以直接單向通信。Controller 需要將 Model 呈現(xiàn)給用戶(hù)，因此需要知道模型的一切，還需要有同 Model 完全通信的能力，并且能任意使用 Model 的公共 API。
Controller to View
可以直接單向通信。Controller 通過(guò) View 來(lái)布局用戶(hù)界面。
Model to View
永遠(yuǎn)不要直接通信。Model 是獨(dú)立于 UI 的，并不需要和 View 直接通信，View 通過(guò) Controller 獲取 Model 數(shù)據(jù)。
View to Controller
View 不能對(duì) Controller 知道的太多，因此要通過(guò)間接的方式通信。
Target action。首先 Controller 會(huì)給自己留一個(gè) target，再把配套的 action 交給 View 作為聯(lián)系方式。那么 View 接收到某些變化時(shí)，View 就會(huì)發(fā)送 action 給 target 從而達(dá)到通知的目的。這里 View 只需要發(fā)送 action，并不需要知道 Controller 如何去執(zhí)行方法。
代理。有時(shí)候 View 沒(méi)有足夠的邏輯去判斷用戶(hù)操作是否符合規(guī)范，他會(huì)把判斷這些問(wèn)題的權(quán)力委托給其他對(duì)象，他只需獲得答案就行了，并不會(huì)管是誰(shuí)給的答案。
DataSoure。View 沒(méi)有擁有他們所顯示數(shù)據(jù)的權(quán)力，View 只能向 Controller 請(qǐng)求數(shù)據(jù)進(jìn)行顯示，Controller 則獲取 Model 的數(shù)據(jù)整理排版后提供給 View。
Model 訪(fǎng)問(wèn) Controller
同樣的 Model 是獨(dú)立于 UI 存在的，因此無(wú)法直接與 Controller 通信，但是當(dāng) Model 本身信息發(fā)生了改變的時(shí)候，會(huì)通過(guò)下面的方式進(jìn)行間接通信。
Notification & KVO一種類(lèi)似電臺(tái)的方法，Model 信息改變時(shí)會(huì)廣播消息給感興趣的人 ，只要 Controller 接收到了這個(gè)廣播的時(shí)候就會(huì)主動(dòng)聯(lián)系 Model，獲取新的數(shù)據(jù)并提供給 View。
從上面的簡(jiǎn)單介紹中我們來(lái)簡(jiǎn)單概括一下 MVC 模式的優(yōu)點(diǎn)。
1.低耦合性
2.有利于開(kāi)發(fā)分工
3.有利于組件重用
4.可維護(hù)性
兩個(gè)無(wú)限長(zhǎng)度鏈表（也就是可能有環(huán)） 判斷有沒(méi)有交點(diǎn)
鏈表常見(jiàn)操作
給定單鏈表，檢測(cè)是否有環(huán)。如果有環(huán)，則求出進(jìn)入環(huán)的第一個(gè)節(jié)點(diǎn)。
判斷單向鏈表是否有環(huán)，可以采用快指針與慢指針的方式來(lái)解決。即定義一個(gè)快指針fast和一個(gè)慢指針slow，使得fast每次跳躍兩個(gè)節(jié)點(diǎn)，slow每次跳躍一個(gè)節(jié)點(diǎn)。如果鏈表沒(méi)有環(huán)的話(huà)，則slow與fast永遠(yuǎn)不會(huì)相遇（這里鏈表至少有兩個(gè)節(jié)點(diǎn)）；如果有環(huán)，則fast與slow將會(huì)在環(huán)中相遇。
然后獲取環(huán)的入口點(diǎn)方法如圖所示：
[圖片上傳中。。。（2）]
給定兩個(gè)單鏈表（鏈表自身無(wú)環(huán)），檢測(cè)兩個(gè)鏈表是否有交點(diǎn)，如果有返回第一個(gè)交點(diǎn)。
檢測(cè)兩個(gè)單鏈表是否有交點(diǎn)是很容易的，因?yàn)槿绻麅蓚€(gè)鏈表有交點(diǎn)，那么這兩個(gè)鏈表的最后一個(gè)節(jié)點(diǎn)必須相同，所以只需比較最后一個(gè)節(jié)點(diǎn)即可。但是這種方案是無(wú)法求出第一個(gè)交點(diǎn)的，所以需要另辟蹊徑。另外，判斷是否有交點(diǎn)可以轉(zhuǎn)換成鏈表是否有環(huán)的問(wèn)題。讓一個(gè)鏈表的最后一個(gè)節(jié)點(diǎn)指向第二個(gè)鏈表的頭結(jié)點(diǎn)，這樣的話(huà)，如果相交，則新的鏈表是存在環(huán)的，并且交點(diǎn)便是環(huán)的入口點(diǎn)。
給定兩個(gè)單鏈表（不確定是否帶環(huán)），判斷是否有交點(diǎn)
先判斷兩個(gè)鏈表是否帶環(huán)；
i).如果兩個(gè)都不帶環(huán)，可以用：判斷兩個(gè)無(wú)環(huán)單鏈表是否有交點(diǎn)。
ii).兩個(gè)都帶環(huán)：找到兩個(gè)入環(huán)點(diǎn)r1,r2，環(huán)1的入環(huán)點(diǎn)為r1，從r1開(kāi)始遍歷一圈，每個(gè)結(jié)點(diǎn)如r2比較
iii).一個(gè)帶環(huán)一個(gè)不帶環(huán)，則肯定不相交。
給定單鏈表頭結(jié)點(diǎn)，刪除鏈表中倒數(shù)第k個(gè)結(jié)點(diǎn)
這個(gè)問(wèn)題的關(guān)鍵是需要獲取倒數(shù)第k個(gè)節(jié)點(diǎn)。如何獲取呢？這里，需要兩個(gè)指針p和q，p指向頭結(jié)點(diǎn)，q指向距離頭結(jié)點(diǎn)為k的節(jié)點(diǎn)。這樣p和q每次遍歷一個(gè)節(jié)點(diǎn)，當(dāng)q遍歷到末尾的時(shí)候，p指向的節(jié)點(diǎn)即為倒數(shù)第k個(gè)節(jié)點(diǎn)，然后刪除即可。
只給定單鏈表中某個(gè)結(jié)點(diǎn)p（并非最后一個(gè)結(jié)點(diǎn)，即p->next!=NULL）指針，刪除該結(jié)點(diǎn)；
只給定單鏈表中某個(gè)結(jié)點(diǎn)p（非空結(jié)點(diǎn)），在p前面插入一個(gè)結(jié)點(diǎn)。
上訴兩種方法的原理都是一樣的。
UITableView 的相關(guān)優(yōu)化
1.基礎(chǔ)的優(yōu)化準(zhǔn)則(高度緩存, cell 重用...)
滾動(dòng)很快時(shí)，只加載目標(biāo)范圍內(nèi)的Cell，這樣按需加載，極大的提高流暢度。提前計(jì)算并緩存 好高度（布局），因?yàn)閔eightForRowAtIndexPath:是調(diào)用最頻繁的方法。異步繪制，遇到復(fù) 雜界面，遇到性能瓶頸時(shí)，可能就是突破口。滑動(dòng)時(shí)按需加載，這個(gè)在大量圖片展示，網(wǎng)絡(luò)加 載的時(shí)候很管用！（SDWebImage已經(jīng)實(shí)現(xiàn)異步加載，配合這條性能杠杠的）。
除了上面最主要的三個(gè)方面外，還有很多幾乎大伙都很熟知的優(yōu)化點(diǎn)：
正確使用reuseIdentifier來(lái)重用Cells
盡量使所有的viewopaque，包括Cell自身
盡量少用或不用透明圖層
如果Cell內(nèi)現(xiàn)實(shí)的內(nèi)容來(lái)自web，使用異步加載，緩存請(qǐng)求結(jié)果
減少subviews的數(shù)量
在heightForRowAtIndexPath:中盡量不使用cellForRowAtIndexPath:，如果你需要用到 它，只用一次然后緩存結(jié)果
盡量少用addView給Cell動(dòng)態(tài)添加View，可以初始化時(shí)就添加，然后通過(guò)hide來(lái)控制是否顯
2.學(xué)會(huì)使用調(diào)試工具分析問(wèn)題
http://www.lxweimin.com/p/af6b095aaaf3
http://blog.csdn.net/icetime17/article/details/46709975
KVO、Notification、delegate 各自的優(yōu)缺點(diǎn)，效率還有使用場(chǎng)景
在開(kāi)發(fā)ios應(yīng)用的時(shí)候，我們會(huì)經(jīng)常遇到一個(gè)常見(jiàn)的問(wèn)題：在不過(guò)分耦合的前提下，controllers間怎么進(jìn)行通信。在IOS應(yīng)用不斷的出現(xiàn)三種模式來(lái)實(shí)現(xiàn)這種通信：
1.委托delegation；
2.通知中心Notification Center；
3.鍵值觀察key value observing，KVO
delegate的優(yōu)勢(shì)：
1.很?chē)?yán)格的語(yǔ)法，所有能響應(yīng)的時(shí)間必須在協(xié)議中有清晰的定義
2.因?yàn)橛袊?yán)格的語(yǔ)法，所以編譯器能幫你檢查是否實(shí)現(xiàn)了所有應(yīng)該實(shí)現(xiàn)的方法，不容易遺忘和出錯(cuò)
3.使用delegate的時(shí)候，邏輯很清楚，控制流程可跟蹤和識(shí)別
4.在一個(gè)controller中可以定義多個(gè)協(xié)議，每個(gè)協(xié)議有不同的delegate
5.沒(méi)有第三方要求保持/監(jiān)視通信過(guò)程，所以假如出了問(wèn)題，那我們可以比較方便的定位錯(cuò)誤代碼。
6.能夠接受調(diào)用的協(xié)議方法的返回值，意味著delegate能夠提供反饋信息給controller
delegate的缺點(diǎn)：
需要寫(xiě)的代碼比較多
有一個(gè)“Notification Center”的概念，他是一個(gè)單例對(duì)象，允許當(dāng)事件發(fā)生的時(shí)候通知一些對(duì)象，滿(mǎn)足控制器與一個(gè)任意的對(duì)象進(jìn)行通信的目的，這種模式的基本特征就是接收到在該controller中發(fā)生某種事件而產(chǎn)生的消息，controller用一個(gè)key（通知名稱(chēng)），這樣對(duì)于controller是匿名的，其他的使用同樣地key來(lái)注冊(cè)了該通知的對(duì)象能對(duì)通知的事件作出反應(yīng)。
notification的優(yōu)勢(shì)：
1.不需要寫(xiě)多少代碼，實(shí)現(xiàn)比較簡(jiǎn)單
2.一個(gè)對(duì)象發(fā)出的通知，多個(gè)對(duì)象能進(jìn)行反應(yīng)，一對(duì)多的方式實(shí)現(xiàn)很簡(jiǎn)單
缺點(diǎn)：
1.編譯期不會(huì)接茬通知是否能被正確處理
2.釋放注冊(cè)的對(duì)象時(shí)候，需要在通知中心取消注冊(cè)
3.調(diào)試的時(shí)候，程序的工作以及控制流程難跟蹤
4.需要第三方來(lái)管理controller和觀察者的聯(lián)系
5.controller和觀察者需要提前知道通知名稱(chēng)、UserInfo dictionary keys。如果這些沒(méi)有在工作區(qū)間定義，那么會(huì)出現(xiàn)不同步的情況
6.通知發(fā)出后，發(fā)出通知的對(duì)象不能從觀察者獲得任何反饋。
KVO
KVO是一個(gè)對(duì)象能觀察另一個(gè)對(duì)象屬性的值，前兩種模式更適合一個(gè)controller和其他的對(duì)象進(jìn)行通信，而KVO適合任何對(duì)象監(jiān)聽(tīng)另一個(gè)對(duì)象的改變，這是一個(gè)對(duì)象與另外一個(gè)對(duì)象保持同步的一種方法。KVO只能對(duì)屬性做出反應(yīng)，不會(huì)用來(lái)對(duì)方法或者動(dòng)作做出反應(yīng)。
優(yōu)點(diǎn)：
1.提供一個(gè)簡(jiǎn)單地方法來(lái)實(shí)現(xiàn)兩個(gè)對(duì)象的同步
2.能對(duì)非我們創(chuàng)建的對(duì)象做出反應(yīng)
3.能夠提供觀察的屬性的最新值和先前值
4.用keypaths 來(lái)觀察屬性，因此也可以觀察嵌套對(duì)象
缺點(diǎn)：
1.觀察的屬性必須使用string來(lái)定義，因此編譯器不會(huì)出現(xiàn)警告和檢查
2.對(duì)屬性的重構(gòu)將導(dǎo)致觀察不可用
3.復(fù)雜的“if”語(yǔ)句要求對(duì)象正在觀察多個(gè)值，這是因?yàn)樗械挠^察都通過(guò)一個(gè)方法來(lái)指向
KVO有顯著的使用場(chǎng)景，當(dāng)你希望監(jiān)視一個(gè)屬性的時(shí)候，我們選用KVO
而notification和delegate有比較相似的用處，
當(dāng)處理屬性層的消息的事件時(shí)候，使用KVO，其他的盡量使用delegate，除非代碼需要處理的東西確實(shí)很簡(jiǎn)單，那么用通知很方便
如何手動(dòng)通知 KVO
重寫(xiě)Controller里面某個(gè)屬性的setter方法，聯(lián)動(dòng)給View賦值，使用Controller監(jiān)控Model里面某個(gè)值的變化，在controller的dealloc函數(shù)中用一行代碼了結(jié)：removeObserver。
Objective-C 中的 copy 方法
Objective-c中對(duì)象的Copy、MutableCopy、淺拷貝、深拷貝
淺析Objective-C的copy
runtime 中，SEL 和 IMP 的區(qū)別
方法名 SEL – 表示該方法的名稱(chēng)；
一個(gè) types – 表示該方法參數(shù)的類(lèi)型；
一個(gè)IMP – 指向該方法的具體實(shí)現(xiàn)的函數(shù)指針，說(shuō)白了IMP就是實(shí)現(xiàn)方法。
autoreleasepool 的使用場(chǎng)景和原理
Autorelease Pool全名叫做NSAutoreleasePool，是OC中的一個(gè)類(lèi)。autorelease pool并不是天生就有的，你需要手動(dòng)的去創(chuàng)建它。一般地，在新建一個(gè)iphone項(xiàng)目的時(shí)候，xcode會(huì)自動(dòng)地為你創(chuàng)建一個(gè)Autorelease Pool，這個(gè)pool就寫(xiě)在Main函數(shù)里面。在NSAutoreleasePool中包含了一個(gè)可變數(shù)組，用來(lái)存儲(chǔ)被聲明為autorelease的對(duì)象。當(dāng)NSAutoreleasePool自身被銷(xiāo)毀的時(shí)候，它會(huì)遍歷這個(gè)數(shù)組，release數(shù)組中的每一個(gè)成員（注意，這里只是release，并沒(méi)有直接銷(xiāo)毀對(duì)象）。若成員的retain count 大于1，那么對(duì)象沒(méi)有被銷(xiāo)毀，造成內(nèi)存泄露。默認(rèn)的NSAutoreleasePool 只有一個(gè)，你可以在你的程序中創(chuàng)建NSAutoreleasePool，被標(biāo)記為autorelease的對(duì)象會(huì)跟最近的NSAutoreleasePool匹配。可以嵌套使用NSAutoreleasePool。
Objective-C Autorelease Pool 的實(shí)現(xiàn)原理
RunLoop 的實(shí)現(xiàn)原理和數(shù)據(jù)結(jié)構(gòu)，什么時(shí)候會(huì)用到
Objective-C之run loop詳解
Objective-C之Run Loop詳解
block 為什么會(huì)有循環(huán)引用
產(chǎn)生原因：如下圖所示，對(duì)象A和對(duì)象B相互引用了對(duì)方作為自己的成員變量，只有自己銷(xiāo)毀的時(shí)候才能將成員變量的引用計(jì)數(shù)減1。對(duì)象A的銷(xiāo)毀依賴(lài)于對(duì)象B的銷(xiāo)毀，同時(shí)對(duì)象B銷(xiāo)毀也依賴(lài)與對(duì)象A的銷(xiāo)毀，從而形成循環(huán)引用，此時(shí)，即使外界沒(méi)有任何指針訪(fǎng)問(wèn)它，它也無(wú)法釋放。
[圖片上傳中。。。（3）]
循環(huán)引用示例圖
多個(gè)對(duì)象間依然會(huì)存在循環(huán)引用問(wèn)題，形成一個(gè)環(huán)，在編程中，形成的環(huán)越大越不容易察覺(jué)，如下圖所示：
[圖片上傳中。。。（4）]
多個(gè)對(duì)象引用示例圖
解決方法：
事先知道存在循環(huán)引用的地方，在合理的位置主動(dòng)斷開(kāi)一個(gè)引用，是對(duì)象回收,使用弱引用的方法。
使用 GCD 如何實(shí)現(xiàn)這個(gè)需求：A、B、C 三個(gè)任務(wù)并發(fā)，完成后執(zhí)行任務(wù) D。
NSOperation 和 GCD 的區(qū)別
GCD是基于c的底層api，NSOperation屬于object-c類(lèi)。ios 首先引入的是NSOperation，IOS4之后引入了GCD和NSOperationQueue并且其內(nèi)部是用gcd實(shí)現(xiàn)的。
相對(duì)于GCD：
1，NSOperation擁有更多的函數(shù)可用，具體查看api。
2，在NSOperationQueue中，可以建立各個(gè)NSOperation之間的依賴(lài)關(guān)系。
3，有kvo，可以監(jiān)測(cè)operation是否正在執(zhí)行（isExecuted）、是否結(jié)束（isFinished），是否取消（isCanceld）。
4，NSOperationQueue可以方便的管理并發(fā)、NSOperation之間的優(yōu)先級(jí)。
GCD主要與block結(jié)合使用。代碼簡(jiǎn)潔高效。
GCD也可以實(shí)現(xiàn)復(fù)雜的多線(xiàn)程應(yīng)用，主要是建立個(gè)個(gè)線(xiàn)程時(shí)間的依賴(lài)關(guān)系這類(lèi)的情況，但是需要自己實(shí)現(xiàn)相比NSOperation要復(fù)雜。
具體使用哪個(gè)，依需求而定。從個(gè)人使用的感覺(jué)來(lái)看，比較合適的用法是：除了依賴(lài)關(guān)系盡量使用GCD，因?yàn)樘O(píng)果專(zhuān)門(mén)為GCD做了性能上面的優(yōu)化。
NSOprationQueue 與 GCD 的區(qū)別與選用
GCD和NSOperation的區(qū)別
CoreData 的使用，如何處理多線(xiàn)程問(wèn)題
如何設(shè)計(jì)圖片緩存？
有沒(méi)有自己設(shè)計(jì)過(guò)網(wǎng)絡(luò)控件？
怎么判斷某個(gè) cell 是否顯示在屏幕上
iOS基礎(chǔ)--UITableViewCell的重用機(jī)制
進(jìn)程和線(xiàn)程的區(qū)別
進(jìn)程和線(xiàn)程關(guān)系及區(qū)別
TCP 與 UDP 區(qū)別
這是兩個(gè)工作在TCP/IP協(xié)議傳輸層的兩個(gè)不同的協(xié)議，是用來(lái)傳輸數(shù)據(jù)用的。
TCP：Transfer Control Protocol，傳輸控制協(xié)議。
這是一個(gè)全雙工的、面向連接的、可靠的并且是精確控制的協(xié)議。
主要是用在那些實(shí)時(shí)性不強(qiáng)、但要求不能出錯(cuò)的應(yīng)用。比如說(shuō)，網(wǎng)頁(yè)的瀏覽、文件的下載（不是BT、電驢下載）、郵件的收發(fā)等場(chǎng)合，就需要TCP協(xié)議進(jìn)行傳輸（因?yàn)椴粫?huì)出錯(cuò)）。
當(dāng)然，它在網(wǎng)絡(luò)方面的開(kāi)銷(xiāo)是昂貴的。
UDP：User Datagram Protocol，用戶(hù)數(shù)據(jù)報(bào)協(xié)議。
這是一個(gè)不可靠的傳輸協(xié)議。因?yàn)樗慌判蛩l(fā)送的數(shù)據(jù)段、不關(guān)心這些數(shù)據(jù)段到達(dá)目的方的順序（所以它才不可靠），所以它在網(wǎng)絡(luò)的開(kāi)銷(xiāo)要比TCP小很多。因此UDP適合用在那些實(shí)時(shí)性強(qiáng)、允許出錯(cuò)的場(chǎng)合。
比如說(shuō)：即時(shí)通信（MSN、QQ），視頻，語(yǔ)音等方面
TCP 流量控制
滑動(dòng)窗口機(jī)制
比如發(fā)送端能發(fā)送5個(gè)數(shù)據(jù)，接收端也能收到5個(gè)數(shù)據(jù)，給個(gè)確認(rèn)（ack）給發(fā)送端，確認(rèn)我收到5個(gè)數(shù)據(jù)。如果網(wǎng)絡(luò)通信出現(xiàn)繁忙或者擁塞的時(shí)候，接收端只能收3個(gè)數(shù)據(jù)，接受端給個(gè)確認(rèn)我只能收3個(gè)數(shù)據(jù)，那么發(fā)送端就自動(dòng)調(diào)整發(fā)送的窗口為3，當(dāng)線(xiàn)路又恢復(fù)通暢的時(shí)候，接受端又可以受到5個(gè)數(shù)據(jù)，那它會(huì)給確認(rèn)給發(fā)送端，告訴它我的窗口為5，那發(fā)送端就把窗口又調(diào)整會(huì)5，這樣進(jìn)行流量控制的
2、比如說(shuō)發(fā)送端窗口為3，發(fā)送到接收端，接收端的接收窗口為5的話(huà)，接受數(shù)據(jù)，并且會(huì)給發(fā)送端一個(gè)ack（確認(rèn)）告訴發(fā)送端我的窗口為5，發(fā)送端收到確認(rèn)后會(huì)把自己的發(fā)送端窗口調(diào)整為5~~這樣就可以加速數(shù)據(jù)傳輸了
數(shù)組和鏈表的區(qū)別
鏈表和數(shù)組的區(qū)別在哪里?
從邏輯結(jié)構(gòu)來(lái)看
- 數(shù)組必須事先定義固定的長(zhǎng)度（元素個(gè)數(shù)），不能適應(yīng)數(shù)據(jù)動(dòng)態(tài)地增減的情況。當(dāng)數(shù)據(jù)增加時(shí)，可能超出原先定義的元素個(gè)數(shù)；當(dāng)數(shù)據(jù)減少時(shí)，造成內(nèi)存浪費(fèi)；數(shù)組可以根據(jù)下標(biāo)直接存取。
- 鏈表動(dòng)態(tài)地進(jìn)行存儲(chǔ)分配，可以適應(yīng)數(shù)據(jù)動(dòng)態(tài)地增減的情況，且可以方便地插入、刪除數(shù)據(jù)項(xiàng)。（數(shù)組中插入、刪除數(shù)據(jù)項(xiàng)時(shí)，需要移動(dòng)其它數(shù)據(jù)項(xiàng)，非常繁瑣）鏈表必須根據(jù)next指針找到下一個(gè)元素
從內(nèi)存存儲(chǔ)來(lái)看 - (靜態(tài))數(shù)組從棧中分配空間, 對(duì)于程序員方便快速,但是自由度小
- 鏈表從堆中分配空間, 自由度大但是申請(qǐng)管理比較麻煩
從上面的比較可以看出，如果需要快速訪(fǎng)問(wèn)數(shù)據(jù)，很少或不插入和刪除元素，就應(yīng)該用數(shù)組；相反， 如果需要經(jīng)常插入和刪除元素就需要用鏈表數(shù)據(jù)結(jié)構(gòu)了。
鏈表是動(dòng)態(tài)進(jìn)行存儲(chǔ)分配,不連續(xù)。數(shù)組是固定好數(shù)組長(zhǎng)度，存儲(chǔ)空間是靜態(tài)連續(xù)的。
UIView 生命周期
一、 大體流程：
(loadView/nib)文件來(lái)加載view到內(nèi)存-->viewDidLoad函數(shù)進(jìn)一步初始化這些view-->內(nèi)存不足時(shí)， 調(diào)用viewDidUnload函數(shù)釋放views-->當(dāng)需要使用view時(shí)又回到第一步
loadView：
永遠(yuǎn)不要主導(dǎo)調(diào)用這個(gè)函數(shù)。
viewController 會(huì)在view的property被請(qǐng)求并且當(dāng)前view值為nil時(shí)調(diào)用這個(gè)函數(shù)。如果你手動(dòng)創(chuàng)建view， 你應(yīng)該重載這個(gè)函數(shù)，切不要在重載的時(shí)候調(diào)用[super loadView]。
viewDidload:
這個(gè)函數(shù)的作用主要是讓你可以進(jìn)一步的初始化你的views。
viewDidLoad通常負(fù)責(zé)的是view及其子view被加載進(jìn)內(nèi)存之后的數(shù)據(jù)初始化的工作，即視圖的數(shù)據(jù)部分的初始化
viewDidUnLoad：
這個(gè)函數(shù)時(shí)viewDidLoad的對(duì)立函數(shù)。在程序內(nèi)存欠缺時(shí)，這個(gè)函數(shù)被controller帶哦用，來(lái)釋放他的view以及view相關(guān)的對(duì)象。由于controller通常保存著view以及相關(guān)的object的引用，所以你必須使用這個(gè)函數(shù)來(lái)放棄這些對(duì)象的所有權(quán)以便內(nèi)存回收，但不要釋放那些難以重建的數(shù)據(jù)
viewWillAppear:
視圖即將可見(jiàn)時(shí)調(diào)用，默認(rèn)情況下不執(zhí)行任何操作。
viewDidAppear：
視圖已完全過(guò)渡到屏幕上時(shí)調(diào)用
viewWillDisappear：
視圖被駁回時(shí)調(diào)用，覆蓋或以其他方式隱藏，默認(rèn)情況下不執(zhí)行任何操作
viewDidDisappear:
視圖被駁回后調(diào)用，覆蓋或以其他方式隱藏。默認(rèn)情況下不執(zhí)行任何操作
didReceiveMemoryWarning:
當(dāng)程序內(nèi)存過(guò)度時(shí)，系統(tǒng)會(huì)調(diào)用該方法
二、Controller和View的生命周期
這里指的View是指Controller的View。它作為Controler的屬性，生命周期在Controller的生命周期內(nèi)。就是說(shuō)你的Controller不能在view釋放前就釋放了。
當(dāng)你alloc并init了一個(gè)ViewController時(shí)，這個(gè)ViewController應(yīng)該是還沒(méi)有創(chuàng)建view的。ViewController的view是使用了lazyInit方式創(chuàng)建，就是說(shuō)你調(diào)用的view屬性的getter：［self view］。在getter里會(huì)先判斷view是否創(chuàng)建，如果沒(méi)有創(chuàng)建，那么會(huì)調(diào)用loadView來(lái)創(chuàng)建view。loadView完成時(shí)會(huì)繼續(xù)調(diào)用viewDidLoad。loadView和viewDidLoad的一個(gè)區(qū)別就是：loadView時(shí)還沒(méi)有view。而viewDidLoad時(shí)view以及創(chuàng)建好了。
當(dāng)view被添加其他view中之前時(shí)，會(huì)調(diào)用viewWillAppear，而之后會(huì)調(diào)用viewDidAppear。
當(dāng)view從其他view中移出之前時(shí)，會(huì)調(diào)用viewWillDisAppear，而之后會(huì)調(diào)用viewDidDisappear。
當(dāng)view不在使用，而且是disappeared，受到內(nèi)存警告時(shí)，那么viewController會(huì)將view釋放并將其指向nil。
三、代碼組織（如何設(shè)計(jì)良好的viewcontroller）
ViewController生命周期中有那么多函數(shù)，一個(gè)重要問(wèn)題就是什么代碼該寫(xiě)在什么地方。
1、init里不要出現(xiàn)創(chuàng)建view的代碼。良好的設(shè)計(jì)，在init里應(yīng)該只有相關(guān)數(shù)據(jù)的初始化，而且這些數(shù)據(jù)都是比較關(guān)鍵的數(shù)據(jù)。init里不要掉self.view，否則會(huì)導(dǎo)致viewcontroller創(chuàng)建view。（因?yàn)関iew是lazyinit的）。
2、loadView中只初始化view，一般用于創(chuàng)建比較關(guān)鍵的view如tableViewController的tabView，UINavigationController的navgationBar，不可掉用view的getter（在掉super loadView前），最好也不要初始化一些非關(guān)鍵的view。如果你是從nib文件中創(chuàng)建的viewController在這里一定要首先調(diào)用super的loadView方法，但建議不要重載這個(gè)方法。
3、viewDidLoad 這時(shí)候view已經(jīng)有了，最適合創(chuàng)建一些附加的view和控件了。
4、viewWillAppear 這個(gè)一般在view被添加到superview之前，切換動(dòng)畫(huà)之前調(diào)用。在這里可以進(jìn)行一些顯示前的處理。比如鍵盤(pán)彈出，一些特殊的過(guò)程動(dòng)畫(huà)（比如狀態(tài)條和navigationbar顏色）。
5、viewDidAppear 一般用于顯示后，在切換動(dòng)畫(huà)后，如果有需要的操作，可以在這里加入相關(guān)代碼。
6、viewDidUnload 這時(shí)候viewController的view已經(jīng)是nil了。由于這一般發(fā)生在內(nèi)存警告時(shí)，所以在這里你應(yīng)該將那些不在顯示的view釋放了。比如你在viewcontroller的view上加了一個(gè)label，而且這個(gè)label是viewcontroller的屬性，那么你要把這個(gè)屬性設(shè)置成nil，以免占用不必要的內(nèi)存，而這個(gè)label在viewDidLoad時(shí)會(huì)重新創(chuàng)建。
7、接下來(lái)看看ViewController中的view是如何被卸載的：
當(dāng)系統(tǒng)發(fā)出內(nèi)存警告時(shí)，會(huì)調(diào)用didReceiveMemoeryWarning方法，如果當(dāng)前有能被釋放的view，系統(tǒng)會(huì)調(diào)用viewWillUnload方法來(lái)釋放view，完成后調(diào)用viewDidUnload方法，至此，view就被卸載了。此時(shí)原本指向view的變量要被置為nil，具體操作是在viewDidUnload方法中調(diào)用self.myButton = nil;
小結(jié)一下：loadView和viewDidLoad的區(qū)別就是，loadView時(shí)view還沒(méi)有生成，viewDidLoad時(shí)，view已經(jīng)生成了，loadView只會(huì)被調(diào)用一次，而viewDidLoad可能會(huì)被調(diào)用多次（View可能會(huì)被多次加載），當(dāng)view被添加到其他view中之前，會(huì)調(diào)用viewWillAppear，之后會(huì)調(diào)用viewDidAppear。當(dāng)view從其他view中移除之前，調(diào)用viewWillDisAppear，移除之后會(huì)調(diào)用viewDidDisappear。當(dāng)view不再使用時(shí)，受到內(nèi)存警告時(shí)，ViewController會(huì)將view釋放并將其指向?yàn)閚il。
ViewController的生命周期中各方法執(zhí)行流程如下：init—>loadView—>viewDidLoad—>viewWillApper—>viewDidApper—>viewWillDisapper—>viewDidDisapper—>viewWillUnload->viewDidUnload—>dealloc
如果頁(yè)面 A 跳轉(zhuǎn)到 頁(yè)面 B，A 的 viewDidDisappear 方法和 B 的 viewDidAppear 方法哪個(gè)先調(diào)用？
1.A -->viewWillDisappear
2.B-->viewWillAppear
3.A-->viewDidDisappear
4.B-->viewDidAppear
ARC 的本質(zhì)
ARC是編譯器（時(shí)）特性，而不是運(yùn)行時(shí)特性，更不是垃圾回收器(GC)。
Automatic Reference Counting (ARC) is a compiler-level feature that simplifies the process of managing object lifetimes (memory management) in Cocoa applications.
ARC只是相對(duì)于MRC（Manual Reference Counting或稱(chēng)為非ARC，下文中我們會(huì)一直使用MRC來(lái)指代非ARC的管理方式）的一次改進(jìn)，但它和之前的技術(shù)本質(zhì)上沒(méi)有區(qū)別。具體信息可以參考ARC編譯器官方文檔。
iOS-ARC你看我就夠了
iOS開(kāi)發(fā)ARC內(nèi)存管理技術(shù)要點(diǎn)
如何找到字符串中第一個(gè)不重復(fù)的字符
如何在字符串里查找第一個(gè)不重復(fù)的字母,即只出現(xiàn)一次的最靠前的字母
哈希表如何處理沖突
介紹 block。
Block的內(nèi)存管理
ARC 會(huì)對(duì)代碼做什么優(yōu)化？
——比如 NSString *s2 = s1; s2 = nil 這樣的語(yǔ)句，可能就不會(huì)有 retain 和 release 方法了。
ARC 下內(nèi)存泄露的那些點(diǎn)
介紹一下 MVVM 和 RAC。
iOS MVVM+RAC 從框架到實(shí)戰(zhàn)
ViewModel層，就是View和Model層的粘合劑，他是一個(gè)放置用戶(hù)輸入驗(yàn)證邏輯，視圖顯示邏輯，發(fā)起網(wǎng)絡(luò)請(qǐng)求和其他各種各樣的代碼的極好的地方。說(shuō)白了，就是把原來(lái)ViewController層的業(yè)務(wù)邏輯和頁(yè)面邏輯等剝離出來(lái)放到ViewModel層。
View層，就是ViewController層，他的任務(wù)就是從ViewModel層獲取數(shù)據(jù)，然后顯示。
介紹自己用過(guò)哪些開(kāi)源庫(kù)。
——Masonry 和 SnapKit，AFNetWorking，MKNetworkKit，Alamofire，Mantle，SDWebImage
讀過(guò)某個(gè)庫(kù)的源碼么？
——扯了一點(diǎn) SDWebImage，后來(lái)被告知這個(gè)庫(kù)用了 runloop 來(lái)保證滑動(dòng)是加載數(shù)據(jù)的流暢性，自己看了源碼后表示沒(méi)有發(fā)現(xiàn)，唯一用到 runloop 地方是保證后臺(tái)線(xiàn)程一直跑，也有可能是我理解錯(cuò)了，如果錯(cuò)誤歡迎指正。
SDWebImage 下載了圖片后為什么要解碼？
——當(dāng)時(shí)蒙住了，面試官很 nice 的解釋了一下，說(shuō)是要把 png 文件建立一個(gè)什么內(nèi)存映射，目前還不太懂，有空研究一下。
不用臨時(shí)變量怎么實(shí)現(xiàn) swap(a, b)
——用加法或者異或都可以
二維有序數(shù)組查找數(shù)字
——?jiǎng)χ?offer 第 3題
億級(jí)日志中，查找登陸次數(shù)最多的十個(gè)用戶(hù)
——（不確定對(duì)不對(duì)，我的思路是）先用哈希表保存登陸次數(shù)和ID，然后用紅黑樹(shù)保存最大的十個(gè)數(shù)。劍指 offer 第 30題
簡(jiǎn)述排序算法
——快排，partion 函數(shù)的原理，堆排（不穩(wěn)定），歸并排序，基數(shù)排序。
說(shuō)說(shuō)你對(duì) OC 中 load 方法和 initialize 方法的異同。
——主要說(shuō)一下執(zhí)行時(shí)間，各自用途，沒(méi)實(shí)現(xiàn)子類(lèi)的方法會(huì)不會(huì)調(diào)用父類(lèi)的？
說(shuō)說(shuō)你對(duì) block 的理解。
—— 三種 block，棧上的自動(dòng)復(fù)制到堆上，block 的屬性修飾符是 copy，循環(huán)引用的原理和解決方案。
說(shuō)說(shuō)你對(duì) runtime 的理解。
——主要是方法調(diào)用時(shí)如何查找緩存，如何找到方法，找不到方法時(shí)怎么轉(zhuǎn)發(fā)，對(duì)象的內(nèi)存布局。
說(shuō)說(shuō)你對(duì) MVC 和 MVVM 的理解。
—— MVC 的 C 太臃腫，可以和 V 合并，變成 MVVM 中的 V，而 VM 用來(lái)將 M 轉(zhuǎn)化成 V 能用的數(shù)據(jù)。
野指針是什么，iOS 開(kāi)發(fā)中什么情況下會(huì)有野指針？
——野指針是不為 nil，但是指向已經(jīng)被釋放的內(nèi)存的指針，不知道什么時(shí)候會(huì)有，如果有知道的讀者還望提醒。
很長(zhǎng)一道題，讀了很久才讀懂，目測(cè)是 DFS，但是最后沒(méi)時(shí)間了，寫(xiě)了個(gè)思路。
把 "www.zhidao.baidu.com" 這樣的字符串改成 "com/baidu/zhidao/www"
——老題目了，劍指 offer 的，兩次逆序排列即可。
求數(shù)組中和為某個(gè)值的所有子數(shù)組，比如數(shù)組是 [5,5,10,2,3] 一共有四個(gè)子數(shù)組的和是 15，比如 [5,10]，[5,10]，[10,2,3]，[5,5,2,3]。
這個(gè)就是簡(jiǎn)單的遞歸了，分兩種情況，當(dāng)前位置的數(shù)字在子數(shù)組中，以及不在子數(shù)組中。
作者：kidzss鏈接：http://www.lxweimin.com/p/c12f90300077來(lái)源：簡(jiǎn)書(shū)著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。
