超全iOS面試資料，看完你還擔心面試嗎？

　　1、網(wǎng)絡(luò)多線程(★★★)

　　一、多線程的底層實現(xiàn)

　　1> 首先搞清楚什么是線程、什么是多線程

　　2> Mach是第一個以多線程方式處理任務(wù)的系統(tǒng)，因此多線程的底層實現(xiàn)機制是基于Mach的線程

　　3> 開發(fā)中很少用Mach級的線程，因為Mach級的線程沒有提供多線程的基本特征，線程之間是獨立的

　　4> 開發(fā)中實現(xiàn)多線程的方案

　　• C語言的POSIX接口：#include?

　　• OC的NSThread?

　　• C語言的GCD接口(性能最好，代碼更精簡)?

　　OC的NSOperation和NSOperationQueue(基于GCD)

　　二、線程間怎么通信？

　　http://blog.csdn.net/bawangxx/article/details/50546314

　　三、網(wǎng)絡(luò)圖片處理問題中怎么解決一個相同的網(wǎng)絡(luò)地址重復(fù)請求的問題？

　　利用字典(圖片地址為key，下載操作為value)

　　四、用NSOpertion和NSOpertionQueue處理A,B,C三個線程,要求執(zhí)行完A,B后才能執(zhí)行C,怎么做？

　　// 創(chuàng)建隊列

　　NSOperationQueue *queue = [[NSOperationQueue alloc] init];

　　// 創(chuàng)建3個操作

　　NSOperation *a = [NSBlockOperation blockOperationWithBlock:^{

　　NSLog(@”operationA---“);

　　}];

　　NSOperation *b = [NSBlockOperation blockOperationWithBlock:^{

　　NSLog(@”operationB---“);

　　}];

　　NSOperation *c = [NSBlockOperation blockOperationWithBlock:^{

　　NSLog(@”operationC---“);

　　}];

　　// 添加依賴

　　[c addDependency:a];

　　[c addDependency:b];

　　// 執(zhí)行操作

　　[queue addOperation:a];

　　[queue addOperation:b];

　　[queue addOperation:c];

　　五、列舉cocoa中常見對幾種多線程的實現(xiàn)，并談?wù)劧嗑€程安全的幾種解決辦法及多線程安全怎么控制？

　　1> 只在主線程刷新訪問UI

　　2> 如果要防止資源搶奪，得用synchronized進行加鎖保護

　　3> 如果異步操作要保證線程安全等問題, 盡量使用GCD(有些函數(shù)默認就是安全的)

　　六、GCD內(nèi)部怎么實現(xiàn)?

　　1> iOS和OS X的核心是XNU內(nèi)核，GCD是基于XNU內(nèi)核實現(xiàn)的

　　2> GCD的API全部在libdispatch庫中

　　3> GCD的底層實現(xiàn)主要有Dispatch Queue和Dispatch Source

　　Dispatch Queue ：管理block(操作) ?

　　DispatchSource ：處理事件

　　七、你用過NSOperationQueue么?如果用過或者了解的話，你為什么要使用NSOperationQueue，實現(xiàn)了什么?請描述它和GCD的區(qū)別和類似的地方(提示：可以從兩者的實現(xiàn)機制和適用范圍來描述)

　　1> GCD是純C語言的API，NSOperationQueue是基于GCD的OC版本封裝

　　2> GCD只支持FIFO的隊列，NSOperationQueue可以很方便地調(diào)整執(zhí)行順序、設(shè)置最大并發(fā)數(shù)量

　　3> NSOperationQueue可以在輕松在Operation間設(shè)置依賴關(guān)系，而GCD需要寫很多的代碼才能實現(xiàn)

　　4> NSOperationQueue支持KVO，可以監(jiān)測operation是否正在執(zhí)行(isExecuted)、是否結(jié)束(isFinished)，是否取消(isCanceld)

　　5> GCD的執(zhí)行速度比NSOperationQueue快

　　任務(wù)之間不太互相依賴：GCD

　　任務(wù)之間有依賴\或者要監(jiān)聽任務(wù)的執(zhí)行情況：NSOperationQueue

