導讀7月，iOS求職跳槽的相對較少，能在這個時間段求職的，不是被迫，就是對自己的技術很自信；針對7月，特別總結了第二份iOS常見大廠面試題（中）;iOS面試題分....

7月，iOS求職跳槽的相對較少，能在這個時間段求職的，不是被迫，就是對自己的技術很自信； 針對7月，特別總結了第二份iOS常見大廠面試題（中）;

iOS面試題分為 上、中、下三部分，方便大家觀看;

請先自己答一答！

話不多說；直接上題本文收錄：公眾號【iOS進階寶典《iOS底層面試題（中篇））》】

6: iOS中內(nèi)省的幾個方法？class方法和objc_getClass方法有什么區(qū)別?

• 1: 什么是內(nèi)省？

在計算機科學中，內(nèi)省是指計算機程序在運行時（Run time）檢查對象（Object）類型的一種能力，通常也可以稱作運行時類型檢查。 不應該將內(nèi)省和反射混淆。相對于內(nèi)省，反射更進一步，是指計算機程序在運行時（Run time）可以訪問、檢測和修改它本身狀態(tài)或行為的一種能力。

• 2：iOS中內(nèi)省的幾個方法？

isMemberOfClass //對象是否是某個類型的對象

isKindOfClass //對象是否是某個類型或某個類型子類的對象 isSubclassOfClass //某個類對象是否是另一個類型的子類 isAncestorOfObject //某個類對象是否是另一個類型的父類 respondsToSelector //是否能響應某個方法 conformsToProtocol //是否遵循某個協(xié)議

• 3:class方法分類方法和對象方法。

實例class方法就直接返回object_getClass(self)類class方法直接返回self

• 4.object_getClass()獲取的是類型，對象.isa --->類.isa --->元類.isa ---> 父元類.isa ---> 根元類.isa ---> 自己（還是根元類）

7: 分類和擴展有什么區(qū)別？可以分別用來做什么？分類有哪些局限性？分類的結構體里面有哪些成員？

1:分類主要用來為某個類添加方法，屬性，協(xié)議（我一般用來為系統(tǒng)的類擴展方法或者把某個復雜的類的按照功能拆到不同的文件里）2:擴展主要用來為某個類原來沒有的成員變量、屬性、方法。注：方法只是聲明（我一般用擴展來聲明私有屬性，或者把.h的只讀屬性重寫成可讀寫的）

分類和擴展的區(qū)別：

分類是在運行時把分類信息合并到類信息中，而擴展是在編譯時，就把信息合并到類中的

分類聲明的屬性，只會生成對應的成員變量，不會有getter/setter方法的聲明和實現(xiàn)，而擴展會有。

分類不可用為類添加實例變量，而擴展可以

分類可以為類添加方法的實現(xiàn)，而擴展只能聲明方法，而不能實現(xiàn)

分類的局限性：

無法為類添加實例變量，但可通過關聯(lián)對象進行實現(xiàn)，注：關聯(lián)對象中內(nèi)存管理沒有weak，用時需要注意野指針的問題，可通過其他辦法來實現(xiàn)，具體可參考iOS weak 關鍵字漫談 分類的方法若和類中原本的實現(xiàn)重名，會覆蓋原本方法的實現(xiàn)，注：并不是真正的覆蓋

多個分類的方法重名，會調(diào)用最后編譯的那個分類的實現(xiàn)

分類的結構體里有哪些成員

