該文章屬于<簡書 — Timhbw>原創(chuàng)拌蜘，轉(zhuǎn)載請注明： <簡書社區(qū) — Timhbw>http://www.reibang.com/p/5fd65c20912e

iOSinterview.jpg

<簡書社區(qū) — Timhbw>iOS基礎(chǔ)問答面試題連載(一)-附答案
<簡書社區(qū) — Timhbw>iOS基礎(chǔ)問答面試題連載(二)-附答案
<簡書社區(qū) — Timhbw>iOS基礎(chǔ)問答面試題連載(三)-附答案
<簡書社區(qū) — Timhbw>iOS基礎(chǔ)問答面試題連載(四)

這次的問題是網(wǎng)絡(luò)多線程相關(guān)的喲颗圣，面試的時(shí)候也是必問的邑狸，大家多看看

11月24日修正一處錯(cuò)誤:18、19題目一樣,答案不一樣(其實(shí)是兩種理解伴澄，修改為最優(yōu)的一種放上來.多謝讀者提醒)

• 以下是一些自己收集的網(wǎng)絡(luò)多線程方面比較基礎(chǔ)的問題（大神可以忽略）蟀苛，附上答案，方便大家閱讀奕短。俗話說得好，基礎(chǔ)不牢匀钧，地動(dòng)山搖翎碑。文章末尾會(huì)提供PDF版的文檔，方便大家木有網(wǎng)的時(shí)候也可以用移動(dòng)設(shè)備觀看之斯。

1.請簡單說明多線程技術(shù)的優(yōu)點(diǎn)和缺點(diǎn)日杈？

• 優(yōu)點(diǎn)：
  • 1.能夠適當(dāng)提高程序的執(zhí)行效率；
  • 2.能夠適當(dāng)?shù)奶岣哔Y源的利用率佑刷，比如CPU莉擒、內(nèi)存。
• 缺點(diǎn)：
  • 1.創(chuàng)建線程有額外開銷
  • 2.程序的代碼更加復(fù)雜
  • 3.線程越多瘫絮，CPU在調(diào)度線程上的開銷就越大
  • 4.如果開啟大量線程涨冀，反而會(huì)降低程序的性能

2.請簡單說明線程和進(jìn)程，以及他們之間的關(guān)系麦萤？

• 1.進(jìn)程是CPU調(diào)度和分配資源的單位鹿鳖。
• 2.線程是CPU調(diào)用的最小單位
• 關(guān)系：
  • 1.進(jìn)程包含線程；
  • 2.一個(gè)程序可以對應(yīng)多個(gè)進(jìn)程壮莹，一個(gè)進(jìn)程中可以有多個(gè)線程翅帜，但至少要有一個(gè)線程；
  • 3.同一個(gè)進(jìn)程內(nèi)的線程共享進(jìn)程的資源命满。

3.請簡單說明在iOS開發(fā)中有哪些多線程的實(shí)現(xiàn)方案涝滴？

• 1.PThread
• 2.NSThread
• 3.GCD
• 4.NSOperation

4.請簡單說明主線程的作用，以及使用注意點(diǎn)胶台？

• 主線程:默認(rèn)啟動(dòng)的線程
• 作用:(1)顯示和刷新UI界面 (2)處理UI事件
• 注意點(diǎn):
  • 1.不要將耗時(shí)操作放在主線程中執(zhí)行
  • 2.UI操作必須在主線程中執(zhí)行 !!!!

5.請簡單列出NSThread線程的幾種狀態(tài)狭莱，并說明狀態(tài)轉(zhuǎn)換的邏輯？

新建->就緒 CPU調(diào)度當(dāng)前任務(wù)->運(yùn)行->阻塞->死亡
                            CPU調(diào)度其他任務(wù)->就緒

6.請簡單說明如何簡單的解決多線程訪問同一塊資源造成的線程安全的問題概作，以及注意點(diǎn)腋妙？

• 加同步(互斥)鎖，
• @synchronized
• OC中的同步鎖:(鎖對象) + {要鎖住的代碼}
• 鎖對象:要求是全局唯一的屬性
  • 注意點(diǎn):
    • 1.要注意加鎖的位置
    • 2.加鎖需要耗費(fèi)性能,因此需要注意加鎖的條件(多線程訪問同一塊資源)
    • 3.專業(yè)術(shù)語:線程同步

7.請簡單介紹下什么是原子和非原子屬性讯榕？

• atomic：原子屬性骤素，會(huì)為setter方法加鎖，默認(rèn)為atomic愚屁。線程安全济竹，會(huì)消耗大量資源
• nonatomic：非原子屬性，不會(huì)為setter方法加鎖霎槐。非線程安全送浊，適合內(nèi)存小的移動(dòng)設(shè)備。

8.請簡單介紹下GCD這門技術(shù)丘跌？

• 全稱 Grand Central Dispatch袭景，中樞調(diào)度器唁桩。
• GCD中有2個(gè)核心概念:任務(wù)和隊(duì)列。
• GCD使用:封裝任務(wù)耸棒，將封裝好的任務(wù)添加到隊(duì)列中荒澡，遵循FIFO。

9.請簡單介紹GCD中的幾種隊(duì)列与殃？（4種）

• 并發(fā)隊(duì)列：多個(gè)任務(wù)同時(shí)執(zhí)行单山，會(huì)開啟多個(gè)線程同時(shí)執(zhí)行任務(wù)，只有在異步函數(shù)下才有效幅疼。
• 串行隊(duì)列：任務(wù)只能一個(gè)接一個(gè)的去執(zhí)行米奸，不會(huì)開啟多個(gè)線程，主隊(duì)列屬于串行隊(duì)列爽篷，主隊(duì)列所有的任務(wù)必須在主線程中執(zhí)行躏升。
• 全局隊(duì)列
• 主隊(duì)列

10.如果當(dāng)前有多個(gè)任務(wù)，這些任務(wù)都需要開子線程執(zhí)行狼忱，而多個(gè)任務(wù)之間有一定的依賴關(guān)系膨疏，如果使用GCD來實(shí)現(xiàn)請?jiān)囍o出一些解決方案。

• 使用異步函數(shù)（同步函數(shù)）+主隊(duì)列

11.請簡單說明單例模式的特點(diǎn)（作用）钻弄？

• 如果一個(gè)類實(shí)現(xiàn)了單例佃却，那么可以保證在程序運(yùn)行過程，一個(gè)類只有一個(gè)實(shí)例
• 單例對象易于供外界訪問（通常會(huì)提供一個(gè)類方法）
• 實(shí)現(xiàn)了單例模式后窘俺，可以方便地控制了實(shí)例個(gè)數(shù)饲帅，并節(jié)約系統(tǒng)資源

