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

iOSinterview.jpg

<簡(jiǎn)書社區(qū) — Timhbw>iOS基礎(chǔ)問答面試題連載(一)-附答案
<簡(jiǎn)書社區(qū) — Timhbw>iOS基礎(chǔ)問答面試題連載(二)-附答案
<簡(jiǎn)書社區(qū) — Timhbw>iOS基礎(chǔ)問答面試題連載(三)-附答案
<簡(jiǎn)書社區(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.請(qǐng)簡(jiǎn)單說明多線程技術(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.請(qǐng)簡(jiǎn)單說明線程和進(jìn)程，以及他們之間的關(guān)系？

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

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

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

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

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

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

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

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

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

7.請(qǐng)簡(jiǎn)單介紹下什么是原子和非原子屬性？

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

8.請(qǐng)簡(jiǎn)單介紹下GCD這門技術(shù)？

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

9.請(qǐng)簡(jiǎn)單介紹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)請(qǐng)?jiān)囍o出一些解決方案。

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

11.請(qǐng)簡(jiǎn)單說明單例模式的特點(diǎn)（作用）？

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

12.請(qǐng)簡(jiǎn)單介紹操作隊(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.請(qǐng)簡(jiǎn)單比較GCD中的全局并發(fā)隊(duì)列和使用dispatch_queue_create函數(shù)創(chuàng)建的并發(fā)隊(duì)列異同？

• 1.全局并發(fā)隊(duì)列在整個(gè)應(yīng)用程序中本身是默認(rèn)存在的并且對(duì)應(yīng)有高優(yōu)先級(jí)、默認(rèn)優(yōu)先級(jí)、低優(yōu)先級(jí)和后臺(tái)優(yōu)先級(jí)一共四個(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)建的對(duì)象也不再需要開發(fā)人員手動(dòng)釋放，我們像對(duì)待普通OC對(duì)象一樣對(duì)待GCD就OK。
• 3.在使用柵欄函數(shù)的時(shí)候，柵欄函數(shù)只有在和使用create函數(shù)自己的創(chuàng)建的并發(fā)隊(duì)列一起使用的時(shí)候才有效
• 4.其它區(qū)別涉及到XNU內(nèi)核的系統(tǒng)級(jí)線程編程，不一一列舉。

15.請(qǐng)簡(jiǎn)單說明對(duì)圖片進(jìn)行二級(jí)緩存的實(shí)現(xiàn)思路？

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

16.請(qǐng)簡(jiǎn)單對(duì)比下GCD和NSOperation兩種多線程的實(shí)現(xiàn)方案？

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

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

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

18.請(qǐng)談一談，自定義操作的好處？

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

19.請(qǐng)簡(jiǎn)單介紹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.請(qǐng)說明NSRunloop和線程的關(guān)系?

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

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

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

23.請(qǐng)簡(jiǎn)單說明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.請(qǐng)簡(jiǎn)單介紹下SDWebImage框架？

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

25.請(qǐng)問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.請(qǐng)問SDWebImage框架的框架結(jié)構(gòu)是怎么樣的？

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

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

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

28.請(qǐng)簡(jiǎn)單說明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è)線程對(duì)應(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.請(qǐng)簡(jiǎn)單說明使用NSURLConnection發(fā)送網(wǎng)絡(luò)請(qǐng)求的幾種方法？

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

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

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

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

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

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

34.請(qǐng)簡(jiǎn)單說明HTTP通信的過程？

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

35.請(qǐng)簡(jiǎn)單說明NSURLSession對(duì)比NSURLConnection的優(yōu)勢(shì)？

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

36.請(qǐng)簡(jiǎn)單列出NSURLSession發(fā)送POST請(qǐng)求的步驟？

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

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

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

[urlStr stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]

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

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

    //....

}] resume];

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

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

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