struct category_t { const char *name; //名字 classref_t cls; //類的引用 struct method_list_t *instanceMethods;//實例方法列表 struct method_list_t *classMethods;//類方法列表 struct protocol_list_t *protocols;//協(xié)議列表 struct property_list_t *instanceProperties;//實例屬性列表 // 此屬性不一定真正的存在 struct property_list_t *_classProperties;//類屬性列表};

8：能不能簡述一下 Dealloc 的實現(xiàn)機制

Dealloc 的實現(xiàn)機制是內(nèi)容管理部分的重點，把這個知識點弄明白，對于全方位的理解內(nèi)存管理的只是很有 必要。

1.Dealloc 調(diào)用流程

1.首先調(diào)用 _objc_rootDealloc()2.接下來調(diào)用 rootDealloc()3.這時候會判斷是否可以被釋放，判斷的依據(jù)主要有 5 個，判斷是否有以上五種情況NONPointer_ISAweakly_referencehas_assochas_cxx_dtorhas_sidetable_rc4-1.如果有以上五中任意一種，將會調(diào)用 object_dispose()方法，做下一步的處理。4-2.如果沒有之前五種情況的任意一種，則可以執(zhí)行釋放操作，C 函數(shù)的 free()。5.執(zhí)行完畢。

2.object_dispose() 調(diào)用流程。

直接調(diào)用 objc_DEStructInstance()。之后調(diào)用 C 函數(shù)的 free()。

3.objc_destructInstance() 調(diào)用流程

先判斷 hasCxxDtor，如果有 C 的相關內(nèi)容，要調(diào)用 object_cxxDestruct() ，銷毀 C 相關的內(nèi)容。再判斷 hasAssocitatedObjects，如果有的話，要調(diào)用 object_remove_associations()， 銷毀關聯(lián)對象的一系列操作。然后調(diào)用 clearDeallocating()。執(zhí)行完畢。

4.clearDeallocating() 調(diào)用流程。

先執(zhí)行 sideTable_clearDellocating()。再執(zhí)行 weak_clear_no_lock,在這一步驟中，會將指向該對象的弱引用指針置為 nil。接下來執(zhí)行 table.refcnts.eraser()，從引用計數(shù)表中擦除該對象的引用計數(shù)。至此為止，Dealloc 的執(zhí)行流程結束。

9：HTTPS和HTTP的區(qū)別

HTTPS協(xié)議 = HTTP協(xié)議 SSL/TLS協(xié)議

SSL的全稱是Secure Sockets Layer，即安全套接層協(xié)議，是為網(wǎng)絡通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。TLS的全稱是Transport Layer Security，即安全傳輸層協(xié)議。

即HTTPS是安全的HTTP。

https, 全稱Hyper Text Transfer Protocol Secure，相比http，多了一個secure，這一個secure是怎么來的呢？ 這是由TLS（SSL）提供的！大概就是一個叫openSSL的library提供的。 https和http都屬于application layer，基于TCP（以及UDP）協(xié)議，但是又完全不一樣。 TCP用的port是80， https用的是443 （值得一提的是，google發(fā)明了一個新的協(xié)議，叫QUIC，并不基于TCP，用的port也是443， 同樣是用來給https的。谷歌好牛逼啊。） 總體來說，https和http類似，但是比http安全。

10：TCP為什么要三次握手，四次揮手？

三次握手：

客戶端向服務端發(fā)起請求鏈接，首先發(fā)送SYN報文，SYN=1，seq=x,并且客戶端進入SYN_SENT狀態(tài)服務端收到請求鏈接，服務端向客戶端進行回復，并發(fā)送響應報文，SYN=1，seq=y,ACK=1,ack=x 1,并且服務端進入到SYN_RCVD狀態(tài)客戶端收到確認報文后，向服務端發(fā)送確認報文，ACK=1，ack=y 1，此時客戶端進入到ESTABLISHED，服務端收到用戶端發(fā)送過來的確認報文后，也進入到ESTABLISHED狀態(tài)，此時鏈接創(chuàng)建成功

四次揮手：

客戶端向服務端發(fā)起關閉鏈接，并停止發(fā)送數(shù)據(jù)服務端收到關閉鏈接的請求時，向客戶端發(fā)送回應，我知道了，然后停止接收數(shù)據(jù)當服務端發(fā)送數(shù)據(jù)結束之后，向客戶端發(fā)起關閉鏈接，并停止發(fā)送數(shù)據(jù)客戶端收到關閉鏈接的請求時，向服務端發(fā)送回應，我知道了，然后停止接收數(shù)據(jù)

為什么需要三次握手：

為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產(chǎn)生錯誤，假設這是一個早已失效的報文段。 但server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求。 于是就向client發(fā)出確認報文段，同意建立連接。 假設不采用“三次握手”，那么只要server發(fā)出確認，新的連接就建立了。 由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認，也不會向server發(fā)送數(shù)據(jù)。 但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。 這樣，server的很多資源就白白浪費掉了。

為什么需要四次揮手：

因為TCP是全雙工通信的，在接收到客戶端的關閉請求時，還可能在向客戶端發(fā)送著數(shù)據(jù)，因此不能再回應關閉鏈接的請求時，同時發(fā)送關閉鏈接的請求

11. 對稱加密和非對稱加密的區(qū)別？分別有哪些算法的實現(xiàn)？

對稱加密，加密的加密和解密使用同一密鑰。

非對稱加密，使用一對密鑰用于加密和解密，分別為公開密鑰和私有密鑰。公開密鑰所有人都可以獲得，通信發(fā)送方獲得接收方的公開密鑰之后，就可以使用公開密鑰進行加密，接收方收到通信內(nèi)容后使用私有密鑰解密。對稱加密常用的算法實現(xiàn)有AES,ChaCha20,DES,不過DES被認為是不安全的;非對稱加密用的算法實現(xiàn)有RSA，ECC

12. HTTPS的握手流程？為什么密鑰的傳遞需要使用非對稱加密？雙向認證了解么？

HTTPS的握手流程，如下圖，摘自圖解HTTP

客戶端發(fā)送Client Hello 報文開始SSL通信。報文中包含客戶端支持的SSL的版本，加密組件列表。服務器收到之后，會以Server Hello 報文作為應答。和客戶端一樣，報文中包含客戶端支持的SSL的版本，加密組件列表。服務器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的服務器發(fā)送Certificate報文。報文中包含公開密鑰證書。然后服務器發(fā)送Server Hello Done報文通知客戶端，最初階段的SSL握手協(xié)商部分結束SSL第一次握手結束之后，客戶端以Client Key Exchange報文作為會議。報文中包含通信加密中使用的一種被稱為Pre-master secret的隨機密碼串接著客戶端發(fā)送Change Cipher Space報文。該報文會提示服務器，在次報文之后的通信會采用Pre-master secret密鑰加密客戶端發(fā)送Finished 報文。該報文包含鏈接至今全部報文的整體校驗值。這次握手協(xié)商是否能夠成功，要以服務器是否能夠正確揭秘該報文作為判定標準服務器同樣發(fā)送Change Cipher Space報文。服務器同樣發(fā)送Finished報文。服務器和客戶端的Finished報文交換完畢之后，SSL連接建立完成，從此開始HTTP通信，通信的內(nèi)容都使用Pre-master secret加密。然后開始發(fā)送HTTP請求應用層收到HTTP請求之后，發(fā)送HTTP響應最后有客戶端斷開連接

為什么密鑰的傳遞需要使用非對稱加密？

使用非對稱加密是為了后面客戶端生成的Pre-master secret密鑰的安全，通過上面的步驟能得知，服務器向客戶端發(fā)送公鑰證書這一步是有可能被別人攔截的，如果使用對稱加密的話，在客戶端向服務端發(fā)送Pre-master secret密鑰的時候，被黑客攔截的話，就能夠使用公鑰進行解碼，就無法保證Pre-master secret密鑰的安全了

雙向認證了解么？

上面的HTTPS的通信流程只驗證了服務端的身份，而服務端沒有驗證客戶端的身份，雙向認證是服務端也要確保客戶端的身份，大概流程是客戶端在校驗完服務器的證書之后，會向服務器發(fā)送自己的公鑰，然后服務端用公鑰加密產(chǎn)生一個新的密鑰，傳給客戶端，客戶端再用私鑰解密，以后就用此密鑰進行對稱加密的通信

文末推薦：iOS熱門文集&視頻解析①　Swift②　iOS底層技術③　iOS逆向防護④　iOS面試合集⑤ 大廠面試題 底層技術 逆向安防 Swift

喜歡的小伙伴記得點贊喔~

收藏等于白嫖，點贊才是真情?( ′???` )?