12.請簡單介紹操作隊(duì)列？

• 操作隊(duì)列本身是OC語言的瘤泪，在iOS開發(fā)中可以用來實(shí)現(xiàn)多線程編程
• 操作隊(duì)列有兩大核心的概念灶泵，一個(gè)是操作（NSOperation），一個(gè)是隊(duì)列(NSOperationQueue),操作用來封裝任務(wù)对途，隊(duì)列用來存放操作
• 要使用操作隊(duì)列進(jìn)行多線程編程赦邻，只需要把封裝好的操作提交到相應(yīng)的隊(duì)列中即可，系統(tǒng)內(nèi)部會(huì)視情況自動(dòng)開啟相應(yīng)的線程來執(zhí)行任務(wù)
• 在操作隊(duì)列這門技術(shù)中实檀，系統(tǒng)提供了兩個(gè)子類可以來封裝任務(wù)惶洲，一個(gè)是NSInvocationOperation，一個(gè)是NSBlockOperation,除此之外也可以直接自定義操作
• 操作隊(duì)列中有兩種隊(duì)列膳犹，一種是通過[NSOperationQueue mainQueue]獲得的主隊(duì)列恬吕，一種是通過[[NSOperationQueue alloc]init]方法獲得的非主隊(duì)列
• 主隊(duì)列是和主線程相關(guān)的串行隊(duì)列，提交到主隊(duì)列中的操作將被安排在主線程中執(zhí)行（可以利用該特性來處理線程間通信的相關(guān)邏輯）
• 操作+隊(duì)列:
  • NSInvocationOperation
  • NSBlockOperatio
• NSOperationQueue
  • 自己創(chuàng)建 [[NSOperationQueue alloc]init];
  • 主隊(duì)列 [NSOperationQueue main];

13.如果有多個(gè)操作如何來設(shè)置依賴關(guān)系须床，如何監(jiān)聽到某個(gè)操作執(zhí)行完畢事件铐料？

• 1.設(shè)置依賴關(guān)系：假設(shè)有有兩個(gè)操作分別是op1和op2，op1需要依賴于op2,那么只需要使用[op1 addDependency:op2]方法設(shè)置即可。
• 2.操作依賴補(bǔ)充：使用操作隊(duì)列可以方便的指定多個(gè)操作間的依賴關(guān)系钠惩，甚至可以實(shí)現(xiàn)跨隊(duì)列的操作依賴柒凉，但是在使用的時(shí)候需要注意操作之間不能有循環(huán)依賴關(guān)系
• 3.操作監(jiān)聽：可以使用^completionBlock來實(shí)現(xiàn)操作監(jiān)聽

14.請簡單比較GCD中的全局并發(fā)隊(duì)列和使用dispatch_queue_create函數(shù)創(chuàng)建的并發(fā)隊(duì)列異同？

• 1.全局并發(fā)隊(duì)列在整個(gè)應(yīng)用程序中本身是默認(rèn)存在的并且對應(yīng)有高優(yōu)先級妻柒、默認(rèn)優(yōu)先級、低優(yōu)先級和后臺優(yōu)先級一共四個(gè)并發(fā)隊(duì)列耘分，我們只是選擇其中的一個(gè)直接拿來用举塔。而Create函數(shù)是實(shí)打?qū)嵉膹念^開始去創(chuàng)建一個(gè)隊(duì)列。
• 2.在iOS6.0之前求泰，在GCD中凡是使用了帶Create和retain的函數(shù)在最后都需要做一次release操作央渣。而主隊(duì)列和全局并發(fā)隊(duì)列不需要我們手動(dòng)release。當(dāng)然了渴频，在iOS6.0之后GCD已經(jīng)被納入到了ARC的內(nèi)存管理范疇中芽丹，即便是使用retain或者create函數(shù)創(chuàng)建的對象也不再需要開發(fā)人員手動(dòng)釋放，我們像對待普通OC對象一樣對待GCD就OK卜朗。
• 3.在使用柵欄函數(shù)的時(shí)候拔第，柵欄函數(shù)只有在和使用create函數(shù)自己的創(chuàng)建的并發(fā)隊(duì)列一起使用的時(shí)候才有效
• 4.其它區(qū)別涉及到XNU內(nèi)核的系統(tǒng)級線程編程，不一一列舉场钉。

15.請簡單說明對圖片進(jìn)行二級緩存的實(shí)現(xiàn)思路蚊俺？

• 在顯示圖片的時(shí)候
  • 1.先檢查該圖片對應(yīng)的內(nèi)存緩存
    • 1.如果存在內(nèi)存緩存，則
      • a.直接使用設(shè)置并顯示圖片逛万；
    • 2.如果內(nèi)存緩存中沒有,則
      • a.繼續(xù)檢查該圖片對應(yīng)的磁盤緩存是否存在泳猬，跳轉(zhuǎn)到第2步。
  • 2.檢查該圖片對應(yīng)的磁盤緩存
    • 1.如果存在磁盤緩存宇植，則
      • a.先保存一份到內(nèi)存緩存中（方便下次使用）
      • b.然后設(shè)置并顯示圖片
    • 2.如果不存在磁盤緩存得封，則直接下載該圖片，下載完成后
      • a.保存一份到內(nèi)存緩存中
      • b.保存一份到磁盤緩存中
      • c.設(shè)置并顯示圖片

16.請簡單對比下GCD和NSOperation兩種多線程的實(shí)現(xiàn)方案指郁？

• GCD是純C語言的API,而操作隊(duì)列則是Object-C的對象忙上。
• 在GCD中，任務(wù)用塊（block）來表示闲坎，而塊是個(gè)輕量級的數(shù)據(jù)結(jié)構(gòu)晨横；相反操作隊(duì)列中的『操作』NSOperation則是個(gè)更加重量級的Object-C對象。
• 具體該使用GCD還是使用NSOperation需要看具體的情況箫柳，如果只是想簡單開一個(gè)子線程執(zhí)行任務(wù)推薦使用GCD手形，如果有很多任務(wù)需要開多個(gè)子線程下載推薦使用操作隊(duì)列

17.請按照自己的理解，說一說在進(jìn)行多線程編程的時(shí)候相對于GCD而言悯恍，操作隊(duì)列有哪些優(yōu)勢库糠？