40.使用NSURLSession發(fā)送網(wǎng)絡(luò)請(qǐng)求的時(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ò)請(qǐng)求,在處理HTTP請(qǐng)求的時(shí)候 多數(shù)瀏覽器廠商都是不假思索的就在客戶端排隊(duì)所有的HTTP請(qǐng)求,然后通過一個(gè)持久連接,一個(gè)接著一個(gè)的發(fā)送這些請(qǐng)求。然而這種方式性能實(shí)在太差。實(shí)際上,瀏覽器開發(fā)商對(duì)于對(duì)于此性能問題,尚沒有任何更好的辦法,因此只能允許客戶端并行打開多個(gè)TCP連接會(huì)話。但是具體最多可以打開多少個(gè)TCP連接是有數(shù)量限制的, 多數(shù)現(xiàn)代的瀏覽器,包括桌面和移動(dòng)瀏覽器,都支持打開6個(gè)連接。即客戶端可以并行分派最多6個(gè)請(qǐng)求,服務(wù)器可以并行處理最多6個(gè)請(qǐng)求。
  • 為什么是6個(gè)連接?有什么特殊的意義嗎?其實(shí)，這個(gè)數(shù)字是多方平衡后的結(jié)果:這個(gè)數(shù)字越大,便能夠帶來更多的請(qǐng)求并行能力,但是同樣的客戶端和服務(wù)器端所占用的資源也會(huì)越多。因此,每個(gè)主機(jī)6個(gè)連接只不過是大家都覺得比較安全,能夠接受的一個(gè)數(shù)字而已。

41.請(qǐng)簡(jiǎn)單介紹JSON和XML？

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

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

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

43.請(qǐng)簡(jiǎn)單說明什么是序列化和反序列處理，用到了什么方法？

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

44.請(qǐng)簡(jiǎn)單說明輸出流的使用步驟【應(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.請(qǐng)簡(jiǎn)單說明文件句柄（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.請(qǐng)簡(jiǎn)單介紹下NSURLSessionTask的幾個(gè)子類？

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

47.請(qǐng)簡(jiǎn)單介紹在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è)置代理之后對(duì)代理對(duì)象的強(qiáng)引用問題？

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

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

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

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

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

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

51.請(qǐng)簡(jiǎn)單比較使用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.請(qǐng)列出使用NSURLSession發(fā)送請(qǐng)求實(shí)現(xiàn)文件上傳的主要步驟？

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

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

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

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

• 直接百度 搜索
• 對(duì)著該文件發(fā)送一個(gè)網(wǎng)絡(luò)請(qǐng)求，接受到該請(qǐng)求響應(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.請(qǐng)簡(jiǎn)單介紹下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ò)請(qǐng)求的時(shí)候會(huì)請(qǐng)求失敗請(qǐng)問是什么原因產(chǎn)生的？如何解決？

• AFN在接受到服務(wù)器返回?cái)?shù)據(jù)的時(shí)候，內(nèi)部默認(rèn)采用以JSON的方式來對(duì)響應(yīng)體信息進(jìn)行反序列化處理，而如果服務(wù)器返回的數(shù)據(jù)不是JSON而是其他數(shù)據(jù)比如XML數(shù)據(jù)或者是圖片數(shù)據(jù)的時(shí)候就會(huì)提示網(wǎng)絡(luò)請(qǐng)求失敗
• 如果服務(wù)器返回的數(shù)據(jù)不是JSON，那么應(yīng)該修改AFN對(duì)響應(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ì)話對(duì)象的時(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)該釋放對(duì)代理對(duì)象的強(qiáng)引用

58.請(qǐng)簡(jiǎn)單說明系統(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或證書。這對(duì)于實(shí)現(xiàn)像"秘密瀏覽"功能的功能來說，是很理想的

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

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

①:[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

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

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

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

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

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

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

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

62.請(qǐng)簡(jiǎn)單介紹下Base64編碼？

• 特點(diǎn)：可以將任意的二進(jìn)制數(shù)據(jù)進(jìn)行Base64編碼
• 結(jié)果：所有的數(shù)據(jù)都能被編碼為并只用65個(gè)字符就能表示的文本文件。65字符：A~Z a~z 0~9 + / =
• 對(duì)文件進(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)制對(duì)應(yīng)的Base64編碼

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

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

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

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

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

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

66.請(qǐng)簡(jiǎn)單說明ECB和CBC兩種分組加密模式？

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

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

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

68.請(qǐng)簡(jiǎn)單介紹下數(shù)字簽名這門技術(shù)？

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

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

• 數(shù)字證書就是對(duì)公鑰進(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.請(qǐng)簡(jiǎn)單說明在安裝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文件下載