1、OC中創(chuàng)建線程的方法是什么？如果指定在主線程中執(zhí)行代碼尝艘？如何延時執(zhí)行代碼∽巳荆【難度系數(shù)★★】
1）創(chuàng)建線程的方法
NSThread
NSOperationQueue和NSOperation
GCD
2）主線程中執(zhí)行代碼
[self performSelectorOnMainThread: withObject: waitUntilDone:];
[self performSelector: onThread:[NSThread mainThread] withObject: waitUntilDone:];
dispatch_async(dispatch_get_main_queue(), ^{
});
3）延時執(zhí)行
double delayInSeconds = 2.0;
dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW,
(int64_t)(delayInSeconds * NSEC_PER_SEC));
dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
});
[self performSelector: withObject: afterDelay:];
[NSTimer scheduledTimerWithTimeInterval: target: selector: userInfo: repeats:];
2背亥、多線程是什么【難度系數(shù)★】
多線程是個復雜的概念，按字面意思是同步完成多項任務(wù)，提高了資源的使用效率狡汉，從硬件娄徊、操作系統(tǒng)、應(yīng)用軟件不同的角度去看盾戴，多線程被賦予不同的內(nèi)涵寄锐，對于硬件，現(xiàn)在市面上多數(shù)的CPU都是多核的尖啡，多核的CPU運算多線程更為出色;從操作系統(tǒng)角度橄仆，是多任務(wù)，現(xiàn)在用的主流操作系統(tǒng)都是多任務(wù)的衅斩，可以一邊聽歌沿癞、一邊寫博客;對于應(yīng)用來說，多線程可以讓應(yīng)用有更快的回應(yīng)矛渴，可以在網(wǎng)絡(luò)下載時椎扬，同時響應(yīng)用戶的觸摸操作。在iOS應(yīng)用中具温，對多線程最初的理解蚕涤，就是并發(fā)，它的含義是原來先做燒水铣猩，再摘菜揖铜，再炒菜的工作，會變成燒水的同時去摘菜达皿，最后去炒菜
3天吓、iOS 中的多線程【難度系數(shù)★★】
iOS中的多線程，是Cocoa框架下的多線程峦椰，通過Cocoa的封裝龄寞，可以讓我們更為方便的使用線程，做過C++的同學可能會對線程有更多的理解汤功，比如線程的創(chuàng)立物邑，信號量、共享變量有認識滔金，Cocoa框架下會方便很多色解，它對線程做了封裝，有些封裝餐茵，可以讓我們創(chuàng)建的對象科阎，本身便擁有線程，也就是線程的對象化抽象忿族，從而減少我們的工程锣笨，提供程序的健壯性刚梭。
GCD是(Grand Central Dispatch)的縮寫
，從系統(tǒng)級別提供的一個易用地多線程類庫票唆，具有運行時的特點，能充分利用多核心硬件屹徘。GCD的API接口為C語言的函數(shù)走趋，函數(shù)參數(shù)中多數(shù)有Block，關(guān)于Block的使用參看這里噪伊，為我們提供強大的“接口”簿煌，對于GCD的使用參見本文
NSOperation與Queue
NSOperation是一個抽象類，它封裝了線程的細節(jié)實現(xiàn)鉴吹，我們可以通過子類化該對象姨伟，加上NSQueue來同面向?qū)ο蟮乃季S，管理多線程程序豆励。具體可參看這里：一個基于NSOperation的多線程網(wǎng)絡(luò)訪問的項目夺荒。
NSThread
NSThread是一個控制線程執(zhí)行的對象，它不如NSOperation抽象良蒸，通過它我們可以方便的得到一個線程技扼，并控制它。但NSThread的線程之間的并發(fā)控制嫩痰，是需要我們自己來控制的剿吻，可以通過NSCondition實現(xiàn)。
在Cocoa的框架下串纺，通知丽旅、Timer和異步函數(shù)等都有使用多線程，(待補充).
4纺棺、在項目什么時候選擇使用GCD榄笙，什么時候選擇NSOperation?【難度系數(shù)★★】
項目中使用NSOperation的優(yōu)點是NSOperation是對線程的高度抽象，在項目中使用它祷蝌，會使項目的程序結(jié)構(gòu)更好办斑，子類化NSOperation的設(shè)計思路，是具有面向?qū)ο蟮膬?yōu)點(復用杆逗、封裝)乡翅，使得實現(xiàn)是多線程支持，而接口簡單罪郊，建議在復雜項目中使用蠕蚜。
項目中使用GCD的優(yōu)點是GCD本身非常簡單、易用悔橄，對于不復雜的多線程操作靶累，會節(jié)省代碼量腺毫，而Block參數(shù)的使用，會是代碼更為易讀挣柬，建議在簡單項目中使用
5潮酒、NSThread,NSOperation,GCD【難度系數(shù)★★】
NSThread,NSOperation,GCD是IOS中使用多線程的三種方式之一。他們各有優(yōu)缺點邪蛔。抽象層次是從低到高的急黎，抽象度越高的使用越簡單。
NSThread，缺點：需要自己維護線程的生命周期和線程的同步和互斥，但是這些都需要耗費系統(tǒng)的資源捎迫。優(yōu)點：比其它兩個更輕。
NSOperation,優(yōu)點：不需要自己管理線程的生命周期和線程的同步和互斥等故源。只是需要關(guān)注自己的業(yè)務(wù)邏輯處理，需要和NSOperationQueue一起使用汞贸。
GCD绳军，是Apple開發(fā)的一個多核編程解決方法，優(yōu)點：比前面兩者更高效更強大
6矢腻、NSRunLoop 和NSOperationQueue【難度系數(shù)★★】
NSRunLoop
是所有要監(jiān)視的輸入源和定時源以及要通知的注冊觀察者的集合.用來處理諸如鼠標删铃，鍵盤事件等的輸入源。每一個線程擁有自己的RunLoop有系統(tǒng)自動創(chuàng)建踏堡。你不應(yīng)該自己去創(chuàng)建猎唁，只能獲取。一般不會用NSRunLoop,因為它不是線程安全的顷蟆。一般都用CFRunLoop诫隅，這個是線程安全的，是一種消息處理模式帐偎，我們一般不用進行處理逐纬。
NSOperationQueue時一個管理NSOperation的隊列。我們會把NSOperation放入queue中進行管理
7削樊、添加手勢的方式（gesture和touches事件）【難度系數(shù)★★】
1）自己重載實現(xiàn)touchMoved豁生，touchBegin，touchEnd漫贞，touchCanceled事件甸箱。
2）通過UIGestureRecongnizer添加AddGestureRecognier事件。該方式方便添加一些諸如點擊迅脐，雙擊芍殖，拖動等基本的手勢事件
8、常用的開源框架【難度系數(shù)★】
網(wǎng)絡(luò)框架： AFNetworking,coocaHttpServer等谴蔑。
進度條：SVprogressHUD,MBprogressHUD,
工具類：SSToolKit等豌骏。
分享類：ShareKit等
日志框架：log4j龟梦，cocoa lumberJack?等
9、常見的加解密方式(rsa,aes,md5)【難度系數(shù)★★】
常見的加解密方式有：
RSA：基于公鑰和私鑰的非對程加密算法窃躲。適用范圍廣计贰。
AES：是一種對程加密的流行方式。加密涉及矩陣運算蒂窒。
MD5:將任意長度的“字節(jié)串”變換成一個128bit的大整數(shù)躁倒，并且它是一個不可逆的字符串變換算法
10、我們說的oc是動態(tài)運行時語言是什么意思?【難度系數(shù)★★★】
多態(tài)刘绣。 主要是將數(shù)據(jù)類型的確定由編譯時，推遲到了運行時挣输。
這個問題其實淺涉及到兩個概念纬凤，運行時和多態(tài)。
簡單來說撩嚼，運行時機制使我們直到運行時才去決定一個對象的類別停士，以及調(diào)用該類別對象指定方法。
多態(tài)：不同對象以自己的方式響應(yīng)相同的消息的能力叫做多態(tài)完丽。意思就是假設(shè)生物類(life)都用有一個相同的方法-eat;
那人類屬于生物恋技，豬也屬于生物，都繼承了life后逻族，實現(xiàn)各自的eat蜻底，但是調(diào)用是我們只需調(diào)用各自的eat方法。
也就是不同的對象以自己的方式響應(yīng)了相同的消息(響應(yīng)了eat這個選擇器)聘鳞。
因此也可以說薄辅，運行時機制是多態(tài)的基礎(chǔ)?
11、什么是推送消息?【難度系數(shù)★】
推送通知更是一種技術(shù)抠璃。
簡單點就是客戶端獲取資源的一種手段站楚。
普通情況下，都是客戶端主動的pull搏嗡。
推送則是服務(wù)器端主動push窿春。
12、什么是沙盒模型采盒？哪些操作是屬于私有api范疇?【難度系數(shù)★★】
某個iphone工程進行文件操作有此工程對應(yīng)的指定的位置旧乞，不能逾越。
iphone沙箱模型的有四個文件夾documents磅氨，tmp良蛮，app，Library悍赢，永久數(shù)據(jù)存儲一般放documents文件夾决瞳，得到模擬器的路徑的可使用NSHomeDirectory()方法货徙。Nsuserdefaults保存的文件在tmp文件夾里
13、HTTP協(xié)議中皮胡，POST和GET的區(qū)別是什么痴颊？【難度系數(shù)★★】
1).GET 方法
GET 方法提交數(shù)據(jù)不安全，數(shù)據(jù)置于請求行屡贺，客戶端地址欄可見;
GET 方法提交的數(shù)據(jù)大小有限
GET 方法不可以設(shè)置書簽
2).POST 方法
POST 方法提交數(shù)據(jù)安全蠢棱，數(shù)據(jù)置于消息主體內(nèi)，客戶端不可見
POST 方法提交的數(shù)據(jù)大小沒有限制
POST 方法可以設(shè)置書簽
14甩栈、GCD有哪幾種Queue?你自己建立過串行的Queue嗎泻仙？背后的線程模型是什么樣的？【難度系數(shù)★★】
globalQueue和mainQueue
建立過量没，歡迎頁完成一系列的動畫后玉转，彈出登錄框
歡迎頁動畫并行執(zhí)行，前者和后者串行執(zhí)行
主隊列dispatch_main_queue();串行更新UI
全局隊列dispatch_global_queue();并行殴蹄，四個優(yōu)先級：background究抓，low，default袭灯，high
自定義隊列dispatch_queue_t queue;可以自定義是并行DISPATCH_QUEUE_CONCURRENT或DISPATCH_QUEUE_SERIAL
15刺下、TCP和UDP有什么區(qū)別？【難度系數(shù)★★】
1）TCP---傳輸控制協(xié)議,提供的是面向連接稽荧、可靠的字節(jié)流服務(wù)橘茉。當客戶和服務(wù)器彼此交換數(shù)據(jù)前，必須先在雙方之間建立一個TCP連接姨丈，之后才能傳輸數(shù)據(jù)捺癞。TCP提供超時重發(fā)，丟棄重復數(shù)據(jù)构挤，檢驗數(shù)據(jù)髓介，流量控制等功能，保證數(shù)據(jù)能從一端傳到另一端筋现。
2）UDP---用戶數(shù)據(jù)報協(xié)議唐础，是一個簡單的面向數(shù)據(jù)報的運輸層協(xié)議。UDP不提供可靠性矾飞，它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報發(fā)送出去一膨，但是并不能保證它們能到達目的地。由于UDP在傳輸數(shù)據(jù)報前不用在客戶和服務(wù)器之間建立一個連接洒沦，且沒有超時重發(fā)等機制豹绪，故而傳輸速度很快
3）TCP是面向連接的，建立連接需要經(jīng)歷三次握手申眼，保證數(shù)據(jù)正確性和數(shù)據(jù)順序
UDP是非連接的協(xié)議瞒津，傳送數(shù)據(jù)受生成速度蝉衣，傳輸帶寬等限制，可能造成丟包
UDP一臺服務(wù)端可以同時向多個客戶端傳輸信息
TCP報頭體積更大巷蚪，對系統(tǒng)資源要求更多
16病毡、說說響應(yīng)鏈【難度系數(shù)★★★】
事件響應(yīng)鏈。包括點擊事件屁柏，畫面刷新事件等啦膜。在視圖棧內(nèi)從上至下，或者從下之上傳播淌喻。
可以說點事件的分發(fā)僧家，傳遞以及處理。具體可以去看下touch事件這塊裸删。因為問的太抽象化了
嚴重懷疑題目出到越后面就越籠統(tǒng)八拱。
可以從責任鏈模式，來講通過事件響應(yīng)鏈處理烁落，其擁有的擴展性
17乘粒、http和scoket通信的區(qū)別豌注∩怂【難度系數(shù)★★★】
http是客戶端用http協(xié)議進行請求，發(fā)送請求時候需要封裝http請求頭轧铁，并綁定請求的數(shù)據(jù)每聪，服務(wù)器一般有web服務(wù)器配合（當然也非絕對）。
http請求方式為客戶端主動發(fā)起請求齿风，服務(wù)器才能給響應(yīng)药薯，一次請求完畢后則斷開連接，以節(jié)省資源救斑。服務(wù)器不能主動給客戶端響應(yīng)（除非采取http長連接
技術(shù)）童本。iphone主要使用類是NSUrlConnection。
scoket是客戶端跟服務(wù)器直接使用socket“套接字”進行連接脸候，并沒有規(guī)定連接后斷開穷娱，所以客戶端和服務(wù)器可以保持連接通道，雙方
都可以主動發(fā)送數(shù)據(jù)运沦。一般在游戲開發(fā)或股票開發(fā)這種要求即時性很強并且保持發(fā)送數(shù)據(jù)量比較大的場合使用泵额。主要使用類是CFSocketRef。
18携添、什么是push嫁盲。【難度系數(shù)★★】
客戶端程序留下后門端口烈掠，客戶端總是監(jiān)聽針對這個后門的請求羞秤，于是 服務(wù)器可以主動像這個端口推送消息缸托。
19、簡述內(nèi)存分區(qū)情況【難度系數(shù)★★★】
1).代碼區(qū)：存放函數(shù)二進制代碼
2).數(shù)據(jù)區(qū)：系統(tǒng)運行時申請內(nèi)存并初始化锥腻，系統(tǒng)退出時由系統(tǒng)釋放嗦董。存放全局變量、靜態(tài)變量瘦黑、常量
3).堆區(qū)：通過malloc等函數(shù)或new等操作符動態(tài)申請得到京革，需程序員手動申請和釋放
4).棧區(qū)：函數(shù)模塊內(nèi)申請，函數(shù)結(jié)束時由系統(tǒng)自動釋放幸斥。存放局部變量匹摇、函數(shù)參數(shù)
20、runloop和線程有什么關(guān)系甲葬？【難度系數(shù)★★★】
總的說來廊勃，Run
loop，正如其名经窖，loop表示某種循環(huán)坡垫，和run放在一起就表示一直在運行著的循環(huán)。實際上画侣，run loop和線程是緊密相連的冰悠，可以這樣說run
loop是為了線程而生，沒有線程配乱，它就沒有存在的必要溉卓。Run loops是線程的基礎(chǔ)架構(gòu)部分， Cocoa 和 CoreFundation
都提供了 run loop 對象方便配置和管理線程的 run loop （以下都以 Cocoa 為例）搬泥。每個線程桑寨，包括程序的主線程（
main thread ）都有與之相應(yīng)的 run loop 對象。
21忿檩、dispatch_barrier_async的作用是什么尉尾？【難度系數(shù)★★★】
1）在并行隊列中，為了保持某些任務(wù)的順序燥透，需要等待一些任務(wù)完成后才能繼續(xù)進行沙咏，使用 barrier 來等待之前任務(wù)完成，避免數(shù)據(jù)競爭等問題兽掰。
dispatch_barrier_async函數(shù)會等待追加到Concurrent Dispatch Queue并行隊列中的操作全部執(zhí)行完之后芭碍，然后再執(zhí)行dispatch_barrier_async函數(shù)追加的處理，等dispatch_barrier_async追加的處理執(zhí)行結(jié)束之后孽尽，Concurrent
Dispatch Queue才恢復之前的動作繼續(xù)執(zhí)行窖壕。
2）打個比方：比如你們公司周末跟團旅游，高速休息站上，司機說：大家都去上廁所瞻讽，速戰(zhàn)速決鸳吸，上完廁所就上高速。超大的公共廁所速勇，大家同時去晌砾，程序猿很快就結(jié)束了，但程序媛就可能會慢一些烦磁，即使你第一個回來养匈，司機也不會出發(fā)，司機要等待所有人都回來后都伪，才能出發(fā)呕乎。dispatch_barrier_async函數(shù)追加的內(nèi)容就如同
“上完廁所就上高速”這個動作。
（注意：使用dispatch_barrier_async陨晶，該函數(shù)只能搭配自定義并行隊列dispatch_queue_t使用猬仁。不能使用：dispatch_get_global_queue，否則dispatch_barrier_async的作用會和dispatch_async的作用一模一樣先誉。
）
22湿刽、蘋果為什么要廢棄dispatch_get_current_queue？【難度系數(shù)★★】
dispatch_get_current_queue容易造成死鎖
23褐耳、iOS平臺怎么做數(shù)據(jù)的持久化诈闺？coredata和sqlite有無必然聯(lián)系【難度系數(shù)★★】
（1）屬性列表NSString，NSArray漱病，NSDictionary买雾，NSData調(diào)用writeToFile方法寫本地
（2）NSKeyedAarchiver歸檔把曼，解檔來保存數(shù)據(jù)
（3）數(shù)據(jù)庫sqlite的第三方FMDB保存數(shù)據(jù)
（4）coredata保存數(shù)據(jù)
（5）coredata底層可以用sqlite來實現(xiàn)杨帽，coredata相當于封裝了sqlite的底層實現(xiàn)，給用戶一個直接調(diào)用的接口嗤军。
24注盈、Sqlite和coredata的區(qū)別：【難度系數(shù)★★】
簡單的答復 coreData提供ORM(Object Relationships
Mapping)解決方案，能直接生成對應(yīng)的model對象文件叙赚，并且封裝了一些底層操作老客，簡化了使用，而sqlite要使用c調(diào)用對應(yīng)的api震叮，并進行一些底層的封裝操作胧砰，且model對象文件要自己寫過，代碼量會稍大一些苇瓣，其他感覺差不太多
詳細來說有以下幾點：
（1）使用方便性尉间。實際上，一個成熟的工程中一定是對數(shù)據(jù)持久化進行了封裝的，因此底層使用的到底是core data還是sqlite哲嘲，不應(yīng)該被業(yè)務(wù)邏輯開發(fā)者關(guān)心贪薪。因此，即使習慣寫SQL查詢的人眠副，也應(yīng)該避免在業(yè)務(wù)邏輯中直接編寫SQL語句画切。
（2）存儲性能，在寫入性能上囱怕，因為都是使用的sqlite格式作為磁盤存儲格式霍弹，因此其性能是一樣的，如果你覺得用core
data寫的慢娃弓，很可能是你用sqlite的時候?qū)懙拿織l數(shù)據(jù)的內(nèi)容沒有core
data時多庞萍，或者是你批量寫入的時候每寫入一條就調(diào)用了一次save。
（3）查詢性能忘闻，core
data因為要兼容多種后端格式钝计，因此查詢時，其可用的語句比直接使用sqlite少齐佳，因此有些fetch實際上不是在sqlite中執(zhí)行的私恬。但這樣未必會降低查詢效率。因為iPhone的flash
memory速度還是很快的炼吴。我的經(jīng)驗是大部分時候本鸣，在內(nèi)存不是很緊張時，直接fetch一個entity的所有數(shù)據(jù)然后在內(nèi)存中做filter往往比使用predicate在fetch時過濾更快硅蹦。如果你覺的查詢慢荣德，很可能是查詢方式有問題，可以把core
data的debug模式打開童芹，看一下到底執(zhí)行了多少SQL語句涮瞻，相信其中大部分是可以通過改寫core data的調(diào)用方式避免的。
（4）core data的一個比較大的痛點是多人合作開發(fā)的時候假褪，管理coredata的模型需要很小心署咽，尤其是合并的時候，他的data model是XML格式的生音，手動resolve比較煩心宁否。
（5）core data還有其他sql所不具備的優(yōu)點，比如對undo的支持缀遍，多個context實現(xiàn)sketchbook類似的功能慕匠。為ManagedObject優(yōu)化的row cash等。
另外core data是支持多線程的域醇，但需要thread confinement的方式實現(xiàn),使用了多線程之后可以最大化的防止阻塞主線程台谊。
25冤寿、談?wù)剬Χ嗑€程的理解【難度系數(shù)★★】
多線程可以實現(xiàn)一個app中同時執(zhí)行多個代碼路徑。
多線程的優(yōu)勢是
1）多個線程可提高app的感知響應(yīng)青伤。
2）多個線程可提高應(yīng)用程序在多核系統(tǒng)上的實時性能督怜。
多線程的弊端
1）多線程帶來好處的同時也會增加代碼的復雜度，每個線程需要和其他線程協(xié)調(diào)其行為狠角，以防止它破壞應(yīng)用程序的狀態(tài)信息号杠。因為多線程共享內(nèi)存空間，訪問相同的數(shù)據(jù)結(jié)構(gòu)丰歌，如果有兩個線程試圖同時處理相同的數(shù)據(jù)結(jié)構(gòu)姨蟋，一個線程有可能覆蓋另一個線程的改動導致破壞該數(shù)據(jù)結(jié)構(gòu)。
2）多線程速度快的同時增加了內(nèi)存消耗和CPU占用
26立帖、如何管理數(shù)據(jù)的安全性【難度系數(shù)★★】
參數(shù)post傳遞眼溶，關(guān)鍵字段加密處理
iOS數(shù)據(jù)加密方式有：
md5加密
NSString *md5 = [CJMD5 md5HexDigest:password];
aes加密
NSString *encryptedData = [AESCrypt encrypt:userName password:password];//加密
NSString *message = [AESCrypt decrypt:encryptedData password:password]; //解密
base64加密
+ (NSString*)encodeBase64String:(NSString *)input;
+ (NSString*)decodeBase64String:(NSString *)input;
+ (NSString*)encodeBase64Data:(NSData *)data;
+ (NSString*)decodeBase64Data:(NSData *)data;
27、遠程推送的工作機制【難度系數(shù)★★】
(1)蘋果設(shè)備注冊遠程通知晓勇，從蘋果請求deviceToken
(2)蘋果設(shè)備向業(yè)務(wù)邏輯服務(wù)器上傳deviceToken值堂飞，區(qū)分設(shè)備
(3)業(yè)務(wù)邏輯服務(wù)器向蘋果發(fā)送推送通知消息請求，
(4)蘋果根據(jù)deviceToken區(qū)分不同的手機設(shè)備推送給指定的iOS客戶端绑咱。
28绰筛、多線程GCD，有三個事件abc描融，想要處理完ab后再執(zhí)行c铝噩，要怎么做【難度系數(shù)★★★】
（1）比較笨的一種方法，abc皆順序執(zhí)行dispatch_async(dispatch_get_global_queue(0,0), ^{
//事件a
//事件b
//事件c
});
（2）利用分組操作窿克，ab在不同線程執(zhí)行骏庸，最后都執(zhí)行完了后再執(zhí)行c
dispatch_group_tgroup =dispatch_group_create();
dispatch_group_async(group,dispatch_get_global_queue(0,0), ^{
//事件a
});
dispatch_group_async(group,dispatch_get_global_queue(0,0), ^{
//事件b
});
dispatch_group_notify(group,dispatch_get_global_queue(0,0), ^{
//事件c
});
（3）利用基礎(chǔ)知識，自定義實現(xiàn)此功能年叮。相當于自己實現(xiàn)了分組的底層
__blockintcount =0;
dispatch_async(dispatch_get_global_queue(0,0), ^{
//事件a
count++;
if(count ==2)
{
//事件c
}
});
dispatch_async(dispatch_get_global_queue(0,0), ^{
//事件b
count++;
if(count ==2)
{
//事件c
}
});
29具被、單例是線程安全的嗎？【難度系數(shù)★★】
（1）單例在之前的創(chuàng)建過程中是
@synchronized(self)
{
if(!_configs)
{
_configs= [[XRConfigsalloc]init];
}
}
加了同步代碼谋右，所以同一時刻只會有一個線程調(diào)用創(chuàng)建代碼硬猫，所以是線程安全的
（2）單例現(xiàn)在的創(chuàng)建過程是
staticdispatch_once_tonceToken;
dispatch_once(&onceToken, ^{
_configs= [[XRConfigsalloc]init];
});
return_configs;
用GCD來控制他只執(zhí)行一次补箍，所以也是線程安全的
(3) 單例中方法如果想要線程安全可以用dispatch_queue_create命令來創(chuàng)建一個單獨的線程改执，然后單例中所有方法都在這個串行線程中執(zhí)行，這樣可以保證執(zhí)行方法是線程安全的坑雅。
30辈挂、寫出異步加載復數(shù)網(wǎng)絡(luò)圖片的原理比如SDWebImage【難度系數(shù)★★★★】
SDWebImage 加載圖片的流程：
1.入口 setImageWithURL:placeholderImage:options: 會先把 placeholderImage 顯示，然后 SDWebImageManager 根據(jù) URL 開始處理圖片裹粤。
2.進入
SDWebImageManager-downloadWithURL:delegate:options:userInfo:终蒂，交給
SDImageCache 從緩存查找圖片是否已經(jīng)下載 queryDiskCacheForKey:delegate:userInfo:.
3.先從內(nèi)存圖片緩存查找是否有圖片，如果內(nèi)存中已經(jīng)有圖片緩存，SDImageCacheDelegate 回調(diào) imageCache:didFindImage:forKey:userInfo: 到 SDWebImageManager拇泣。
4.SDWebImageManagerDelegate 回調(diào) webImageManager:didFinishWithImage: 到 UIImageView+WebCache 等前端展示圖片噪叙。
5.如果內(nèi)存緩存中沒有，生成 NSInvocationOperation 添加到隊列開始從硬盤查找圖片是否已經(jīng)緩存霉翔。
6.根據(jù) URLKey 在硬盤緩存目錄下嘗試讀取圖片文件睁蕾。這一步是在 NSOperation 進行的操作，所以回主線程進行結(jié)果回調(diào) notifyDelegate:债朵。
7.如果上一操作從硬盤讀取到了圖片子眶，將圖片添加到內(nèi)存緩存中（如果空閑內(nèi)存過小，會先清空內(nèi)存緩存）序芦。SDImageCacheDelegate 回調(diào) imageCache:didFindImage:forKey:userInfo:臭杰。進而回調(diào)展示圖片。
8.如果從硬盤緩存目錄讀取不到圖片谚中，說明所有緩存都不存在該圖片渴杆，需要下載圖片，回調(diào) imageCache:didNotFindImageForKey:userInfo:宪塔。
9.共享或重新生成一個下載器 SDWebImageDownloader 開始下載圖片将塑。
10.圖片下載由 NSURLConnection 來做，實現(xiàn)相關(guān) delegate 來判斷圖片下載中蝌麸、下載完成和下載失敗点寥。
11.connection:didReceiveData: 中利用 ImageIO 做了按圖片下載進度加載效果。
12.connectionDidFinishLoading: 數(shù)據(jù)下載完成后交給 SDWebImageDecoder 做圖片解碼處理来吩。
13.圖片解碼處理在一個 NSOperationQueue 完成敢辩，不會拖慢主線程 UI。如果有需要對下載的圖片進行二次處理弟疆，最好也在這里完成戚长，效率會好很多。
14.在主線程 notifyDelegateOnMainThreadWithInfo: 宣告解碼完成怠苔，imageDecoder:didFinishDecodingImage:userInfo: 回調(diào)給 SDWebImageDownloader同廉。
31、獲取項目根路徑柑司，并在其下創(chuàng)建一個名稱為userData的目錄迫肖。【難度系數(shù)★】
NSString*userDataPath = [NSHomeDirectory()stringByAppendingString:@"/userData"];
[[NSFileManagerdefaultManager]createDirectoryAtPath:userDataPathwithIntermediateDirectories:nilattributes:nilerror:nil];
簡單來說
[NSFileManagerdefaultManager]調(diào)用它的createDirectoryAtPath的方法來創(chuàng)建目錄
32攒驰、XML蟆湖、HTML語言區(qū)別【難度系數(shù)★★】
1）XML與HTML的設(shè)計區(qū)別是：XML的核心是數(shù)據(jù)泪掀，其重點是數(shù)據(jù)的內(nèi)容仔掸。而HTML 被設(shè)計用來顯示數(shù)據(jù)，其重點是數(shù)據(jù)的顯示。
2）XML和HTML語法區(qū)別：HTML的標記不是所有的都需要成對出現(xiàn)量九，XML則要求所有的標記必須成對出現(xiàn)仿耽；HTML標記不區(qū)分大小寫获搏，XML則 大小敏感,即區(qū)分大小寫怖喻。
33、HTTP協(xié)議詳解【難度系數(shù)★★★】
HTTP是一個屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議充蓝，由于其簡捷晦鞋、快速的方式，適用于分布式超媒體信息系統(tǒng)棺克。目前在WWW中使用的是HTTP/1.0的第六版悠垛，HTTP/1.1的規(guī)范化工作正在進行之中。
http（超文本傳輸協(xié)議）是一個基于請求與響應(yīng)模式的娜谊、無狀態(tài)的确买、應(yīng)用層的協(xié)議，成唇裕基于TCP的連接方式湾趾，HTTP1.1版本中給出一種持續(xù)連接的機制，絕大多數(shù)的Web開發(fā)派草，都是構(gòu)建在HTTP協(xié)議之上的Web應(yīng)用搀缠。
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ù)處理需要前面的信息睦焕，則它必須重傳藐握，這樣可能導致每次連接傳送的數(shù)據(jù)量增大。另一方面垃喊，在服務(wù)器不需要先前信息時它的應(yīng)答就較快猾普。
34、HTTP三次握手【難度系數(shù)★★★】
TCP（Transmission Control
Protocol本谜，傳輸控制協(xié)議）是基于連接的協(xié)議初家，也就是說，在正式收發(fā)數(shù)據(jù)前乌助，必須和對方建立可靠的連接溜在。一個TCP連接必須要經(jīng)過三次“對話”才能建立起來，我們來看看這三次對話的簡單過程：1.主機A向主機B發(fā)出連接請求數(shù)據(jù)包他托；2.主機B向主機A發(fā)送同意連接和要求同步（同步就是兩臺主機一個在發(fā)送掖肋，一個在接收，協(xié)調(diào)工作）的數(shù)據(jù)包赏参；3.主機A再發(fā)出一個數(shù)據(jù)包確認主機B的要求同步：“我現(xiàn)在就發(fā)志笼，你接著吧！”把篓，這是第三次對話纫溃。三次“對話”的目的是使數(shù)據(jù)包的發(fā)送和接收同步，經(jīng)過三次“對話”之后韧掩，主機A才向主機B正式發(fā)送數(shù)據(jù)紊浩。
第一次握手：客戶端發(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)膘融，完成三次握手。
35祭玉、利用Socket建立網(wǎng)絡(luò)連接的步驟【難度系數(shù)★★★】
建立Socket連接至少需要一對套接字氧映，其中一個運行于客戶端，稱為ClientSocket 脱货，另一個運行于服務(wù)器端岛都，稱為ServerSocket 律姨。
套接字之間的連接過程分為三個步驟：服務(wù)器監(jiān)聽，客戶端請求臼疫，連接確認择份。
1。服務(wù)器監(jiān)聽：服務(wù)器端套接字并不定位具體的客戶端套接字烫堤，而是處于等待連接的狀態(tài)荣赶，實時監(jiān)控網(wǎng)絡(luò)狀態(tài)，等待客戶端的連接請求鸽斟。
2拔创。客戶端請求：指客戶端的套接字提出連接請求富蓄，要連接的目標是服務(wù)器端的套接字剩燥。為此，客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字格粪，指出服務(wù)器端套接字的地址和端口號躏吊，然后就向服務(wù)器端套接字提出連接請求。
3帐萎。連接確認：當服務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時比伏，就響應(yīng)客戶端套接字的請求，建立一個新的線程疆导，把服務(wù)器端套接字的描述發(fā)給客戶端赁项，一旦客戶端確認了此描述，雙方就正式建立連接澈段。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽狀態(tài)悠菜，繼續(xù)接收其他客戶端套接字的連接請求。
36败富、運行時你是怎么理解的悔醋，怎么用的?【難度系數(shù)★★★】
OC Runtime 其實是一個 Runtime 庫，基本上用 C
和匯編寫的兽叮，這個庫使得 C 語言有了面向?qū)ο蟮哪芰ΓX中浮現(xiàn)當你喬幫主參觀了施樂帕克的 SmallTalk
之后嘴角一抹淺笑）芬骄。這個庫做的事前就是加載類的信息，進行方法的分發(fā)和轉(zhuǎn)發(fā)之類的鹦聪。OC是一種面向runtime(運行時)的語言账阻，也就是說，它會盡可能地把代碼執(zhí)行的決策從編譯和鏈接的時候泽本，推遲到運行時淘太。這給程序員寫代碼帶來很大的靈活性，比如說你可以把消息轉(zhuǎn)發(fā)給你想要的對象，或者隨意交換一個方法的實現(xiàn)之類的蒲牧。這就要求runtime能檢測一個對象是否能對一個方法進行響應(yīng)撇贺，然后再把這個方法分發(fā)到對應(yīng)的對象去。我們拿
C 來跟 ObjC 對比一下造成。在 C 語言里面显熏，一切從 main 函數(shù)開始雄嚣，程序員寫代碼的時候是自上而下地晒屎，一個 C
的結(jié)構(gòu)體或者說類吧，是不能把方法調(diào)用轉(zhuǎn)發(fā)給其他對象的缓升。這個問題其實淺涉及到兩個概念鼓鲁，運行時和多態(tài)。?簡單來說港谊，運行時機制使我們直到運行時才去決定一個對象的類別骇吭，以及調(diào)用該類別對象指定方法。?多態(tài)：不同對象以自己的方式響應(yīng)相同的消息的能力叫做多態(tài)歧寺。意思就是假設(shè)生物類（life）都用有一個相同的方法-eat;?那人類屬于生物燥狰，豬也屬于生物，都繼承了life后斜筐，實現(xiàn)各自的eat龙致，但是調(diào)用是我們只需調(diào)用各自的eat方法。?也就是不同的對象以自己的方式響應(yīng)了相同的消息（響應(yīng)了eat這個選擇器顷链。因此也可以說目代，運行時機制是多態(tài)的基礎(chǔ)。比如KVO中我們就用了嗤练。
37榛了、消息推送是怎么現(xiàn)實的？【難度系數(shù)★★】
iOS消息推送的工作機制可以簡單的用下圖來概括：
Provider是指某個iPhone軟件的Push服務(wù)器煞抬，APNS是Apple Push Notification Service的縮寫霜大，是蘋果的服務(wù)器。
上圖可以分為三個階段：
第一階段：應(yīng)用程序把要發(fā)送的消息革答、目的iPhone的標識打包战坤，發(fā)給APNS。
第二階段：APNS在自身的已注冊Push服務(wù)的iPhone列表中蝗碎，查找有相應(yīng)標識的iPhone湖笨，并把消息發(fā)送到iPhone。
第三階段：iPhone把發(fā)來的消息傳遞給相應(yīng)的應(yīng)用程序蹦骑，并且按照設(shè)定彈出Push通知慈省。
從上圖我們可以看到：
1、應(yīng)用程序注冊消息推送。
2边败、iOS從APNS Server獲取device token袱衷，應(yīng)用程序接收device token。
3笑窜、應(yīng)用程序?qū)evice token發(fā)送給PUSH服務(wù)端程序致燥。
4、服務(wù)端程序向APNS服務(wù)發(fā)送消息排截。
5嫌蚤、APNS服務(wù)將消息發(fā)送給iPhone應(yīng)用程序。
38断傲、根據(jù)什么確定要開啟線程數(shù)脱吱？一般情況下開啟幾條？【難度系數(shù)★★】
一般不需要管理線程數(shù)量认罩，程序開放時是針對隊列開發(fā)的箱蝠，向隊列添加操作就可以了。具體的線程數(shù)量由底層的線程池管理垦垂，開啟線程的數(shù)量一般會根據(jù)用戶的網(wǎng)絡(luò)情況決定宦搬。WIFI一般5-6條，3G一般2-3條劫拗。
39间校、分析json、xml的區(qū)別杨幼？json撇簿、xml解析方式的底層是如何處理的？【難度系數(shù)★★★★】
一差购、關(guān)于輕量級和重量級
輕量級和重量級是相對來說的四瘫，那么XML相對于JSON的重量級體現(xiàn)在哪呢?應(yīng)該體現(xiàn)在解析上，XML目前設(shè)計了兩種解析方式：DOM和 SAX欲逃。
<1>.DOM
DOM需要把XML文件整個讀入內(nèi)存找蜜；
<2>.SAX
SAX不需要整個讀入文檔就可以對解析出的內(nèi)容進行處理，是一種逐步解析的方法稳析。程序也可以隨時終止解析洗做。這樣，一個大的文檔就可以逐步的彰居、一點一點的展現(xiàn)出來诚纸，所以SAX適合于大規(guī)模的解析。這一點陈惰，JSON目前是做不到得畦徘。
所以，JSON和XML的輕/重量級的區(qū)別在于：
JSON只提供整體解析方案，而這種方法只在解析較少的數(shù)據(jù)時才能起到良好的效果井辆；
XML提供了對大規(guī)模數(shù)據(jù)的逐步解析方案关筒，這種方案很適合于對大量數(shù)據(jù)的處理。
二杯缺、關(guān)于數(shù)據(jù)格式編碼及解析難度
1蒸播、在編碼方面。
雖 然XML和JSON都有各自的編碼工具萍肆，但是JSON的編碼要比XML簡單袍榆，即使不借助工具，也可以寫出JSON代碼匾鸥，但要寫出好的XML代碼就有點困 難;與XML一樣蜡塌，JSON也是基于文本的碉纳，且它們都使用Unicode編碼勿负，且其與數(shù)據(jù)交換格式XML一樣具有可讀性。
主觀上來看劳曹，JSON更為清晰且冗余更少些奴愉。JSON網(wǎng)站提供了對JSON語法的嚴格描述，只是描述較簡短铁孵。從總體來看锭硼，XML比較適合于標記文檔，而JSON卻更適于進行數(shù)據(jù)交換處理蜕劝。
JSON聲稱相對XML有許多好處檀头，包括：
容易閱讀
解析速度更快
占用空間更少
盡管容易閱讀是很難衡量的一點，但其它兩點是很顯然的岖沛。
很容易看出暑始，存儲相同的信息JSON確實需要更少的空間∮は鳎快速瀏覽一下JSON的網(wǎng)站后廊镜，你會發(fā)現(xiàn)幾個比較這兩種格式的例子。從頁面上可以很容易的看出：
描述同樣的信息JSON比XML少占用很多的空間唉俗。例如：第一個例子（詞匯表結(jié)構(gòu)）存儲為XML需要502個字符嗤朴，而存儲為JSON只需345字符（大約
少占30％的空間）。
對于“解析速度更快”這一點虫溜，有點難以測試雹姊。對此我寫了一個快速測試來看看我能以多快的速度來把一個XML和JSON字符串轉(zhuǎn)化為Java對象。
對于XML解析衡楞，我使用Java內(nèi)置的SAX解析器吱雏。SAX解析器允許遍歷XML文件，并把XML值賦給對象中適當?shù)淖侄巍＿@種方法相對JSON解析是比較繁瑣的坎背，但不是沒有道理替劈。
JSON的解析，我使用了GSON庫得滤，只需用一行代碼就可以很容易地在JSON和java對象之間轉(zhuǎn)換陨献，只需要一個這個類的定義就可以了（如Book類，
字段名和JSON中的對應(yīng)）懂更。不過這使得這個類變量和JSON實例綁定到了一起眨业。一旦類的實例名稱或JSON字段名有了變化，將會出現(xiàn)問題沮协。
三龄捡、實例比較
XML和JSON都使用結(jié)構(gòu)化方法來標記數(shù)據(jù)，下面來做一個簡單的比較慷暂。
<1>.用XML表示中國部分省市數(shù)據(jù)如下：
?> ? 中國 ?
黑龍江 ? ?
哈爾濱 ? ? ? 大慶
廣東 ? ?
廣州 ? ? ? 深圳
珠海 ? ? ?
<2>.用JSON表示中國部分省市數(shù)據(jù)如下：
var country = ? ? ? ? { ? ? ? ? ? ? name:
"中國", ? ? ? ? ? ? provinces: [ ? ? ? ? ? ? { name: "黑龍江", citys: { city:
["哈爾濱", "大慶"]} }, ? ? ? ? ? ? { name: "廣東", citys: { city: ["廣州", "深圳",
"珠海"]} }, ? ? ? ? ? ? { name: "臺灣", citys:
{ city: ["臺北", "高雄"]} }, ? ? ? ? ? ? { name: "新疆", citys: { city:
["烏魯木齊"]} } ? ? ? ? ? ? ] ? ? ? ? }
底層實現(xiàn)：
json解析的用法：底層原理遍歷字符串中的字符聘殖，最終根據(jù)格式規(guī)定的特殊字符，比如{}號行瑞，[]號, : 號 等進行區(qū)分奸腺，
{}號是一個字典的開始，[]號是一個數(shù)組的開始, : 號是字典的鍵和值的分水嶺血久，最終乃是將json數(shù)據(jù)轉(zhuǎn)化為字典突照，
字典中值可能是字典，數(shù)組氧吐，或字符串而已讹蘑。
40、什么是動態(tài)識別筑舅，動態(tài)綁定座慰？【難度系數(shù)★★★★】
一、Objective-C多態(tài)
1.概念：相同接口豁翎，不同的實現(xiàn)
來自不同類可以定義共享相同名稱的方法角骤。
動態(tài)類型能使程序直到執(zhí)行時才確定對象所屬類型
動態(tài)類型綁定能使程序直到執(zhí)行時才確定要對對象調(diào)用的實際方法
2.Objective-C不同于傳統(tǒng)程序設(shè)計語言，它可以再運行時加入新的數(shù)據(jù)類型和新的程序模塊：動態(tài)類型識別心剥，動態(tài)綁定邦尊，動態(tài)加載
3.id類型：通用指針類型，弱類型优烧，編譯時不進行類型檢查
二蝉揍、動態(tài)類型識別
1.任意NSObject的子類都會繼承NSObject的isa實例變量，而且當NSObject的子類實例化對象時畦娄，isa實例變量永遠是對象的第一個實例變量又沾。
2.類對象
＊類對象再程序運行時一直存在弊仪。
＊類對象是一種數(shù)據(jù)結(jié)構(gòu)，存儲類的基本信息：類大小杖刷，類名稱励饵，類的版本以及消息與函數(shù)的映射表等
＊類對象所保存的信息在程序編譯時確定，在程序啟動時加載到內(nèi)存中滑燃。
＊類對象代表類役听，class代表類對象，類方法屬于類對象
＊如果消息的接收者是類名表窘，則類名代表類對象
＊運行時典予，所有類的實例都由類對象生成，類對象會把實例的isa的值修改成自己的地址乐严，每個實例的isa都指向該實例的類對象瘤袖，＊從類對象里可以知道父類信息、可以響應(yīng)的方法等
＊類對象只能使用類方法昂验，不能用實例方法
3.SEL類型
Objective-C在編譯的時候,會根據(jù)方法的名字
(包括參數(shù)序列),生成一個用來區(qū)分這個方法的唯一的一個標示(ID),這個標示(ID)就是SEL類型的,在運行時候是通過方法的標示來查找方法的捂敌。只
要方法的名字(包括參數(shù)序列)相同,那么它們的 ID都是相同的×莞荩可以通過@select()指示符獲得方法的標示黍匾。SEL mydraw
=@select(draw)；
NSSelectorFromString(NSString*);根據(jù)方法名得到方法標識
(NSString*)NSStringFromSelector(SEL);得到SEL類型的方法名
4.動態(tài)類型識別常用方法
-(BOOL)isKindOfClass:classObj? 是否是classObj類或其子類
-(BOOL)isMemberOfClass:classObj是否是classObj的實例
-(BOOL)respondsTosSelector:selector? 類中是否有這個方法
NSClassFromString(NSString*);由字符串得到類對象
NSStringFromClass([類名 Class]);由類名得到字符串
Class rectClass= [Rectangle class];通過類名得到類對象
Class aClass =[anObject class];通過實例得到類對象
if([obj1 class]== [obj2 class])判斷是不是相同類的實例
5. 可以將對象分為id類型和靜態(tài)類型
– 如果不涉及到多態(tài),盡量使用靜態(tài)類型
– 靜態(tài)類型可更好的在編譯階段而不是運行階段指 出錯誤
– 靜態(tài)類型能夠提高程序的可讀性
三呛梆、動態(tài)綁定
1. 在objective-c中,一個對象內(nèi)否調(diào)用指定的方法不是由編譯器決定而是由運行時決定,這被稱作是方法的動態(tài)綁定。
2. 在objective-c里,對象不調(diào)用方法,而是接收消息,消息 表達式為:
[reciver message];運行時系統(tǒng)首先確定接收者的類型(動態(tài)類型識別),然 后根據(jù)消息名在類的方法列表里選擇相依的方法執(zhí)行,所
以在源代碼里消息也稱為選擇器(selector)
3. 消息函數(shù)的作用:
– 首先通過第一個參數(shù)的receiver,找到它的isa 指針,然 后在isa 指向的Class 對象中使用第二個參數(shù)selector 查 找方法;
– 如果沒有找到,就使用當前Class 對象中的新的isa 指針 到上一級的父類的Class 對象中查找;
– 當找到方法后,再依據(jù)receiver 的中的self 指針找到當前 的對象,調(diào)用當前對象的具體實現(xiàn)的方法(IMP),然后傳 遞參數(shù),調(diào)用實現(xiàn)方法磕诊。
– 假如一直找到NSObject 的Class 對象,也沒有找到你調(diào) 用的方法,就會報告不能識別發(fā)送消息的錯誤填物。
41、線程與進程的區(qū)別和聯(lián)系?【難度系數(shù)★★】
1). 進程和線程都是由操作系統(tǒng)所體會的程序運行的基本單元霎终，系統(tǒng)利用該基本單元實現(xiàn)系統(tǒng)對應(yīng)用的并發(fā)性
2). 進程和線程的主要差別在于它們是不同的操作系統(tǒng)資源管理方式滞磺。
3). 進程有獨立的地址空間，一個進程崩潰后莱褒，在保護模式下不會對其它進程產(chǎn)生影響击困，而線程只是一個進程中的不同執(zhí)行路徑。
4.)線程有自己的堆棧和局部變量广凸，但線程之間沒有單獨的地址空間阅茶，一個線程死掉就等于整個進程死掉。所以多進程的程序要比多線程的程序健壯谅海，但在進程切換時脸哀，耗費資源較大，效率要差一些扭吁。
5). 但對于一些要求同時進行并且又要共享某些變量的并發(fā)操作撞蜂，只能用線程盲镶，不能用進程。
42蝌诡、iOS中socket使用【難度系數(shù)★★★★★】
Socket是對TCP/IP協(xié)議的封裝溉贿，Socket本身并不是協(xié)議，而是一個調(diào)用接口（API）浦旱，通過Socket顽照，我們才能使用TCP/IP協(xié)議。
http協(xié)議：對應(yīng)于應(yīng)用層
tcp協(xié)議：對應(yīng)于傳輸層
ip協(xié)議：對應(yīng)于網(wǎng)絡(luò)層
三者本質(zhì)上沒有可比性闽寡。 何況HTTP協(xié)議是基于TCP連接的代兵。
TCP/IP是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸爷狈；而HTTP是應(yīng)用層協(xié)議植影，主要解決如何包裝數(shù)據(jù)。
我們在傳輸數(shù)據(jù)時涎永，可以只使用傳輸層（TCP/IP）思币，但是那樣的話，由于沒有應(yīng)用層羡微，便無法識別數(shù)據(jù)內(nèi)容谷饿，如果想要使傳輸?shù)臄?shù)據(jù)有意義，則必須使用應(yīng)用層
協(xié)議妈倔，應(yīng)用層協(xié)議很多博投，有HTTP、FTP盯蝴、TELNET等等毅哗，也可以自己定義應(yīng)用層協(xié)議。WEB使用HTTP作傳輸層協(xié)議捧挺，以封裝HTTP文本信息虑绵，然
后使用TCP/IP做傳輸層協(xié)議將它發(fā)送到網(wǎng)絡(luò)上。
SOCKET原理
1闽烙、套接字（socket）概念
套接字（socket）是通信的基石翅睛，是支持TCP/IP協(xié)議的網(wǎng)絡(luò)通信的基本操作單元。它是網(wǎng)絡(luò)通信過程中端點的抽象表示黑竞，包含進行網(wǎng)絡(luò)通信必須的五種信息：連接使用的協(xié)議捕发，本地主機的IP地址，本地進程的協(xié)議端口摊溶，遠地主機的IP地址爬骤，遠地進程的協(xié)議端口。
應(yīng)用層通過傳輸層進行數(shù)據(jù)通信時莫换，TCP會遇到同時為多個應(yīng)用程序進程提供并發(fā)服務(wù)的問題霞玄。多個TCP連接或多個應(yīng)用程序進程可能需要通過同一個
TCP協(xié)議端口傳輸數(shù)據(jù)骤铃。為了區(qū)別不同的應(yīng)用程序進程和連接，許多計算機操作系統(tǒng)為應(yīng)用程序與TCP／IP協(xié)議交互提供了套接字(Socket)接口坷剧。應(yīng)
用層可以和傳輸層通過Socket接口惰爬，區(qū)分來自不同應(yīng)用程序進程或網(wǎng)絡(luò)連接的通信，實現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù)惫企。
2撕瞧、建立socket連接
建立Socket連接至少需要一對套接字，其中一個運行于客戶端狞尔，稱為ClientSocket丛版，另一個運行于服務(wù)器端，稱為ServerSocket偏序。
套接字之間的連接過程分為三個步驟：服務(wù)器監(jiān)聽页畦，客戶端請求，連接確認研儒。
服務(wù)器監(jiān)聽：服務(wù)器端套接字并不定位具體的客戶端套接字豫缨，而是處于等待連接的狀態(tài)，實時監(jiān)控網(wǎng)絡(luò)狀態(tài)端朵，等待客戶端的連接請求好芭。
客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是服務(wù)器端的套接字冲呢。為此舍败，客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字，指出服務(wù)器端套接字的地址和端口號碗硬，然后就向服務(wù)器端套接字提出連接請求瓤湘。
連接確認：當服務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時，就響應(yīng)客戶端套接字的請求恩尾，建立一個新的線程，把服務(wù)器端套接字的描述發(fā)給客戶
端挽懦，一旦客戶端確認了此描述翰意，雙方就正式建立連接刽辙。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽狀態(tài)条辟，繼續(xù)接收其他客戶端套接字的連接請求。
3花沉、SOCKET連接與TCP連接
創(chuàng)建Socket連接時渔嚷，可以指定使用的傳輸層協(xié)議进鸠，Socket可以支持不同的傳輸層協(xié)議（TCP或UDP），當使用TCP協(xié)議進行連接時形病，該Socket連接就是一個TCP連接客年。
4霞幅、Socket連接與HTTP連接
由于通常情況下Socket連接就是TCP連接，因此Socket連接一旦建立量瓜，通信雙方即可開始相互發(fā)送數(shù)據(jù)內(nèi)容司恳，直到雙方連接斷開。但在實際網(wǎng)絡(luò)應(yīng)用
中绍傲，客戶端到服務(wù)器之間的通信往往需要穿越多個中間節(jié)點扔傅，例如路由器、網(wǎng)關(guān)烫饼、防火墻等猎塞，大部分防火墻默認會關(guān)閉長時間處于非活躍狀態(tài)的連接而導致
Socket 連接斷連，因此需要通過輪詢告訴網(wǎng)絡(luò)杠纵，該連接處于活躍狀態(tài)荠耽。
而HTTP連接使用的是“請求—響應(yīng)”的方式，不僅在請求時需要先建立連接淡诗，而且需要客戶端向服務(wù)器發(fā)出請求后骇塘，服務(wù)器端才能回復數(shù)據(jù)。
很多情況下韩容，需要服務(wù)器端主動向客戶端推送數(shù)據(jù)款违，保持客戶端與服務(wù)器數(shù)據(jù)的實時與同步。此時若雙方建立的是Socket連接群凶，服務(wù)器就可以直接將數(shù)據(jù)傳送給
客戶端插爹；若雙方建立的是HTTP連接，則服務(wù)器需要等到客戶端發(fā)送一次請求后才能將數(shù)據(jù)傳回給客戶端请梢，因此赠尾，客戶端定時向服務(wù)器端發(fā)送連接請求，不僅可以
保持在線毅弧，同時也是在“詢問”服務(wù)器是否有新的數(shù)據(jù)气嫁，如果有就將數(shù)據(jù)傳給客戶端。
43够坐、遠程推送【難度系數(shù)★★★★★】
當服務(wù)端遠程向APNS推送至一臺離線的設(shè)備時寸宵，蘋果服務(wù)器Qos組件會自動保留一份最新的通知，等設(shè)備上線后元咙，Qos將把推送發(fā)送到目標設(shè)備上梯影。
遠程推送的基本過程：
1.客戶端的app需要將用戶的UDID和app的bundleID發(fā)送給apns服務(wù)器,進行注冊,apns將加密后的device Token返回給app
2.app獲得device Token后,上傳到公司服務(wù)器
3.當需要推送通知時,公司服務(wù)器會將推送內(nèi)容和device Token一起發(fā)給apns服務(wù)器
4.apns再將推送內(nèi)容送到客戶端上
創(chuàng)建證書的流程：
1.打開鑰匙串，生成CertificateSigningRequest.certSigningRequest文件
2.將CertificateSigningRequest.certSigningRequest上傳進developer庶香，導出.cer文件
3.利用CSR導出P12文件
4.需要準備下設(shè)備token值（無空格）
5.使用OpenSSL合成服務(wù)器所使用的推送證書
本地app代碼參考
1.注冊遠程通知
-?(BOOL)application:(UIApplication?*)application?didFinishLaunchingWithOptions:(NSDictionary?*)launchOptions//中注冊遠程通知
{
[[UIApplication?sharedApplication]?registerForRemoteNotificationTypes:(UIRemoteNotificationTypeAlert?|?UIRemoteNotificationTypeBadge?|?UIRemoteNotificationTypeSound)];
}
2,實現(xiàn)幾個代理方法：
//獲取deviceToken令牌
-(void)application:(UIApplication?*)application?didRegisterForRemoteNotificationsWithDeviceToken:(NSData?*)deviceToken
{
//獲取設(shè)備的deviceToken唯一編號
NSLog(@"deviceToken=%@",deviceToken);
NSString?*realDeviceToken=[NSString?stringWithFormat:@"%@",deviceToken];
//去除<>
realDeviceToken?=?[realDeviceToken?stringByReplacingOccurrencesOfString:@"<"?withString:@""];
realDeviceToken?=?[realDeviceToken?stringByReplacingOccurrencesOfString:@">"?withString:@""];
NSLog(@"realDeviceToken=%@",realDeviceToken);
[[NSUserDefaults?standardUserDefaults]?setValue:realDeviceToken?forKey:@"DeviceToken"];??//要發(fā)送給服務(wù)器
}
//獲取令牌出錯
-(void)application:(UIApplication?*)application?didFailToRegisterForRemoteNotificationsWithError:(NSError?*)error
{
//注冊遠程通知設(shè)備出錯
NSLog(@"RegisterForRemoteNotification?error=%@",error);
}
//在應(yīng)用在前臺時受到消息調(diào)用
-(void)application:(UIApplication?*)application?didReceiveRemoteNotification:(NSDictionary?*)userInfo
{
//打印推送的消息
NSLog(@"%@",[[userInfo?objectForKey:@"aps"]?objectForKey:@"alert"]):
}
配置后臺模式
一般我們是使用開發(fā)版本的Provisioning做推送測試,如果沒有問題,再使用發(fā)布版本證書的時候一般也應(yīng)該是沒有問題的甲棍。為了以防萬一,我們可以在越獄的手機上安裝我們的使用發(fā)布版證書的ipa文件(最好使用debug版本,并打印出獲取到的deviceToken),安裝成功后在;XCode->Window->Organizer-找到對應(yīng)的設(shè)備查看console找到打印的deviceToken。
在后臺的推送程序中使用發(fā)布版制作的證書并使用該deviceToken做推送服務(wù).
使用開發(fā)和發(fā)布證書獲取到的deviceToken是不一樣的赶掖。
44感猛、什么是事件響應(yīng)鏈七扰，其特點是什么〕猓【難度系數(shù)★★★★★】
對于iOS設(shè)備用戶來說戳寸，他們操作設(shè)備的方式主要有三種：觸摸屏幕、晃動設(shè)備拷泽、通過遙控設(shè)施控制設(shè)備疫鹊。對應(yīng)的事件類型有以下三種：
1、觸屏事件（Touch Event）
2司致、運動事件（Motion Event）
3拆吆、遠端控制事件（Remote-Control Event）
響應(yīng)者鏈（Responder Chain）
響應(yīng)者對象（Responder Object），指的是有響應(yīng)和處理事件能力的對象脂矫。響應(yīng)者鏈就是由一系列的響應(yīng)者對象構(gòu)成的一個層次結(jié)構(gòu)枣耀。
UIResponder是所有響應(yīng)對象的基類，在UIResponder類中定義了處理上述各種事件的接口庭再。我們熟悉的UIApplication捞奕、
UIViewController、UIWindow和所有繼承自UIView的UIKit類都直接或間接的繼承自UIResponder拄轻，所以它們的實例都是可以構(gòu)成響應(yīng)者鏈的響應(yīng)者對象颅围。
響應(yīng)者鏈有以下特點：
1、響應(yīng)者鏈通常是由視圖（UIView）構(gòu)成的恨搓；
2院促、一個視圖的下一個響應(yīng)者是它視圖控制器（UIViewController）（如果有的話），然后再轉(zhuǎn)給它的父視圖（Super View）斧抱；
3常拓、視圖控制器（如果有的話）的下一個響應(yīng)者為其管理的視圖的父視圖；
4辉浦、單例的窗口（UIWindow）的內(nèi)容視圖將指向窗口本身作為它的下一個響應(yīng)者
需要指出的是弄抬，Cocoa Touch應(yīng)用不像Cocoa應(yīng)用，它只有一個UIWindow對象宪郊，因此整個響應(yīng)者鏈要簡單一點眉睹；
5、單例的應(yīng)用（UIApplication）是一個響應(yīng)者鏈的終點废膘，它的下一個響應(yīng)者指向nil，以結(jié)束整個循環(huán)慕蔚。