• NSOperation和NSOperationQueue的好處有：
  • 1.NSOperationQueue可以方便的調(diào)用cancel方法來取消某個(gè)操作，而GCD中的任務(wù)是無法被取消的（安排好任務(wù)之后就不管了）。
  • 2.NSOperation可以方便的指定操作間的依賴關(guān)系瞬欧。
  • 3.NSOperation可以通過KVO提供對NSOperation對象的精細(xì)控制（如監(jiān)聽當(dāng)前操作是否被取消或是否已經(jīng)完成等）
  • 4.NSOperation可以方便的指定操作優(yōu)先級贷屎。操作優(yōu)先級表示此操作與隊(duì)列中其它操作之間的優(yōu)先關(guān)系，優(yōu)先級高的操作先執(zhí)行艘虎，優(yōu)先級低的后執(zhí)行钮追。
  • 5.通過自定義NSOperation的子類可以實(shí)現(xiàn)操作重用

18.請談一談蛋勺，自定義操作的好處？

• 自定義操作，對操作進(jìn)行封裝网严，那么以后在使用的時(shí)候只需要alloc init即可右犹，創(chuàng)建該操作的人不需要關(guān)系內(nèi)部的代碼實(shí)現(xiàn)桑包，信息隱蔽湾趾。
• 自定義操作有助于代碼重用

19.請簡單介紹GCD中的一次性代碼?

• 1.一次性代碼：

   static dispatch_once_t onceToken;
     dispatch_once(&onceToken, ^{
        NSLog(@"-------");
     });

• 2.特點(diǎn)：
  - 在整個(gè)程序運(yùn)行過程中block中的代碼只會(huì)被執(zhí)行一次
  - 一次性代碼本身是線程安全的
• 3.常用于單例模式的實(shí)現(xiàn)中

20.GCD中的dispatch_after是延遲把任務(wù)提交到隊(duì)列還是先提交到隊(duì)列再延遲執(zhí)行？

• 是延遲之后在把任務(wù)提交到隊(duì)列執(zhí)行唯鸭，把任務(wù)提交到隊(duì)列中在延遲執(zhí)行難度較大须蜗，不容易實(shí)現(xiàn).

21.請說明NSRunloop和線程的關(guān)系?

• 線程和runloop是一一對應(yīng)的關(guān)系(字典)
• 主線程對應(yīng)的runloop是默認(rèn)創(chuàng)建并啟動(dòng)的
• 子線程對應(yīng)的runloop需要手動(dòng)的創(chuàng)建并啟動(dòng)
• 如何獲得子線程對應(yīng)的runloop?[NSRunloop currentRunloop]該方法是懶加載的,在第一次調(diào)用該方法的時(shí)候發(fā)現(xiàn)該子線程對應(yīng)的runloop不存在則會(huì)直接創(chuàng)建一個(gè)runloop保存并且返回.
• 線程銷毀后runloop也要銷毀

22.請簡單說明NSCache的特點(diǎn)

• NSCache是蘋果推出專門用來處理內(nèi)存緩存的類
• NSCache默認(rèn)是線程安全的,在使用的時(shí)候可以不用考慮線程安全的問題
• NSCache使用方法和可變字典類似,當(dāng)緩存文件超過最大限度的時(shí)候會(huì)開啟一個(gè)回收過程,把最老的緩存對象回收
• NSCache可以設(shè)置緩存的const(成本)和緩存的數(shù)量

23.請簡單說明runloop中幾個(gè)類之間的相互關(guān)系（runloop & source & timer &observer &mode）

• runloop啟動(dòng)之后會(huì)選擇一種運(yùn)行模式，在執(zhí)行執(zhí)行會(huì)先檢查運(yùn)行模式內(nèi)部是否有source和timers,如果一個(gè)sourc或者是一個(gè)timer都沒有那么runlooop啟動(dòng)之后就立刻退出了目溉。
• runlooop的source有兩種分類方法明肮，按照以前的分類方法可以分為
  • 基于端口的
  • 自定義的
  • performSelector事件
  • 按照函數(shù)調(diào)用棧來劃分，可以分為source0和soucr1缭付。
• observer晤愧，可以用來監(jiān)聽當(dāng)前runloop運(yùn)行狀態(tài)的改變，注意（Core foundation框架）
• NSTimer必須添加到runloop中才會(huì)工作蛉腌，且其工作收到runloop運(yùn)行模式的影響官份。

24.請簡單介紹下SDWebImage框架？

• SDWebImage框架是一款非常流行的用來處理圖片下載和緩存的第三方框架
• SDWebImage框架為我們提供了高性能異步下載圖片的方案烙丛，內(nèi)部使用GCD等多線程相關(guān)技術(shù)
• 使用SDWebImage框架來下載圖片舅巷，它內(nèi)部默認(rèn)會(huì)對圖片進(jìn)行內(nèi)存緩存和磁盤緩存的二級緩存結(jié)構(gòu)
• 該框架為UIButton,UIImageView等UI控件提供了分類，能夠方便的處理相關(guān)控件圖片的遠(yuǎn)程下載和緩存設(shè)置
• 該框架內(nèi)部還提供了GIF圖片播放河咽，判斷圖片類型等一般功能

25.請問SDWebImage框架內(nèi)部在清理磁盤緩存的時(shí)候clearDisk方法和cleanDisk方法有什么區(qū)別钠右？

• clearDisk:直接把整個(gè)緩存文件刪除，刪除之后創(chuàng)建一個(gè)新的空文件;
• cleanDisk:先刪除過期的緩存文件忘蟹，然后計(jì)算當(dāng)前剩余緩存文件的大小,如果該數(shù)值超過設(shè)定的最大緩存大小飒房，那么久安全文件創(chuàng)建的時(shí)間從遠(yuǎn)到近依次刪除，直到整個(gè)剩余緩存文件大小小于設(shè)定的最大緩存大小為止媚值。

26.請問SDWebImage框架的框架結(jié)構(gòu)是怎么樣的狠毯？

• SDWebImage框架有幾個(gè)主要的組件：
  • 管理者（SDWebImageManager)
  • 緩存處理組件（SDImageCache）主要對下載的圖片進(jìn)行內(nèi)存緩存和磁盤緩存處理
  • 下載處理組件（SDWebImageDownloader|SDWebImageDownloadOperation）主要處理開子線程異步發(fā)送網(wǎng)絡(luò)請求下載圖片相關(guān)操作

27.請問SDWebImage框架內(nèi)部怎么處理內(nèi)存緩存的？

• 內(nèi)部使用NSCache來專門處理內(nèi)存緩存

28.請簡單說明NSRunloop的基本作用?

