7月,iOS求職跳槽的相對較少,能在這個時間段求職的,不是被迫,就是對本身的技術很自信;
針對7月,特別總結了第二份iOS常見大廠面試題(中);iosiOS面試題分爲 上、中、下三部分,方便你們觀看;git
請先本身
答一答
!github
話很少說;直接上題
本文收錄:公衆號【iOS進階寶典《iOS底層面試題(中篇)》】面試
在計算機科學中,內省是指計算機程序在運行時(Run time)檢查對象(Object)類型的一種能力,一般也能夠稱做運行時類型檢查。 不該該將內省和反射混淆。相對於內省,反射更進一步,是指計算機程序在運行時(Run time)能夠訪問、檢測和修改它自己狀態或行爲的一種能力。算法
isMemberOfClass
//對象是不是某個類型的對象isKindOfClass
//對象是不是某個類型或某個類型子類的對象isSubclassOfClass
//某個類對象是不是另外一個類型的子類isAncestorOfObject
//某個類對象是不是另外一個類型的父類respondsToSelector
//是否能響應某個方法conformsToProtocol
//是否遵循某個協議安全
class
方法分類方法和對象方法。
- 實例
class
方法就直接返回object_getClass(self)
- 類
class
方法直接返回self
object_getClass()
獲取的是類型,對象.isa —>類.isa —>元類.isa —> 父元類.isa —> 根元類.isa —> 本身(仍是根元類)
- 1:分類主要用來爲某個類添加方法,屬性,協議(我通常用來爲系統的類擴展方法或者把某個複雜的類的按照功能拆到不一樣的文件裏)
- 2:擴展主要用來爲某個類原來沒有的成員變量、屬性、方法。注:方法只是聲明(我通常用擴展來聲明私有屬性,或者把.h的只讀屬性重寫成可讀寫的)
分類和擴展的區別:服務器
分類是在運行時把分類信息合併到類信息中,而擴展是在編譯時,就把信息合併到類中的網絡
分類聲明的屬性,只會生成對應的成員變量,不會有
getter/setter
方法的聲明和實現,而擴展會有。併發分類不可用爲類添加實例變量,而擴展能夠
分類能夠爲類添加方法的實現,而擴展只能聲明方法,而不能實現app
分類的侷限性:
沒法爲類添加實例變量,但可經過關聯對象進行實現,注:關聯對象中內存管理沒有weak,用時須要注意野指針的問題,可經過其餘辦法來實現,具體可參考iOS weak 關鍵字漫談
分類的方法若和類中本來的實現重名,會覆蓋本來方法的實現,注:並非真正的覆蓋多個分類的方法重名,會調用最後編譯的那個分類的實現
分類的結構體裏有哪些成員
struct category_t { const char *name; //名字 cla***ef_t cls; //類的引用 struct method_list_t *instanceMethods;//實例方法列表 struct method_list_t *classMethods;//類方法列表 struct protocol_list_t *protocols;//協議列表 struct property_list_t *instanceProperties;//實例屬性列表 // 此屬性不必定真正的存在 struct property_list_t *_classProperties;//類屬性列表 };
Dealloc 的實現機制是內容管理部分的重點,把這個知識點弄明白,對於全方位的理解內存管理的只是頗有 必要。
1.Dealloc 調用流程
- 1.首先調用
_objc_rootDealloc()
- 2.接下來調用
rootDealloc()
- 3.這時候會判斷是否能夠被釋放,判斷的依據主要有 5 個,判斷是否有以上五種狀況
NONPointer_ISA
weakly_reference
has_assoc
has_cxx_dtor
has_sidetable_rc
- 4-1.若是有以上五中任意一種,將會調用
object_dispose()
方法,作下一步的處理。- 4-2.若是沒有以前五種狀況的任意一種,則能夠執行釋放操做,
C 函數的 free()
。- 5.執行完畢。
2.object_dispose() 調用流程。
- 直接調用
objc_destructInstance()
。- 以後調用 C 函數的 free()。
3.objc_destructInstance()
調用流程
- 先判斷
hasCxxDtor
,若是有 C++ 的相關內容,要調用object_cxxDestruct()
,銷燬 C++ 相關的內容。- 再判斷
hasAssocitatedObjects
,若是有的話,要調用object_remove_associations()
, 銷燬關聯對象的一系列操做。- 而後調用
clearDeallocating()
。- 執行完畢。
4.clearDeallocating()
調用流程。
- 先執行
sideTable_clearDellocating()
。- 再執行
weak_clear_no_lock
,在這一步驟中,會將指向該對象的弱引用指針置爲nil
。- 接下來執行
table.refcnts.eraser()
,從引用計數表中擦除該對象的引用計數。- 至此爲止,
Dealloc
的執行流程結束。
HTTPS協議 = HTTP協議 + SSL/TLS協議
SSL
的全稱是Secure Sockets Layer
,即安全套接層協議,是爲網絡通訊提供安全及數據完整性的一種安全協議。- TLS的全稱是
Transport Layer Security
,即安全傳輸層協議。
即HTTPS是安全的HTTP。
https
, 全稱Hyper Text Transfer Protocol Secure
,相比http
,多了一個secure
,這一個secure
是怎麼來的呢?
這是由TLS(SSL)
提供的!大概就是一個叫openSSL
的library
提供的。https
和http
都屬於application layer
,基於TCP(以及UDP)協議,可是又徹底不同。
TCP用的port是80, https用的是443
(值得一提的是,google發明了一個新的協議,叫QUIC,並不基於TCP,用的port也是443, 一樣是用來給https的。谷歌好牛逼啊。)
整體來講,https和http相似,可是比http安全。
三次握手:
- 客戶端向服務端發起請求連接,首先發送
SYN
報文,SYN=1,seq=x
,而且客戶端進入SYN_SENT
狀態- 服務端收到請求連接,服務端向客戶端進行回覆,併發送響應報文,
SYN=1,seq=y,ACK=1,ack=x+1
,而且服務端進入到SYN_RCVD
狀態- 客戶端收到確認報文後,向服務端發送確認報文,
ACK=1,ack=y+1
,此時客戶端進入到ESTABLISHED
,服務端收到用戶端發送過來的確認報文後,也進入到ESTABLISHED
狀態,此時連接建立成功
四次揮手:
- 客戶端向服務端發起關閉連接,並中止發送數據
- 服務端收到關閉連接的請求時,向客戶端發送迴應,我知道了,而後中止接收數據
- 當服務端發送數據結束以後,向客戶端發起關閉連接,並中止發送數據
- 客戶端收到關閉連接的請求時,向服務端發送迴應,我知道了,而後中止接收數據
爲何須要三次握手:
爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端,於是產生錯誤,假設這是一個早已失效的報文段。
但server
收到此失效的鏈接請求報文段後,就誤認爲是client
再次發出的一個新的鏈接請求。
因而就向client
發出確認報文段,贊成創建鏈接。
假設不採用「三次握手」,那麼只要server發出確認,新的鏈接就創建了。
因爲如今client
並無發出創建鏈接的請求,所以不會理睬server
的確認,也不會向server
發送數據。
但server
卻覺得新的運輸鏈接已經創建,並一直等待client
發來數據。
這樣,server
的不少資源就白白浪費掉了。
爲何須要四次揮手:
由於TCP是全雙工通訊的,在接收到客戶端的關閉請求時,還可能在向客戶端發送着數據,所以不能再回應關閉連接的請求時,同時發送關閉連接的請求
對稱加密,加密的加密和解密使用同一密鑰。
- 非對稱加密,使用一對密鑰用於加密和解密,分別爲公開密鑰和私有密鑰。公開密鑰全部人均可以得到,通訊發送方得到接收方的公開密鑰以後,就可使用公開密鑰進行加密,接收方收到通訊內容後使用私有密鑰解密。
- 對稱加密經常使用的算法實現有AES,ChaCha20,DES,不過DES被認爲是不安全的;非對稱加密用的算法實現有RSA,ECC
HTTPS的握手流程,以下圖,摘自圖解HTTP
- 客戶端發送Client Hello 報文開始SSL通訊。報文中包含客戶端支持的SSL的版本,加密組件列表。
- 服務器收到以後,會以Server Hello 報文做爲應答。和客戶端同樣,報文中包含客戶端支持的SSL的版本,加密組件列表。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的
- 服務器發送Certificate報文。報文中包含公開密鑰證書。
- 而後服務器發送Server Hello Done報文通知客戶端,最初階段的SSL握手協商部分結束
- SSL第一次握手結束以後,客戶端以Client Key Exchange報文做爲會議。報文中包含通訊加密中使用的一種被稱爲Pre-master secret的隨機密碼串
- 接着客戶端發送Change Cipher Space報文。該報文會提示服務器,在次報文以後的通訊會採用Pre-master secret密鑰加密
- 客戶端發送Finished 報文。該報文包含連接至今所有報文的總體校驗值。此次握手協商是否可以成功,要以服務器是否可以正確揭祕該報文做爲斷定標準
- 服務器一樣發送Change Cipher Space報文。
- 服務器一樣發送Finished報文。
- 服務器和客戶端的Finished報文交換完畢以後,SSL鏈接創建完成,今後開始HTTP通訊,通訊的內容都使用Pre-master secret加密。而後開始發送HTTP請求
- 應用層收到HTTP請求以後,發送HTTP響應
- 最後有客戶端斷開鏈接
爲何密鑰的傳遞須要使用非對稱加密?
使用非對稱加密是爲了後面客戶端生成的Pre-master secret
密鑰的安全,經過上面的步驟能得知,服務器向客戶端發送公鑰證書這一步是有可能被別人攔截的,若是使用對稱加密的話,在客戶端向服務端發送Pre-master secret
密鑰的時候,被***攔截的話,就可以使用公鑰進行解碼,就沒法保證Pre-master secret
密鑰的安全了
雙向認證瞭解麼?
上面的HTTPS的通訊流程只驗證了服務端的身份,而服務端沒有驗證客戶端的身份,雙向認證是服務端也要確保客戶端的身份,大概流程是客戶端在校驗完服務器的證書以後,會向服務器發送本身的公鑰,而後服務端用公鑰加密產生一個新的密鑰,傳給客戶端,客戶端再用私鑰解密,之後就用此密鑰進行對稱加密的通訊
文末推薦:iOS熱門文集&視頻解析