iOS基礎問答面試題連載(三)-附答案

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

iOSinterview.jpg

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

這次的問題是網(wǎng)絡多線程相關的喲，面試的時候也是必問的，大家多看看

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

  • 以下是一些自己收集的網(wǎng)絡多線程方面比較基礎的問題（大神可以忽略），附上答案，方便大家閱讀。俗話說得好，基礎不牢，地動山搖。文章末尾會提供PDF版的文檔，方便大家木有網(wǎng)的時候也可以用移動設備觀看。

1.請簡單說明多線程技術的優(yōu)點和缺點？

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

2.請簡單說明線程和進程，以及他們之間的關系？

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

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

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

4.請簡單說明主線程的作用，以及使用注意點？

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

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

新建->就緒 CPU調(diào)度當前任務->運行->阻塞->死亡
                            CPU調(diào)度其他任務->就緒

6.請簡單說明如何簡單的解決多線程訪問同一塊資源造成的線程安全的問題，以及注意點？

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

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

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

8.請簡單介紹下GCD這門技術？

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

9.請簡單介紹GCD中的幾種隊列？（4種）

  • 并發(fā)隊列：多個任務同時執(zhí)行，會開啟多個線程同時執(zhí)行任務，只有在異步函數(shù)下才有效。
  • 串行隊列：任務只能一個接一個的去執(zhí)行，不會開啟多個線程，主隊列屬于串行隊列，主隊列所有的任務必須在主線程中執(zhí)行。
  • 全局隊列
  • 主隊列

10.如果當前有多個任務，這些任務都需要開子線程執(zhí)行，而多個任務之間有一定的依賴關系，如果使用GCD來實現(xiàn)請試著給出一些解決方案。

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

11.請簡單說明單例模式的特點（作用）？

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

12.請簡單介紹操作隊列？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 1.一次性代碼：
   static dispatch_once_t onceToken;
     dispatch_once(&onceToken, ^{
        NSLog(@"-------");
     });
  • 2.特點：
    - 在整個程序運行過程中block中的代碼只會被執(zhí)行一次
    - 一次性代碼本身是線程安全的
  • 3.常用于單例模式的實現(xiàn)中

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

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

21.請說明NSRunloop和線程的關系?

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

22.請簡單說明NSCache的特點

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

23.請簡單說明runloop中幾個類之間的相互關系（runloop & source & timer &observer &mode）

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

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

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

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

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

26.請問SDWebImage框架的框架結(jié)構是怎么樣的？

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

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

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

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

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

29.什么是runloop?

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

30.runloop的自動釋放池什么時候創(chuàng)建釋放？

  • 當runloop進入的時候會創(chuàng)建一個自動釋放池。
  • 當runloop退出的時候會把之前的自動釋放池銷毀。
  • 當runloop即將進入休眠的時候會把之前的自動釋放池先銷毀，然后創(chuàng)建一個新的自動釋放池。

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

  • 使用NSURLConnection發(fā)送同步請求（[NSURLConnection sendSync....]）
  • 使用NSURLConnection發(fā)送異步請求1（[NSURLConnection sendAsync...]）
  • 使用NSURLConnection發(fā)送異步請求2（設置代理，再發(fā)送網(wǎng)絡請求）
同步 NSData *data = [NSURLConnection sendSync....]
異步 [NSURLConnection sendAsync]
代理 delegate

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

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

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

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

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

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

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

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

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

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

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

  • 如果URL字符串中有中文，那么在進行使用發(fā)送請求的時候應該先對URL進行中文轉(zhuǎ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)絡響應的狀態(tài)碼？

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

40.使用NSURLSession發(fā)送網(wǎng)絡請求的時候，最多可以建立多少個TCP連接？

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

41.請簡單介紹JSON和XML？

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

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

  • true和false對應OC中的NSNumber數(shù)據(jù)類型
  • true對應的值為1，false對應的值為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.請簡單說明輸出流的使用步驟【應用于文件下載時】和注意點？

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

45.請簡單說明文件句柄（NSFileHandle）的使用步驟【應用于文件下載時】和注意點？

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

46.請簡單介紹下NSURLSessionTask的幾個子類？

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

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

  • XML文檔有兩種解析模式，一種是SAX（從根元素開發(fā)一個接著一個的解析），一種是DOM(將整個XML文檔加載進內(nèi)存解析)
  • 在iOS開發(fā)中常用的XML的解析方法有兩種，一種是使用蘋果原生的NSXMLParser來解析（該方法基于SAX）,一種是使用谷歌公司提供的第三方框架GDataXML來解析（該方法基于DOM）
DOM 一次性加載 GDataXML
SAX 一個元素一個元素的解析 NSXMLParser(創(chuàng)建解析器->設置代理->開始解析)