• 保持程序的持續(xù)運(yùn)行
• 處理App中的各種事件（比如觸摸事件褥芒、定時(shí)器事件嚼松、Selector事件）
• 節(jié)省CPU資源，提高程序性能：該做事時(shí)做事，該休息時(shí)休息

29.什么是runloop?

• 從字面意思看：運(yùn)行循環(huán)献酗、跑圈.其實(shí)它內(nèi)部就是do-while循環(huán)寝受，在這個(gè)循環(huán)內(nèi)部不斷地處理各種任務(wù)（比如Source、Timer罕偎、Observer）
• 一個(gè)線程對應(yīng)一個(gè)RunLoop很澄，主線程的RunLoop默認(rèn)已經(jīng)啟動(dòng)，子線程的RunLoop得手動(dòng)啟動(dòng)（調(diào)用run方法）
• RunLoop只能選擇一個(gè)Mode啟動(dòng)颜及，如果當(dāng)前Mode中沒
  何Source(Sources0甩苛、Sources1)、Timer器予，那么就直接退出RunLoop

30.runloop的自動(dòng)釋放池什么時(shí)候創(chuàng)建釋放浪藻？

• 當(dāng)runloop進(jìn)入的時(shí)候會(huì)創(chuàng)建一個(gè)自動(dòng)釋放池捐迫。
• 當(dāng)runloop退出的時(shí)候會(huì)把之前的自動(dòng)釋放池銷毀乾翔。
• 當(dāng)runloop即將進(jìn)入休眠的時(shí)候會(huì)把之前的自動(dòng)釋放池先銷毀，然后創(chuàng)建一個(gè)新的自動(dòng)釋放池施戴。

31.請簡單說明使用NSURLConnection發(fā)送網(wǎng)絡(luò)請求的幾種方法反浓？

• 使用NSURLConnection發(fā)送同步請求（[NSURLConnection sendSync....]）
• 使用NSURLConnection發(fā)送異步請求1（[NSURLConnection sendAsync...]）
• 使用NSURLConnection發(fā)送異步請求2（設(shè)置代理，再發(fā)送網(wǎng)絡(luò)請求）

同步 NSData *data = [NSURLConnection sendSync....]
異步 [NSURLConnection sendAsync]
代理 delegate

32.請簡單說明GET請求和POST個(gè)請求有什么區(qū)別,如何選擇赞哗？

• GET請求的參數(shù)直接用&拼接并以雷则？為分隔拼接在請求URL的后面
• POST請求的參數(shù)是轉(zhuǎn)換為二進(jìn)制設(shè)置在請求體傳遞的
• 如果僅僅只是索取數(shù)據(jù)獲得數(shù)據(jù)，那么建議使用GET請求肪笋，其他情況則建議使用POST請求月劈，相對而言POST請求安全性更好一些。

33.請簡單列出使用NSURLConnection發(fā)送一個(gè)異步POST網(wǎng)絡(luò)請求的步驟?

• 1.確定請求路徑（URL）
• 2.創(chuàng)建可變的請求對象（NSMutableURLRequest）
• 3.修改請求方法為POST請求
• 4.把參數(shù)拼接起來轉(zhuǎn)換為二進(jìn)制數(shù)據(jù)藤乙，設(shè)置請求體
• 5.使用NSURLConnection發(fā)送異步請求([NSURLConnection sendAsync....])
• 6.解析服務(wù)器返回的數(shù)據(jù)猜揪，查看請求結(jié)果

34.請簡單說明HTTP通信的過程？

• 1.請求：如果客戶端想要獲得相應(yīng)的數(shù)據(jù)坛梁，那么就對著服務(wù)器發(fā)送一個(gè)請求而姐，請求是客戶端向服務(wù)器索要數(shù)據(jù)的過程。
• 2.響應(yīng)：服務(wù)器接收到客戶端的請求之后划咐，需要對該請求作出反應(yīng)拴念，響應(yīng)是服務(wù)器端把數(shù)據(jù)返回給客戶端的過程。
• 3.請求分為兩部分褐缠，一個(gè)是請求頭政鼠，一個(gè)是請求體（GET請求沒有請求體）。其中請求頭是對客戶端信息和請求本身的描述队魏，而請求體存放要發(fā)送給服務(wù)器端的具體數(shù)據(jù)
• 4.響應(yīng)分為兩部分缔俄，一個(gè)是響應(yīng)頭，一個(gè)是響應(yīng)體。其中響應(yīng)頭是對服務(wù)器端信息和響應(yīng)數(shù)據(jù)本身的描述俐载，而響應(yīng)體存放要發(fā)送給客戶端的具體數(shù)據(jù)蟹略。

35.請簡單說明NSURLSession對比NSURLConnection的優(yōu)勢？

• session支持http2.0協(xié)議(iOS 9.0 +)
• 在處理下載任務(wù)的時(shí)候可以直接把數(shù)據(jù)下載到磁盤
• 支持后臺下載|上傳
• 同一個(gè)session發(fā)送多個(gè)請求遏佣，只需要建立一次連接（復(fù)用了TCP）
• 提供了全局的session并且可以統(tǒng)一配置挖炬，使用更加方便
• 下載的時(shí)候是多線程異步處理的效率更高

36.請簡單列出NSURLSession發(fā)送POST請求的步驟？

• 1.確定請求路徑(NSURL)
• 2.創(chuàng)建可變的請求對象(NSMutableURLRequest)
• 3.修改請求方法為POST(HTTPMethod)
• 4.把要傳遞的參數(shù)拼接状婶，轉(zhuǎn)換為二進(jìn)制數(shù)據(jù)意敛，設(shè)置為請求體(HTTPBody)
• 5.創(chuàng)建會(huì)話對象（NSURLSession shareSession）
• 6.根據(jù)會(huì)話對象來創(chuàng)建一個(gè)NSURLSessionDataTask任務(wù)
• 7.執(zhí)行請求Task (需要調(diào)用Resume方法)
• 8.拿到服務(wù)器返回的數(shù)據(jù)之后，解析數(shù)據(jù)

37.在發(fā)送網(wǎng)絡(luò)請求的時(shí)候膛虫，如果請求路徑中的參數(shù)有中文導(dǎo)致發(fā)送的網(wǎng)絡(luò)請求失敗草姻，應(yīng)該如何處理？

• 如果URL字符串中有中文稍刀，那么在進(jìn)行使用發(fā)送請求的時(shí)候應(yīng)該先對URL進(jìn)行中文轉(zhuǎn)碼
• 相關(guān)方法：

