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