48.如何解決session設置代理之后對代理對象的強引用問題？

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

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

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

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

  • 所謂斷點下載，即只下載完整文件中的某一部分數(shù)據(jù)，如該文件有10M，那么需要做到只請求下載這個文件中5M~10M的這部分數(shù)據(jù)
  • 可以通過設置請求頭信息來實現(xiàn)，參考代碼如下：
 NSString *header = [NSString stringWithFormat:@"bytes=%zd-",self.currentSize];
 [request setValue:header forHTTPHeaderField:@"Range"]

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

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

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

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

53.請列出你認為在進行文件上傳時候需要注意的細節(jié)(注意點)？

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

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

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

55.請簡單介紹下AFN各個主要版本的情況？

 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.如果服務器返回的數(shù)據(jù)不是JSON數(shù)據(jù)，那么在使用AFN發(fā)送網(wǎng)絡請求的時候會請求失敗請問是什么原因產(chǎn)生的？如何解決？

  • AFN在接受到服務器返回數(shù)據(jù)的時候，內(nèi)部默認采用以JSON的方式來對響應體信息進行反序列化處理，而如果服務器返回的數(shù)據(jù)不是JSON而是其他數(shù)據(jù)比如XML數(shù)據(jù)或者是圖片數(shù)據(jù)的時候就會提示網(wǎng)絡請求失敗
  • 如果服務器返回的數(shù)據(jù)不是JSON，那么應該修改AFN對響應的解析方式
    • 如果是XML數(shù)據(jù)，則:
manager.responseSerializer = [AFXMLParserResponseSerializer serializer]

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

57.在使用NSURLSession進行文件上傳的時候，如何監(jiān)聽文件上傳的進度，有哪些注意點？

  • 創(chuàng)建會話對象的時候，需要設置代理，讓控制器成為session的代理

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

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

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

         didSendBodyData:(int64_t)bytesSent

         totalBytesSent:(int64_t)totalBytesSent

         totalBytesExpectedToSend:(int64_t)totalBytesExpectedToSend
  • 注意：當任務執(zhí)行完畢的時候應該釋放對代理對象的強引用

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

  • "defaultSessionConfiguration"返回標準配置，這實際上與NSURLConnection的網(wǎng)絡協(xié)議棧是一樣的，具有相同的共享NSHTTPCookieStorage，共享NSURLCache和共享NSURLCredentialStorage

  • "ephemeralSessionConfiguration"返回一個預設配置，沒有持久性存儲的緩存，Cookie或證書。這對于實現(xiàn)像"秘密瀏覽"功能的功能來說，是很理想的

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

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

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

第二種請求路徑是正確的，第一種是錯誤的，后面的shanghai將會被忽略

60.使用AFN進行文件下載相對于NSURLSessionDownloadTask而言有何好處？

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

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

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

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

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

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

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

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

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

    • 將二進制3個歸成一組(不足3個在后邊補0)共24位，再拆分成4組，每組6位；

    • 統(tǒng)一在6位二進制前補兩個0湊足8位；

    • 將補0后的二進制轉(zhuǎn)為十進制；

    • 從Base64編碼表獲取十進制對應的Base64編碼

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

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

64.請簡單介紹下散列函數(shù)的一些應用領域？

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

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

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

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

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

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

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

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

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

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

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

70.請簡單說明在安裝cocoapods時，使用pod install命令安裝框架后的大致過程？

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

PDF3文件下載

最后編輯于 ：
?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

  • 1.請簡單說明多線程技術的優(yōu)點和缺點？ 優(yōu)點：能夠適當提高程序的執(zhí)行效率；能夠適當?shù)奶岣哔Y源的利用率，比如CPU、...
    deeper_iOS閱讀 1,554評論 1贊 12
  • *面試心聲:其實這些題本人都沒怎么背,但是在上海 兩周半 面了大約10家 收到差不多3個offer,總結(jié)起來就是把...
    Dove_iOS閱讀 27,656評論 30贊 472
  • 1.請簡單說明多線程技術的優(yōu)點和缺點？ 優(yōu)點能適當提高程序的執(zhí)行效率能適當提高資源的利用率(CPU/內(nèi)存利用率) ...
    彼岸的黑色曼陀羅閱讀 552評論 0贊 2
  • Spring Cloud為開發(fā)人員提供了快速構建分布式系統(tǒng)中一些常見模式的工具（例如配置管理，服務發(fā)現(xiàn)，斷路器，智...
    卡卡羅2017閱讀 136,695評論 19贊 139
  • 1. 父類實現(xiàn)深拷貝時，子類如何實現(xiàn)深度拷貝。父類沒有實現(xiàn)深拷貝時，子類如何實現(xiàn)深度拷貝。 1.1 深拷貝同淺拷貝...
    iYeso閱讀 1,980評論 0贊 13

友情鏈接更多精彩內(nèi)容