[urlStr stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]

38.觀察下面的代碼撩独，請問completionHandler在主線程還是子線程執(zhí)行？

[[session dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {

    //....

}] resume];

• completionHandler在子線程中執(zhí)行账月。

39.請簡單介紹下網(wǎng)絡(luò)響應(yīng)的狀態(tài)碼综膀？

• 狀態(tài)碼的職責(zé)是當(dāng)客戶端向服務(wù)器端發(fā)送請求時(shí),描述返回的請求結(jié)果。借助狀態(tài)碼,用戶可以知道服務(wù)器端是正常處理了請求還是出現(xiàn)了錯(cuò)誤局齿。
• 如200 OK狀態(tài)碼以3位數(shù)字+原因短語組成剧劝。數(shù)字中的第一位指定了響應(yīng)的類別, 后兩位無分類。
• 狀態(tài)碼分為五種類別抓歼，分別是：
  • 以1開頭的（如100）讥此，定義范圍為100~101，表示接收的請求正在處理谣妻，原因短語為Informational(信息性狀 態(tài)碼)萄喳。
  • 以2開頭的（如200），定義范圍為200~206拌禾，表示請求正常處理完畢取胎，原因短語為Success(成功狀態(tài)碼)。
  • 以3開頭的（如300）湃窍，定義范圍為300~305闻蛀，表示需要進(jìn)行附加的操作以完成網(wǎng)絡(luò)請求，原因短語為Redirection(重定向狀態(tài) 碼)您市。
  • 以4開頭的（如404）觉痛，定義范圍為400~415，表示客戶端有錯(cuò)誤茵休，服務(wù)器無法處理請求薪棒，原因短語為Client error(客戶端錯(cuò)誤)手蝎。
  • 以5開頭的（如500），定義范圍為500~505俐芯，表示服務(wù)器端處理請求出錯(cuò)棵介，原因短語為Server error(服務(wù)器錯(cuò)誤)。

40.使用NSURLSession發(fā)送網(wǎng)絡(luò)請求的時(shí)候吧史，最多可以建立多少個(gè)TCP連接邮辽？

• 在iOS中最多可以建立4個(gè)連接，在OSX中默認(rèn)最多可以建立6個(gè)連接贸营。
• 在iOS中NSURLSessionConguration內(nèi)部有HTTPMaximumConnectionsPerHost屬性,可以設(shè)置連接的數(shù) 量:The default value is 6 in OS X, or 4 in iOS
• 說明：
  • 由于HTTP/1.1 不支持多路復(fù)用,因此如果要處理多個(gè)網(wǎng)絡(luò)請求,在處理HTTP請求的時(shí)候 多數(shù)瀏覽器廠商都是不假思索的就在客戶端排隊(duì)所有的HTTP請求,然后通過一個(gè)持久連接,一個(gè)接著一個(gè)的發(fā)送這些請求吨述。然而這種方式性能實(shí)在太差。實(shí)際上,瀏覽器開發(fā)商對于對于此性能問題,尚沒有任何更好的辦法,因此只能允許客戶端并行打開多個(gè)TCP連接會(huì)話钞脂。但是具體最多可以打開多少個(gè)TCP連接是有數(shù)量限制的, 多數(shù)現(xiàn)代的瀏覽器,包括桌面和移動(dòng)瀏覽器,都支持打開6個(gè)連接揣云。即客戶端可以并行分派最多6個(gè)請求,服務(wù)器可以并行處理最多6個(gè)請求。
  • 為什么是6個(gè)連接?有什么特殊的意義嗎?其實(shí)冰啃，這個(gè)數(shù)字是多方平衡后的結(jié)果:這個(gè)數(shù)字越大,便能夠帶來更多的請求并行能力,但是同樣的客戶端和服務(wù)器端所占用的資源也會(huì)越多邓夕。因此,每個(gè)主機(jī)6個(gè)連接只不過是大家都覺得比較安全,能夠接受的一個(gè)數(shù)字而已。

41.請簡單介紹JSON和XML亿笤？

• JSON和XML都是一種用來表示數(shù)據(jù)的一種數(shù)據(jù)格式翎迁，JSON更加輕量級栋猖。
• 服務(wù)器返回的數(shù)據(jù)通常是JSON的或者是XML的兩種净薛，JSON數(shù)據(jù)格式和OC對象中字典和數(shù)組有些相似，XML又稱為XML文檔蒲拉，XML的語法結(jié)構(gòu)由三部分構(gòu)成分別是文檔聲明肃拜，元素和屬性。
• 如果服務(wù)器返回的數(shù)據(jù)是JSON雌团，那么在開發(fā)中通常需要對JSON數(shù)據(jù)進(jìn)行反序列化處理燃领，把JSON數(shù)據(jù)轉(zhuǎn)換為OC對象。
• 如果服務(wù)器返回的數(shù)據(jù)是XML格式的锦援，那么需要對XML文檔進(jìn)行解析猛蔽，解析XML的方式有兩種，分別是SAX（從根元素開始解析）和DOM(先把整個(gè)XML文檔加載進(jìn)內(nèi)存再解析)

42.JSON格式中的true和false,對應(yīng)OC中的什么數(shù)據(jù)類型灵寺，值為多少曼库？

• true和false對應(yīng)OC中的NSNumber數(shù)據(jù)類型
• true對應(yīng)的值為1，false對應(yīng)的值為0

43.請簡單說明什么是序列化和反序列處理略板，用到了什么方法毁枯？

• 反序列化處理，即把JSON數(shù)據(jù)--->OC對象叮称，使用的方法為：[NSJSONSerialization JSONObjectWithData:jsonData options:kNilOptions error:nil]
• 序列化處理种玛，即把OC對象--->JSON數(shù)據(jù)藐鹤，使用的方法為：[NSJSONSerialization dataWithJSONObject:jsonString options:0 error:nil],注意并不是所有的OC對象都能夠序列化為JSON數(shù)據(jù)

44.請簡單說明輸出流的使用步驟【應(yīng)用于文件下載時(shí)】和注意點(diǎn)？

• 使用步驟：
  • 1.創(chuàng)建輸出流（指定路徑）
  • 2.打開輸出流（open）
  • 3.使用輸出流寫數(shù)據(jù) （write...）
  • 4.關(guān)閉輸出流 （close）
• 注意點(diǎn)：數(shù)據(jù)寫完之后一定要關(guān)閉輸出流

45.請簡單說明文件句柄（NSFileHandle）的使用步驟【應(yīng)用于文件下載時(shí)】和注意點(diǎn)赂韵？

