1. 寫在前面這份題目為什么值得認(rèn)真對待先說結(jié)論歡聚時代2018年校招iOS A卷放在今天來看依然是一份“含金量不低”的基礎(chǔ)題。它不考花哨的Swift語法糖不考新框架API背誦而是把重點壓在iOS開發(fā)最核心的幾塊地基上——內(nèi)存管理、多線程、RunLoop、Runtime、UI布局、網(wǎng)絡(luò)層。這些東西恰恰是很多工作了兩三年的人依然說不透的內(nèi)容。如果你正在準(zhǔn)備iOS校招或者社招這份題目適合拿來當(dāng)自測清單哪些題能脫口而出哪些題需要想一下哪些題完全沒概念這就是你當(dāng)前水平的真實剖面。我當(dāng)年刷完這份卷子后的感受是學(xué)校教的那點東西和實際面試要的東西之間隔著一個“系統(tǒng)性整理”的距離。這篇文章我會按照“原題涉及哪些知識點→每類知識點的核心原理→我的答題思路和踩坑經(jīng)驗”這個邏輯來展開不貼原題原話畢竟涉及版權(quán)而是把題目背后考的每一個知識點拆開揉碎讓你看完之后就算遇到變體題也能應(yīng)對。2. 內(nèi)存管理ARC時代為什么還要問MRC2.1 從一道“引用計數(shù)”題說開去A卷里內(nèi)存管理的題目不少核心圍繞引用計數(shù)、循環(huán)引用、weak和strong的區(qū)別、block對變量的捕獲這幾塊。先說引用計數(shù)。很多新手會覺得“現(xiàn)在都ARC了誰還管retain和release”但面試官問這個不是為了讓你手寫release而是為了確認(rèn)你是否真正理解對象的生命周期。引用計數(shù)的本質(zhì)是一個整數(shù)每個OC對象內(nèi)部都有一個retainCount當(dāng)它為0時對象被釋放。ARC做的事情就是在編譯期幫你插入retain和release調(diào)用它不是一個運(yùn)行時機(jī)制而是一個編譯期機(jī)制。這一點很多解釋都講錯了我在面試中反復(fù)被問到過所以單獨拿出來強(qiáng)調(diào)。你要能說清楚strong對應(yīng)retainweak對應(yīng)assign但會在對象釋放時自動置nilcopy對應(yīng)retain加一次拷貝。在實際開發(fā)中weak最常見的應(yīng)用場景就是delegate屬性和block內(nèi)部對self的弱引用前者是為了避免兩個對象互相持有后者是為了打破block對self的強(qiáng)引用閉環(huán)。2.2 循環(huán)引用最常見的線上崩潰來源循環(huán)引用幾乎是必考題。我給你一個標(biāo)準(zhǔn)的例子一個ViewController持有block屬性block內(nèi)部又使用了self。如果self對block是strongblock對self也是strong那兩者就互相引用誰也釋放不掉dealloc永遠(yuǎn)不會調(diào)用內(nèi)存泄漏就產(chǎn)生了。解決辦法三個思路第一種block內(nèi)部用__weak修飾的self弱引用最常見也最推薦第二種在block執(zhí)行完成后把block屬性置nil強(qiáng)行打破閉環(huán)第三種如果block不需要長時間持有self可以考慮用__block修飾并在block內(nèi)部置nil但這種方式在ARC下要小心因為__block對象的處理規(guī)則在不同版本里有變化。我踩過的一個坑是在block里調(diào)用了self的getter方法比如self.name然后編譯器提示“Block implicitly retains self”。這說明即使用了weakSelf只要你在block里訪問了self的某個屬性編譯器也會生成強(qiáng)引用。正確做法是在block外先定義__weak typeof(self) weakSelf self;然后在block內(nèi)再定義一個__strong typeof(weakSelf) strongSelf weakSelf;用strongSelf來操作屬性。這個“weak-strong dance”在SDK開發(fā)、網(wǎng)絡(luò)回調(diào)里極其常見面試時能主動寫出來是加分項。2.3 內(nèi)存警告與ViewDidUnload2018年的題目里還有關(guān)于內(nèi)存警告處理的題。對UIViewController來說系統(tǒng)在內(nèi)存吃緊時會調(diào)用didReceiveMemoryWarning而對應(yīng)的viewDidUnload在iOS 6之后就被廢棄了不再調(diào)用。原因是系統(tǒng)不再默認(rèn)釋放self.view而是讓開發(fā)者自己重寫didReceiveMemoryWarning來釋放可重建的資源比如圖片緩存、大數(shù)組、動畫等。很多老項目還留著viewDidUnload的代碼在新系統(tǒng)上根本不會執(zhí)行這就造成了一個假象開發(fā)者以為自己做了內(nèi)存釋放實際上什么都沒發(fā)生。面試?yán)锾岬竭@一點能體現(xiàn)你對系統(tǒng)版本差異的敏感度。3. 多線程與RunLoopiOS流暢度的底牌3.1 GCD的隊列與死鎖A卷里多線程的題目占了相當(dāng)比重尤其是GCD。GCD的核心概念就兩樣隊列和任務(wù)。隊列分串行隊列和并發(fā)隊列任務(wù)分同步任務(wù)和異步任務(wù)。排列組合一下就有四種情況但這四種情況的執(zhí)行時機(jī)和行為各不相同面試題經(jīng)常從這里出。這里最經(jīng)典的陷阱題就是“在主隊列調(diào)用sync任務(wù)會發(fā)生什么”。答案是死鎖。主隊列是串行隊列主線程上的任務(wù)必須一個接一個執(zhí)行當(dāng)你用dispatch_sync(dispatch_get_main_queue(), ^{})時相當(dāng)于在主線程正在執(zhí)行的任務(wù)中插入了一個“必須等這個block執(zhí)行完才繼續(xù)”的等待而主隊列的機(jī)制決定這個block要等當(dāng)前任務(wù)執(zhí)行完才開始于是互相等待死鎖就產(chǎn)生了。另一個高頻考點是信號量dispatch_semaphore_t。它用來控制并發(fā)數(shù)的上限比如同時最多允許三個網(wǎng)絡(luò)請求運(yùn)行。這個在實際開發(fā)中很有用比如批量上傳圖片時限制并發(fā)數(shù)防止內(nèi)存暴漲。3.2 RunLoop與界面卡頓的關(guān)聯(lián)RunLoop這塊面試官特別喜歡從“為什么滑動TableView的時候NSTimer不走了”這個問題切入。原因是RunLoop在滑動模式下會切換到UITrackingRunLoopMode而默認(rèn)添加的Timer跑在NSDefaultRunLoopMode下滑動時默認(rèn)模式下的任務(wù)不執(zhí)行Timer自然就不觸發(fā)。解決方案就是把Timer加到NSRunLoopCommonModes下這樣Timer在Default和Tracking兩種模式下都能跑。使用[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes]即可。更深一層RunLoop的source0、source1、timer三種事件源也是面試考點。source0是應(yīng)用內(nèi)部事件比如觸摸事件source1是系統(tǒng)內(nèi)核事件比如端口消息timer就是定時器。理解這些對排查界面卡頓很有幫助因為卡頓的本質(zhì)就是主線程RunLoop無法及時處理事件perf工具抓到的通常就是主線程執(zhí)行耗時操作時的堆棧。3.3 NSOperation與GCD的選擇NSOperationQueue和GCD的區(qū)別也是個老生常談的問題。我總結(jié)了一張對比表面試時可以直接用維度GCDNSOperationQueue底層C語言API輕量高效基于GCD封裝OC對象取消任務(wù)不支持需自己寫標(biāo)志位原生支持cancel依賴關(guān)系需用dispatch_barrier或信號量模擬原生支持addDependency最大并發(fā)數(shù)信號量控制maxConcurrentOperationCount直接設(shè)置操作狀態(tài)監(jiān)聽需手動管理KVO監(jiān)聽isFinished等結(jié)論就是簡單一次性任務(wù)用GCD足夠復(fù)雜任務(wù)編排、需要取消和依賴時用NSOperationQueue更合適。面試時把你的選擇邏輯講清楚面試官會覺得你是“帶著方案思考”而不是“背概念”。4. Runtime與消息機(jī)制OC動態(tài)性的內(nèi)核4.1 objc_msgSend的調(diào)用鏈Runtime幾乎是每年必考2018年的A卷也不例外。核心考點就是objc_msgSend的執(zhí)行流程消息發(fā)送時系統(tǒng)會沿著對象的isa找到其類對象在類對象的method list里查找方法找不到就去父類找最終到了NSObject還沒有就進(jìn)入消息轉(zhuǎn)發(fā)流程。消息轉(zhuǎn)發(fā)有三道防線動態(tài)方法解析resolveInstanceMethod、快速轉(zhuǎn)發(fā)forwardingTargetForSelector、完整轉(zhuǎn)發(fā)methodSignatureForSelector forwardInvocation。面試官問你“一個OC對象調(diào)用了一個不存在的方法會發(fā)生什么”你就應(yīng)該把這個完整鏈路背出來。能答到forwardInvocation這一步就已經(jīng)不錯了。4.2 Method Swizzling的作用與風(fēng)險Method Swizzling也是高頻考點考察點在于“你會不會用”以及“你知道不知道它的風(fēng)險”。它利用Runtime在運(yùn)行時交換兩個方法的IMP常用于AOP場景比如統(tǒng)計頁面曝光、日志上傳、埋點。常見的坑有三個第一交換方法應(yīng)該在load中執(zhí)行不要在initialize里反復(fù)執(zhí)行第二交換時要注意被交換方法所在類的繼承關(guān)系父類子類都要處理第三交換后不能調(diào)原方法的IMP否則會遞歸調(diào)用導(dǎo)致死循環(huán)。我自己就遇到過第三方SDK用Swizzling改變了UIViewController的viewWillAppear行為導(dǎo)致我們自己的統(tǒng)計代碼重復(fù)上報的問題排查了很久才定位到是交換順序沖突。4.3 KVC與KVO的實現(xiàn)原理KVC鍵值編碼和KVO鍵值觀察在2018年的題目中也有涉及。KVC的原理是當(dāng)你調(diào)用setValue:forKey:時系統(tǒng)會先去查找setter方法setXxx找不到就用_xxx或xxx成員變量再找不到就調(diào)用setValue:forUndefinedKey:如果這個也沒有實現(xiàn)就拋異常。KVO的實現(xiàn)原理更有意思當(dāng)你對一個對象添加觀察者時Runtime會動態(tài)生成一個子類NSKVONotifying_xxx重寫被觀察屬性的setter方法在setter里同時調(diào)用willChangeValueForKey和didChangeValueForKey然后通知觀察者。所以KVO只對KVC兼容的屬性生效直接對成員變量賦值不會觸發(fā)通知。5. UI與布局從Auto Layout到UITableView5.1 Auto Layout的優(yōu)先級與固有內(nèi)容大小A卷里有關(guān)UI布局的題主要集中在Auto Layout上。高頻考點一個是intrinsicContentSize固有內(nèi)容大小比如UILabel根據(jù)文字內(nèi)容、字體大小能計算自己需要的尺寸UIButton則會根據(jù)圖片和標(biāo)題計算。理解了這一點你就知道為什么有時候約束明明寫得很全UILabel還是撐不開或壓縮重疊。另一個高頻考點是約束的優(yōu)先級required和optional。required優(yōu)先級的約束必須全部滿足optional約束可以沖突時自動放棄。這個在實際適配不同屏幕尺寸時很有用比如讓按鈕在“滿足寬度約束的前提下盡量貼右”就可以把貼右約束設(shè)為optional。如果只是盲目把約束寫滿在小屏設(shè)備上就會出現(xiàn)約束沖突警告布局錯亂。5.2 UITableView的復(fù)用機(jī)制與卡頓優(yōu)化Cell復(fù)用是必考題但A卷考得更深一點不僅問“為什么復(fù)用”還問“怎么保證數(shù)據(jù)的正確性”。復(fù)用機(jī)制高效是因為避免了頻繁創(chuàng)建和銷毀UIView的昂貴開銷。但復(fù)用的坑在于當(dāng)你快速滑動時一個顯示“已關(guān)注”狀態(tài)的Cell滾出屏幕后又被復(fù)用到顯示“未關(guān)注”的Cell上就會出現(xiàn)狀態(tài)錯亂。標(biāo)準(zhǔn)解法是在cellForRowAtIndexPath里把所有的狀態(tài)按鈕文案、圖片、選中狀態(tài)全部重新賦值不能依賴Cell之前的殘留狀態(tài)。另外iOS 5之后通過注冊類和dequeueReusableCellWithIdentifier:forIndexPath:方式獲取Cell時系統(tǒng)會自動創(chuàng)建并走初始化無需判空。關(guān)于卡頓優(yōu)化核心是減少主線程的工作量Cell高度提前計算并緩存、圖片異步加載、避免在drawRect里做復(fù)雜操作、把離屏渲染降到最低。A卷如果問“TableView滑動卡頓從哪些方面優(yōu)化”這是一套完整的答法。5.3 iOS 11的Safe Area與適配2018年正好是iPhone X發(fā)布后的時間點A卷里出現(xiàn)了關(guān)于Safe Area的題目。iOS 11引入了SafeAreaLayoutGuide取代了之前的topLayoutGuide和bottomLayoutGuide。如果你的項目用Masonry這類框架要注意把約束綁定到safeArea上否則會出現(xiàn)劉海屏下布局被狀態(tài)欄和底部橫條遮擋的問題。一個比較實用的經(jīng)驗是在viewDidLayoutSubviews里通過self.view.safeAreaInsets獲取安全區(qū)域的值做額外的適配邏輯比如判斷底部橫條高度來決定按鈕的偏移量。這個值在viewDidLoad里拿不到要在viewDidAppear或viewDidLayoutSubviews里才有。6. 網(wǎng)絡(luò)層從GET/POST到HTTPS與緩存策略6.1 HTTP協(xié)議基礎(chǔ)與報文結(jié)構(gòu)A卷的網(wǎng)絡(luò)題不會讓你貼一大段代碼而是問原理性的內(nèi)容。HTTP請求的本質(zhì)是TCP連接上傳輸文本格式的報文報文由請求行、請求頭、空行、請求體四部分組成。GET和POST的區(qū)別不只在語義上更實際的差異是GET參數(shù)拼在URL后面有長度限制POST參數(shù)放在body里容量大得多GET是冪等的POST不是冪等的。面試官經(jīng)常會追問“POST能不能用URL傳參”答案是“能”URL上可以拼任意參數(shù)服務(wù)端也未必拒絕但這不符合規(guī)范。我傾向于回答“可以但不建議”然后把原因講清楚URL會出現(xiàn)在日志里敏感信息會泄漏URL有長度限制緩存和收藏夾會把參數(shù)帶走。6.2 HTTPS握手過程與Charles抓包HTTPS的題目這些年越來越常見。核心是握手的簡化流程客戶端先發(fā)ClientHello帶支持的加密套件列表服務(wù)端回ServerHello并附上證書客戶端驗證證書后生成預(yù)主密鑰用服務(wù)端公鑰加密發(fā)給服務(wù)端雙方各自算出會話密鑰之后用對稱加密通信。理解這個過程對日常開發(fā)的幫助很大。比如你Charles抓包的時候SSL Proxying的原理就是Charles偽造了一個證書負(fù)責(zé)解密然后用你自己的證書和服務(wù)端通信負(fù)責(zé)加密相當(dāng)于中間人的角色。所以在抓包時iOS端必須安裝并信任Charles的根證書否則客戶端會驗證證書失敗請求直接報錯。我自己在這個環(huán)節(jié)踩過一個大坑App里用了證書鎖定SSL Pinning也就是客戶端內(nèi)嵌了服務(wù)端的公鑰或證書指紋此時Charles即使裝了證書也解不了包因為客戶端校驗的是自己內(nèi)置的那個證書。解決辦法是debug模式下開放一個開關(guān)關(guān)閉證書校驗或者在內(nèi)置證書集合里臨時加入Charles的證書。6.3 網(wǎng)絡(luò)緩存策略與斷點續(xù)傳緩存策略也是?？键cNSURLRequest的緩存策略有幾種useProtocolCachePolicy默認(rèn)、reloadIgnoringLocalCacheData忽略緩存、returnCacheDataElseLoad先用緩存沒有就請求、returnCacheDataDontLoad只看緩存沒有就失敗。實際開發(fā)中我更習(xí)慣配合ETag和Last-Modified做服務(wù)端驗證的緩存每次請求帶上If-None-Match如果服務(wù)端資源沒變就返回304客戶端直接使用本地緩存。這樣既保證內(nèi)容新鮮又節(jié)約流量和帶寬。斷點續(xù)傳涉及HTTP的Range頭格式是Range: bytes0-1023服務(wù)端支持就會返回206狀態(tài)碼和對應(yīng)分片數(shù)據(jù)。面試中如果能把這個細(xì)節(jié)答出來說明你真的做過下載功能。7. 常見陷阱與備考建議7.1 三張“問題速查表”我把這整套知識點整理成幾個速查表方便你在面試前快速過一遍內(nèi)存管理常見問題問題原因解決方案Block內(nèi)使用self導(dǎo)致循環(huán)引用雙方強(qiáng)引用互相持使用weakSelfstrongSelf定時器不釋放NSTimer被RunLoop持有invalidate并置nil大圖片內(nèi)存暴漲解碼后的位圖占內(nèi)存使用downsample或縮略圖集合類持有大對象內(nèi)存峰值過高使用autoreleasepool局部釋放多線程常見陷阱問題原因解決方案主隊列sync死鎖串行隊列互相等待改用async或子隊列生產(chǎn)者消費者阻塞信號量使用不當(dāng)注意wait/signal配對線程安全數(shù)據(jù)競爭多線程同時寫可變數(shù)據(jù)加鎖或用串行隊列保護(hù)資源回收崩潰信號量或鎖在dealloc中釋放確保所有路徑都釋放UI布局常見異常問題原因解決方案約束沖突警告優(yōu)先級設(shè)置不當(dāng)調(diào)整約束priorityLabel內(nèi)容截斷固有大小計算失效設(shè)置preferredMaxLayoutWidthSafeArea遮擋未適配安全區(qū)域綁定safeAreaLayoutGuideCell狀態(tài)錯亂復(fù)用導(dǎo)致舊狀態(tài)殘留每次都重新賦值7.2 備考心得用“設(shè)計題”的方式學(xué)“概念題”2018年的A卷給我最大的啟發(fā)是它考的不是API的“怎么用”而是API的“為什么”。單純背結(jié)論應(yīng)付不了追問必須真正理解底層原理才能面對變化多端的題目形式。一個建議是面對每個知識點都問自己三個“為什么”。為什么ARC能自動釋放對象因為編譯器插入了release調(diào)用。為什么block會捕獲局部變量因為block本質(zhì)上是一個結(jié)構(gòu)體需要把變量值拷貝到結(jié)構(gòu)體內(nèi)部。為什么UILabel有固有大小因為它能根據(jù)內(nèi)容計算需要的尺寸。當(dāng)你把這三個為什么都能順理成章地回答出來概念題基本就穩(wěn)了。另外我強(qiáng)烈建議用“設(shè)計題”的方式來檢驗自己比如“讓你設(shè)計一個圖片加載框架你會怎么設(shè)計”你會自然想到內(nèi)存緩存、磁盤緩存、異步下載、解碼優(yōu)化、取消機(jī)制、優(yōu)先級調(diào)度而這些恰好覆蓋了A卷里網(wǎng)絡(luò)、多線程、內(nèi)存管理三大主題。通過一道設(shè)計題把所有知識點串起來比一題一題刷效果要好得多。7.3 一個過來人的真心建議最后分享一個小經(jīng)驗。我記得當(dāng)年做這套題的時候最讓我難受的不是不會而是有些題“好像見過但說不清楚”。這種感覺比完全不會還要惱火。后來我意識到原因在于學(xué)習(xí)太碎片化今天看一篇博客講RunLoop明天看一段視頻講Runtime知識沒有形成體系到用的時候自然調(diào)不出來。所以我給你的建議是花一點時間把iOS的知識體系畫成一張大圖分成系統(tǒng)架構(gòu)、語言特性、UI布局、網(wǎng)絡(luò)、存儲、多線程、性能優(yōu)化這幾塊每一塊再往下細(xì)分把自己會的內(nèi)容標(biāo)綠不會的標(biāo)紅然后用紅色部分反推復(fù)習(xí)計劃。這個過程很痛苦但堅持兩周以后你面對面試題的心態(tài)會完全不同——你不會再有“考到不會的就完了”的恐慌因為你知道這個紅色區(qū)域在哪個分支下你大概知道去哪里查、往哪個方向想。這份把控感比任何“面經(jīng)”都值錢。