更新時間:2016年03月02日17時20分 來源:傳智播客 瀏覽次數(shù):
1、網(wǎng)絡(luò)多線程(★★★)
一、多線程的底層實現(xiàn)
1> 首先搞清楚什么是線程、什么是多線程
2> Mach是第一個以多線程方式處理任務(wù)的系統(tǒng),因此多線程的底層實現(xiàn)機(jī)制是基于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進(jìn)行加鎖保護(hù)
3> 如果異步操作要保證線程安全等問題, 盡量使用GCD(有些函數(shù)默認(rèn)就是安全的)
六、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)機(jī)制和適用范圍來描述)
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ù)器,并進(jìn)入SYN_SEND狀態(tài),等待服務(wù)器確認(rèn);
第二次握手:服務(wù)器收到syn包,必須確認(rèn)客戶的SYN(ack=j+1),同時自己也發(fā)送一個SYN包(syn=k),即SYN+ACK包,此時服務(wù)器進(jìn)入SYN_RECV狀態(tài);
第三次握手:客戶端收到服務(wù)器的SYN+ACK包,向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1),此包發(fā)送完畢,客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài),完成三次握手。
握手過程中傳送的包里不包含數(shù)據(jù),三次握手完畢后,客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下,TCP連接一旦建立,在通信雙方中的任何一方主動關(guān)閉連接之前,TCP 連接都將被一直保持下去。斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求,斷開過程需要經(jīng)過“四次握手”(過程就不細(xì)寫了,就是服務(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加以標(biāo)記。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é)議我很早前學(xué)習(xí)的時候大致看過,也寫在了學(xué)習(xí)教程里?“非正式協(xié)議概念其實就是類別的另一種表達(dá)方式“這里有一些你可能希望實現(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)”。