• 使用步驟：
  • 1.創(chuàng)建空的文件（路徑）
  • 2.創(chuàng)建文件句柄（指向文件） 默認(rèn)指向開頭
  • 3.使用文件句柄來寫數(shù)據(jù)（內(nèi)部邊寫數(shù)據(jù)邊移動(dòng)文件句柄指針）
  • 4.關(guān)閉文件句柄(closeFile)
  • 注意點(diǎn)：
    • 1.在寫使用文件句柄指針寫數(shù)據(jù)的時(shí)候娱节，內(nèi)部會(huì)自動(dòng)移動(dòng)文件句柄指針
    • 2.寫數(shù)據(jù)的時(shí)候可以設(shè)置位置（偏移量），如設(shè)置從文件的末尾接著寫數(shù)據(jù)
    • 3.使用完畢之后祭示，應(yīng)該把句柄關(guān)閉

46.請簡單介紹下NSURLSessionTask的幾個(gè)子類括堤？

• NSURLSessionTask是一個(gè)抽象類，如果要使用那么只能使用它的子類;
• NSURLSessionTask有兩個(gè)子類绍移，一個(gè)是NSURLSessionDataTask,該task可以用來處理一般的網(wǎng)絡(luò)請求悄窃，如GET|POST請求等，一個(gè)是NSURLSessionDownloadTask,該downloadTask在處理下載請求的時(shí)候有很大的優(yōu)勢;
• NSURLSessionDataTask有一個(gè)子類為NSURLSessionUploadTask,該uploadTask在處理上傳請求的時(shí)候有優(yōu)勢.

47.請簡單介紹在iOS開發(fā)中XML的幾種解析方式蹂窖？

• XML文檔有兩種解析模式轧抗，一種是SAX（從根元素開發(fā)一個(gè)接著一個(gè)的解析），一種是DOM(將整個(gè)XML文檔加載進(jìn)內(nèi)存解析)
• 在iOS開發(fā)中常用的XML的解析方法有兩種瞬测，一種是使用蘋果原生的NSXMLParser來解析（該方法基于SAX）,一種是使用谷歌公司提供的第三方框架GDataXML來解析（該方法基于DOM）

DOM 一次性加載 GDataXML
SAX 一個(gè)元素一個(gè)元素的解析 NSXMLParser(創(chuàng)建解析器->設(shè)置代理->開始解析)

48.如何解決session設(shè)置代理之后對代理對象的強(qiáng)引用問題横媚？

• NSURLSession對象在使用的時(shí)候，如果設(shè)置了代理月趟，那么session對代理對象會(huì)保持一個(gè)強(qiáng)引用灯蝴，在合適的時(shí)候應(yīng)該主動(dòng)進(jìn)行釋放
• 可以在控制器調(diào)用viewDidDisappear方法的時(shí)候來進(jìn)行處理，可以通過調(diào)用invalidateAndCancel方法或者是finishTasksAndInvalidate方法來釋放對代理對象的強(qiáng)引用
• invalidateAndCancel方法直接取消請求然后釋放代理對象孝宗，finishTasksAndInvalidate方法等請求完成之后釋放代理對象穷躁。

49.在XCode中如何配置以MRC的方式來編譯處理某個(gè)類？

• 點(diǎn)擊項(xiàng)目的Targets因妇，點(diǎn)擊Build phases(編譯階段)问潭，點(diǎn)擊展開Compile Sources,找到要處理的類，配置為-fno-objc-arc即可婚被。

50.在使用NSURLSessionDataTask發(fā)送請求下載文件的時(shí)候狡忙，實(shí)現(xiàn)斷點(diǎn)下載的技術(shù)要點(diǎn)是什么？

• 所謂斷點(diǎn)下載址芯，即只下載完整文件中的某一部分?jǐn)?shù)據(jù)灾茁，如該文件有10M，那么需要做到只請求下載這個(gè)文件中5M~10M的這部分?jǐn)?shù)據(jù)
• 可以通過設(shè)置請求頭信息來實(shí)現(xiàn)谷炸，參考代碼如下：

 NSString *header = [NSString stringWithFormat:@"bytes=%zd-",self.currentSize];
 [request setValue:header forHTTPHeaderField:@"Range"]

51.請簡單比較使用NSURLSessionDownloadTask下載文件和使用NSURLSessionDataTask下載文件的優(yōu)劣北专？

• NSURLSessionDataTask下載文件的優(yōu)點(diǎn)：可以實(shí)現(xiàn)離線斷點(diǎn)下載。缺點(diǎn)：代碼復(fù)雜
• NSURLSessionDownloadTask下載文件的優(yōu)點(diǎn)：
  • 內(nèi)部已經(jīng)完成了邊接收數(shù)據(jù)邊寫入到沙盒中的操作（解決了下載大文件時(shí)候的內(nèi)存飆升問題）
  • 可以方便的實(shí)現(xiàn)斷點(diǎn)下載
• 缺點(diǎn)：無法實(shí)現(xiàn)離線斷點(diǎn)下載

52.請列出使用NSURLSession發(fā)送請求實(shí)現(xiàn)文件上傳的主要步驟淑廊？

• 1.確定上傳請求的路徑 （NSURL）
• 2.創(chuàng)建可變的請求對象（NSMutableURLRequest）
• 3.修改請求方法為POST
• 4.設(shè)置請求頭信息（告知服務(wù)器端這是一個(gè)文件上傳請求）
• 5.按照固定的格式拼接要上傳的文件等參數(shù)
• 6.根據(jù)請求對象創(chuàng)建會(huì)話對象（NSURLSession對象）
• 7.根據(jù)session對象來創(chuàng)建一個(gè)uploadTask上傳請求任務(wù)
• 8.執(zhí)行該上傳請求任務(wù)（調(diào)用resume方法）
• 9.得到服務(wù)器返回的數(shù)據(jù)逗余，解析數(shù)據(jù)（上傳成功|上傳失敗）

53.請列出你認(rèn)為在進(jìn)行文件上傳時(shí)候需要注意的細(xì)節(jié)(注意點(diǎn))季惩？

• 1.創(chuàng)建可變的請求對象录粱，因?yàn)樾枰薷恼埱蠓椒镻OST腻格，設(shè)置請求頭信息
• 2.設(shè)置請求頭這個(gè)步驟可能會(huì)被遺漏
• 3.要處理上傳參數(shù)的時(shí)候，一定要按照固定的格式來進(jìn)行拼接
• 4.需要采用合適的方法來獲得上傳文件的二進(jìn)制數(shù)據(jù)類型（MIMEType）

