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