　　八、 既然提到GCD，那么問一下在使用GCD以及block時要注意些什么?它們兩是一回事兒么?block在ARC中和傳統(tǒng)的MRC中的行為和用法有沒有什么區(qū)別，需要注意些什么?

　　Block的使用注意：

　　1. block的內(nèi)存管理?

　　2. 防止循環(huán)retian?

　　非ARC(MRC)：__block?

　　ARC：__weak\__unsafe_unretained

　　九、在異步線程中下載很多圖片,如果失敗了,該如何處理?請結(jié)合RunLoop來談?wù)劷鉀Q方案.(提示:在異步線程中啟動一個RunLoop重新發(fā)送網(wǎng)絡(luò)請求,下載圖片)

　　1> 重新下載圖片

　　2> 下載完畢, 利用RunLoop的輸入源回到主線程刷新UIImageVIUew

　　十、Socket的實現(xiàn)原理及Socket之間是如何通信的

　　http://blog.csdn.net/jiajia4336/article/details/8798421

　　http://no001.blog.51cto.com/1142339/555344/

　　十一、 http協(xié)議的實現(xiàn)

　　http://www.blogjava.net/crespochen/archive/2008/10/22/235948.html

　　十二、什么是TCP連接的三次握手

　　第一次握手：客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進入SYN_SEND狀態(tài)，等待服務(wù)器確認；

　　第二次握手：服務(wù)器收到syn包，必須確認客戶的SYN(ack=j+1)，同時自己也發(fā)送一個SYN包(syn=k)，即SYN+ACK包，此時服務(wù)器進入SYN_RECV狀態(tài)；

　　第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED狀態(tài)，完成三次握手。

　　握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動關(guān)閉連接之前，TCP 連接都將被一直保持下去。斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求，斷開過程需要經(jīng)過“四次握手”(過程就不細寫了，就是服務(wù)器和客戶端交互，最終確定斷開)

　　十三、http協(xié)議的組成和特性

　　組成：http請求由三部分組成，分別是：請求行、消息報頭、請求正文特性：HTTP協(xié)議的主要特點可概括如下：1.支持客戶/服務(wù)器模式。2.簡單快速：客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標記。4.無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。

　　十四、在項目什么時候選擇使用GCD，什么時候選擇NSOperation?

　　項目中使用NSOperation的優(yōu)點是NSOperation是對線程的高度抽象，在項目中使用它，會使項目的程序結(jié)構(gòu)更好，子類化NSOperation的設(shè)計思路，是具有面向?qū)ο蟮膬?yōu)點(復(fù)用、封裝)，使得實現(xiàn)是多線程支持，而接口簡單，建議在復(fù)雜項目中使用。項目中使用GCD的優(yōu)點是GCD本身非常簡單、易用，對于不復(fù)雜的多線程操作，會節(jié)省代碼量，而Block參數(shù)的使用，會是代碼更為易讀，建議在簡單項目中使用。

　　十五、OC中的協(xié)議和java中的接口概念有何不同?

　　OBC中的代理有2層含義，官方定義為 formal和informal protocol。前者和Java接口一樣。?informal protocol中的方法屬于設(shè)計模式考慮范疇，不是必須實現(xiàn)的，但是如果有實現(xiàn)，就會改變類的屬性。?其實關(guān)于正式協(xié)議，類別和非正式協(xié)議我很早前學習的時候大致看過，也寫在了學習教程里?“非正式協(xié)議概念其實就是類別的另一種表達方式“這里有一些你可能希望實現(xiàn)的方法，你可以使用他們更好的完成工作”。?這個意思是，這些是可選的。比如我門要一個更好的方法，我們就會申明一個這樣的類別去實現(xiàn)。然后你在后期可以直接使用這些更好的方法。?這么看，總覺得類別這玩意兒有點像協(xié)議的可選協(xié)議。"?現(xiàn)在來看，其實protocal已經(jīng)開始對兩者都統(tǒng)一和規(guī)范起來操作，因為資料中說“非正式協(xié)議使用interface修飾“，?現(xiàn)在我們看到協(xié)議中兩個修飾詞：“必須實現(xiàn)(@requied)”和“可選實現(xiàn)(@optional)”。