54.請簡單說明能夠獲得文件二進(jìn)制數(shù)據(jù)類型（MIMEType）的幾種方法啥繁？

• 直接百度 搜索
• 對著該文件發(fā)送一個(gè)網(wǎng)絡(luò)請求菜职，接受到該請求響應(yīng)的時(shí)候，可以通過響應(yīng)頭信息中的MIMEType屬性得到
• 使用通用的二進(jìn)制數(shù)據(jù)類型表示任意的二進(jìn)制數(shù)據(jù) application/octet-stream
• 調(diào)用C語言的API來實(shí)現(xiàn)

55.請簡單介紹下AFN各個(gè)主要版本的情況旗闽？

 0.1--1.0            "2.0---2.6.3"                    3.0-->3.1.0
 NSURLConnection - (NSURLConnection + NSURLSession) - NSURLSessio

0.1-2.0  NSURLConnection
2.0 -3.0 NSURLSession + NSURLConnection
3.0 + NSURLSession

56.如果服務(wù)器返回的數(shù)據(jù)不是JSON數(shù)據(jù)酬核，那么在使用AFN發(fā)送網(wǎng)絡(luò)請求的時(shí)候會(huì)請求失敗請問是什么原因產(chǎn)生的？如何解決适室？

• AFN在接受到服務(wù)器返回?cái)?shù)據(jù)的時(shí)候嫡意，內(nèi)部默認(rèn)采用以JSON的方式來對響應(yīng)體信息進(jìn)行反序列化處理，而如果服務(wù)器返回的數(shù)據(jù)不是JSON而是其他數(shù)據(jù)比如XML數(shù)據(jù)或者是圖片數(shù)據(jù)的時(shí)候就會(huì)提示網(wǎng)絡(luò)請求失敗
• 如果服務(wù)器返回的數(shù)據(jù)不是JSON捣辆，那么應(yīng)該修改AFN對響應(yīng)的解析方式
  • 如果是XML數(shù)據(jù)蔬螟，則:

manager.responseSerializer = [AFXMLParserResponseSerializer serializer]

- 如果既不是JSON也不是XML，則manager.responseSerializer = [AFHTTPResponseSerializer serializer]

57.在使用NSURLSession進(jìn)行文件上傳的時(shí)候汽畴，如何監(jiān)聽文件上傳的進(jìn)度旧巾，有哪些注意點(diǎn)？

• 創(chuàng)建會(huì)話對象的時(shí)候忍些，需要設(shè)置代理鲁猩，讓控制器成為session的代理

• 遵守代理協(xié)議（NSURLSessionDataDelegate）

• 實(shí)現(xiàn)代理方法，在代理方法中計(jì)算文件的上傳進(jìn)度

         - (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task

         didSendBodyData:(int64_t)bytesSent

         totalBytesSent:(int64_t)totalBytesSent

         totalBytesExpectedToSend:(int64_t)totalBytesExpectedToSend

• 注意：當(dāng)任務(wù)執(zhí)行完畢的時(shí)候應(yīng)該釋放對代理對象的強(qiáng)引用

58.請簡單說明系統(tǒng)默認(rèn)提供的NSURLSessionConfiguration三種配置信息罢坝？

• "defaultSessionConfiguration"返回標(biāo)準(zhǔn)配置廓握，這實(shí)際上與NSURLConnection的網(wǎng)絡(luò)協(xié)議棧是一樣的，具有相同的共享NSHTTPCookieStorage炸客，共享NSURLCache和共享NSURLCredentialStorage

• "ephemeralSessionConfiguration"返回一個(gè)預(yù)設(shè)配置疾棵，沒有持久性存儲(chǔ)的緩存戈钢，Cookie或證書痹仙。這對于實(shí)現(xiàn)像"秘密瀏覽"功能的功能來說，是很理想的

• "backgroundSessionConfiguration"：獨(dú)特之處在于殉了，它會(huì)創(chuàng)建一個(gè)后臺會(huì)話开仰。后臺會(huì)話不同于常規(guī)的，普通的會(huì)話薪铜，它甚至可以在應(yīng)用程序掛起众弓，退出，崩潰的情況下運(yùn)行上傳和下載任務(wù)隔箍。初始化時(shí)指定的標(biāo)識符谓娃，被用于向任何可能在進(jìn)程外恢復(fù)后臺傳輸?shù)氖刈o(hù)進(jìn)程提供上下文

59.在發(fā)送網(wǎng)絡(luò)請求的時(shí)候，如果一個(gè)參數(shù)（place）需要對應(yīng)著多個(gè)值蜒滩，那么以下兩種請求路徑哪種是正確的滨达？

