iOS底層面試題（中篇）

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

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

請(qǐng)先自己答一答！

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

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

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

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

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

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

  • 3:class方法分類方法和對(duì)象方法。
  • 實(shí)例class方法就直接返回object_getClass(self)
  • 類class方法直接返回self
  • 4.object_getClass()獲取的是類型，對(duì)象.isa --->類.isa --->元類.isa ---> 父元類.isa ---> 根元類.isa ---> 自己（還是根元類）

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

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

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

  • 分類是在運(yùn)行時(shí)把分類信息合并到類信息中，而擴(kuò)展是在編譯時(shí)，就把信息合并到類中的

  • 分類聲明的屬性，只會(huì)生成對(duì)應(yīng)的成員變量，不會(huì)有getter/setter方法的聲明和實(shí)現(xiàn)，而擴(kuò)展會(huì)有。

  • 分類不可用為類添加實(shí)例變量，而擴(kuò)展可以
    分類可以為類添加方法的實(shí)現(xiàn)，而擴(kuò)展只能聲明方法，而不能實(shí)現(xiàn)

分類的局限性：

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

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

分類的結(jié)構(gòu)體里有哪些成員

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

8：能不能簡(jiǎn)述一下 Dealloc 的實(shí)現(xiàn)機(jī)制

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

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

  • 1.首先調(diào)用 _objc_rootDealloc()
  • 2.接下來調(diào)用 rootDealloc()
  • 3.這時(shí)候會(huì)判斷是否可以被釋放，判斷的依據(jù)主要有 5 個(gè)，判斷是否有以上五種情況
    • NONPointer_ISA
    • weakly_reference
    • has_assoc
    • has_cxx_dtor
    • has_sidetable_rc
  • 4-1.如果有以上五中任意一種，將會(huì)調(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++ 的相關(guān)內(nèi)容，要調(diào)用 object_cxxDestruct()，銷毀 C++ 相關(guān)的內(nèi)容。
  • 再判斷 hasAssocitatedObjects，如果有的話，要調(diào)用 object_remove_associations()， 銷毀關(guān)聯(lián)對(duì)象的一系列操作。
  • 然后調(diào)用 clearDeallocating()。
  • 執(zhí)行完畢。

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

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

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

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

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

即HTTPS是安全的HTTP。

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

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

三次握手：

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

四次揮手：

  • 客戶端向服務(wù)端發(fā)起關(guān)閉鏈接，并停止發(fā)送數(shù)據(jù)
  • 服務(wù)端收到關(guān)閉鏈接的請(qǐng)求時(shí)，向客戶端發(fā)送回應(yīng)，我知道了，然后停止接收數(shù)據(jù)
  • 當(dāng)服務(wù)端發(fā)送數(shù)據(jù)結(jié)束之后，向客戶端發(fā)起關(guān)閉鏈接，并停止發(fā)送數(shù)據(jù)
  • 客戶端收到關(guān)閉鏈接的請(qǐng)求時(shí)，向服務(wù)端發(fā)送回應(yīng)，我知道了，然后停止接收數(shù)據(jù)

為什么需要三次握手：

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

為什么需要四次揮手：

因?yàn)門CP是全雙工通信的，在接收到客戶端的關(guān)閉請(qǐng)求時(shí)，還可能在向客戶端發(fā)送著數(shù)據(jù)，因此不能再回應(yīng)關(guān)閉鏈接的請(qǐng)求時(shí)，同時(shí)發(fā)送關(guān)閉鏈接的請(qǐng)求

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

對(duì)稱加密，加密的加密和解密使用同一密鑰。

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

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

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

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

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

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

雙向認(rèn)證了解么？

上面的HTTPS的通信流程只驗(yàn)證了服務(wù)端的身份，而服務(wù)端沒有驗(yàn)證客戶端的身份，雙向認(rèn)證是服務(wù)端也要確?？蛻舳说纳矸荩蟾帕鞒淌强蛻舳嗽谛ｒ?yàn)完服務(wù)器的證書之后，會(huì)向服務(wù)器發(fā)送自己的公鑰，然后服務(wù)端用公鑰加密產(chǎn)生一個(gè)新的密鑰，傳給客戶端，客戶端再用私鑰解密，以后就用此密鑰進(jìn)行對(duì)稱加密的通信

文末推薦：iOS熱門文集&視頻解析

①　Swift

②　iOS底層技術(shù)

③　iOS逆向防護(hù)

④　iOS面試合集

⑤ 大廠面試題+底層技術(shù)+逆向安防+Swift

喜歡的小伙伴記得點(diǎn)贊喔~

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

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

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

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