①:[http://192.168.31.520:1314/loveyou?place=Beijing&Shanghai](http://120.25.226.186:32812/weather?place=Beijing&Shanghai)

②:[http://](http://120.25.226.186:32812/weather?place=Beijing&place=Shanghai)[192.168.31.520:1314](http://120.25.226.186:32812/weather?place=Beijing&Shanghai)/loveyou?place=Beijing&place=Shanghai

第二種請求路徑是正確的奶稠，第一種是錯(cuò)誤的，后面的shanghai將會(huì)被忽略

60.使用AFN進(jìn)行文件下載相對于NSURLSessionDownloadTask而言有何好處捡遍？

• 可以很方便的監(jiān)聽文件的下載進(jìn)度

• NSURLSessionDownloadTask在實(shí)現(xiàn)文件下載的時(shí)候锌订，內(nèi)部默認(rèn)把文件下載到了tmp臨時(shí)路徑，等下載完畢之后我們需要執(zhí)行一個(gè)剪切操作

• AFN下載請求的實(shí)現(xiàn)內(nèi)部基于NSURLSessionDownloadTask画株，在使用的時(shí)候只需要告知AFN應(yīng)該把文件剪切到什么路徑辆飘，那么AFN內(nèi)部會(huì)自動(dòng)的進(jìn)行文件剪切處理

61.請簡單回答網(wǎng)絡(luò)安全的原則是什么？

• 在網(wǎng)絡(luò)上"不允許"傳輸用戶隱私數(shù)據(jù)的"明文"
• 在本地"不允許"保存用戶隱私數(shù)據(jù)的"明文"

62.請簡單介紹下Base64編碼谓传？

• 特點(diǎn)：可以將任意的二進(jìn)制數(shù)據(jù)進(jìn)行Base64編碼
• 結(jié)果：所有的數(shù)據(jù)都能被編碼為并只用65個(gè)字符就能表示的文本文件蜈项。65字符：A~Z a~z 0~9 + / =
• 對文件進(jìn)行base64編碼后文件數(shù)據(jù)的變化：編碼后的數(shù)據(jù)~=編碼前數(shù)據(jù)的4/3，會(huì)大1/3左右续挟。
• Base64編碼原理:

  • 將所有字符轉(zhuǎn)化為ASCII碼战得；

  • 將ASCII碼轉(zhuǎn)化為8位二進(jìn)制；

  • 將二進(jìn)制3個(gè)歸成一組(不足3個(gè)在后邊補(bǔ)0)共24位庸推，再拆分成4組常侦，每組6位；

  • 統(tǒng)一在6位二進(jìn)制前補(bǔ)兩個(gè)0湊足8位贬媒；

  • 將補(bǔ)0后的二進(jìn)制轉(zhuǎn)為十進(jìn)制聋亡；

  • 從Base64編碼表獲取十進(jìn)制對應(yīng)的Base64編碼

63.請簡單說明單向散列函數(shù)的特點(diǎn)？

• 加密后密文的長度是定長的
• 如果明文不一樣际乘，那么散列后的結(jié)果一定不一樣
• 如果明文一樣坡倔，那么加密后的密文一定一樣（對相同數(shù)據(jù)加密，加密后的密文一樣）
• 所有的加密算法是公開的
• 不可以逆推反算
  • 總結(jié)：
    • 1 不可逆
    • 2 原文相同 散列值相同
    • 3 原文不同 散列值不同
    • 4 加密后密文的長度是定長的

64.請簡單介紹下散列函數(shù)的一些應(yīng)用領(lǐng)域脖含？

• 搜索 多個(gè)關(guān)鍵字罪塔，先對每個(gè)關(guān)鍵字進(jìn)行散列，然后多個(gè)關(guān)鍵字進(jìn)行或運(yùn)算养葵，如果值一致則搜索結(jié)果一致
• 版權(quán) 對文件進(jìn)行散列判斷該文件是否是正版或原版的
• 文件完整性驗(yàn)證 對整個(gè)文件進(jìn)行散列征堪，比較散列值判斷文件是否完整或被篡改

65.請簡單介紹下對稱加密的特點(diǎn)和經(jīng)典算法？

• 特點(diǎn):
  • 加密和解密使用相同的秘鑰
  • 加密和解密的過程是可逆的
  • 性能好关拒，效率高
• 經(jīng)典算法
  • DES 數(shù)據(jù)加密標(biāo)準(zhǔn)
  • 3DES 使用3個(gè)密鑰佃蚜，對消息進(jìn)行（密鑰1·加密）+（密鑰2·解密）+（密鑰3·加密）
  • AES 高級加密標(biāo)準(zhǔn)

66.請簡單說明ECB和CBC兩種分組加密模式？

• ECB模式的全稱為Electronic CodeBook模式着绊。又成為電子密碼本模式谐算。
  • 特點(diǎn)：
    • 使用ECB模式加密的時(shí)候，相同的明文分組會(huì)被轉(zhuǎn)換為相同的密文分組归露。
    • 類似于一個(gè)巨大的明文分組——密文分組的對照表洲脂。
• CBC模式全稱為Cipher Block Chainning模式（密文分組鏈接模式|電子密碼鏈條）
  • 特點(diǎn)：
    • 在CBC模式中，首先將明文分組與前一個(gè)密文分組進(jìn)行XOR運(yùn)算剧包，然后再進(jìn)行加密恐锦。

67.請簡單介紹下非對稱加密的特點(diǎn)和經(jīng)典算法雇毫？

• 非對稱加密的特點(diǎn):
  • 使用一個(gè)密鑰對進(jìn)行加密和解密，公鑰加密踩蔚，私鑰解密
  • 公鑰是公開的棚放，私鑰是保密的
  • 使用非對稱加密來處理加密和解密的過程高度安全，但是效率低下馅闽，性能很差
• 經(jīng)典算法：RSA

68.請簡單介紹下數(shù)字簽名這門技術(shù)飘蚯？

• 應(yīng)用場景：需要嚴(yán)格驗(yàn)證發(fā)送方身份信息情況
• 數(shù)字簽名原理
  • 客戶端處理
    • 對"消息"進(jìn)行 HASH 得到 "消息摘要"
    • 發(fā)送方使用自己的私鑰對"消息摘要" 加密(數(shù)字簽名)
    • 把數(shù)字簽名附著在"報(bào)文"的末尾一起發(fā)送給接收方
  • 服務(wù)端處理
    • 對"消息" HASH 得到 "報(bào)文摘要"
    • 使用公鑰對"數(shù)字簽名" 解密
    • 對結(jié)果進(jìn)行匹配

69.數(shù)字證書和公鑰什么關(guān)系？

• 數(shù)字證書就是對公鑰進(jìn)行數(shù)字簽名
• 證書和駕照很相似福也，里面記有姓名局骤、組織、地址等個(gè)人信息暴凑，以及屬于此人的公鑰峦甩，并有認(rèn)證機(jī)構(gòu)施加數(shù)字簽名,只要看到公鑰證書，我們就可以知道認(rèn)證機(jī)構(gòu)認(rèn)證該公鑰的確屬于此人
• 數(shù)字證書的主要內(nèi)容：
  • 公鑰
  • 認(rèn)證機(jī)構(gòu)的數(shù)字簽名

70.請簡單說明在安裝cocoapods時(shí)现喳，使用pod install命令安裝框架后的大致過程凯傲？

• 1.分析依賴:該步驟會(huì)分析Podfile,查看不同類庫之間的依賴情況。如果有多個(gè)類庫依賴于同一個(gè)類庫嗦篱，但是依賴于不同的版本冰单，那么cocoaPods會(huì)自動(dòng)設(shè)置一個(gè)兼容的版本。
• 2.下載依賴:根據(jù)分析依賴的結(jié)果灸促，下載指定版本的類庫到本地項(xiàng)目中诫欠。
• 3.生成Pods項(xiàng)目：創(chuàng)建一個(gè)Pods項(xiàng)目專門用來編譯和管理第三方框架，CocoaPods會(huì)將所需的框架浴栽，庫等內(nèi)容添加到項(xiàng)目中荒叼，并且進(jìn)行相應(yīng)的配置。
• 4.整合Pods項(xiàng)目：將Pods和項(xiàng)目整合到一個(gè)工作空間中典鸡，并且設(shè)置文件鏈接被廓。

PDF3文件下載