1. 整體出題思路與考察重點(diǎn)解析1.1 這套題到底在考什么每年的秋招筆試都是千軍萬馬過獨(dú)木橋愛奇藝這套iOS方向的筆試題A卷屬于典型的“基礎(chǔ)功篩查型”試卷。我翻過不少大廠的iOS筆試愛奇藝這套題的特點(diǎn)是不考偏題怪題但覆蓋面極廣從語言特性到運(yùn)行時(shí)機(jī)制從內(nèi)存管理到UI事件傳遞幾乎是把你大學(xué)三年加實(shí)習(xí)一年積累的知識(shí)底子整個(gè)翻出來曬一遍。很多同學(xué)拿到試卷第一反應(yīng)是“這些知識(shí)點(diǎn)我都見過”但真正下筆的時(shí)候才發(fā)現(xiàn)自己只是“知道”而不是“理解”。比如KVO鍵值觀察怎么用大多數(shù)人能說出來但問到“KVO的底層實(shí)現(xiàn)是什么”“手動(dòng)觸發(fā)KVO怎么做”“嵌套Context有什么坑”就卡住了。這套題的狠勁就在這兒它不問你API怎么調(diào)它問你API背后發(fā)生了什么。整套題從能力考察維度來看可以分成四個(gè)層次第一層是語言基礎(chǔ)考察OCObjective-C的核心特性有沒有吃透第二層是運(yùn)行時(shí)與內(nèi)存管理考察對(duì)底層的理解深度第三層是UI與事件處理考察日常開發(fā)中會(huì)不會(huì)踩坑第四層是多線程與系統(tǒng)框架考察工程落地能力。從“愛奇藝2019秋招iOS方向筆試題A”這個(gè)標(biāo)題就能看出這是秋招的第一輪篩選出題人的邏輯很清楚——基礎(chǔ)知識(shí)不牢固的人后面項(xiàng)目經(jīng)驗(yàn)聊得再嗨也是白搭。1.2 刷題之外更要建立知識(shí)網(wǎng)絡(luò)我見過太多同學(xué)刷題的方式是背答案這道題選A那道題選C記住了就往下走。這套方法應(yīng)付一般的學(xué)?？荚囈苍S有用但面對(duì)愛奇藝這種大廠筆試幾乎必翻車。因?yàn)榇髲S筆試題有個(gè)特點(diǎn)它經(jīng)常會(huì)換一個(gè)角度考察同一個(gè)知識(shí)點(diǎn)或者把兩個(gè)知識(shí)點(diǎn)揉在一起考。你背的是答案它考的是邏輯對(duì)不上自然就懵了。所以正確的備考方式應(yīng)該是每做一道題不要只停留在“選什么”而是把這個(gè)知識(shí)點(diǎn)相關(guān)的上下游全部梳理一遍。比如考到KVO你就應(yīng)該順著把KVO的原理、應(yīng)用場(chǎng)景、常見坑點(diǎn)、與Notification的區(qū)別全部過一遍考到Block就要把Block的類型、循環(huán)引用、__block修飾符、Block的存儲(chǔ)位置全部串聯(lián)起來。這樣做一道題等于復(fù)習(xí)了一整個(gè)知識(shí)模塊效率比盲目刷題高得多。我在實(shí)際帶新人的時(shí)候發(fā)現(xiàn)很多應(yīng)屆生對(duì)知識(shí)點(diǎn)的掌握是“點(diǎn)狀”的東一個(gè)西一個(gè)連不成線。這樣面試官一深挖就露餡。正確的狀態(tài)應(yīng)該是“網(wǎng)狀”的任何一個(gè)知識(shí)點(diǎn)被問到你都能沿著它延伸到相鄰的領(lǐng)域。這套題本身就是一個(gè)很好的知識(shí)網(wǎng)絡(luò)索引順著它梳理下去基本能把iOS面試的高頻考點(diǎn)覆蓋個(gè)大半。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 語言基礎(chǔ)類考點(diǎn)與解題思路OC語言特性是這套題的重頭戲尤其是那些OC獨(dú)有的、跟Swift差異明顯的機(jī)制。KVO和KVC鍵值編碼基本是必考的而且考法每年都在變。KVO的核心機(jī)制你要能說清楚當(dāng)你對(duì)一個(gè)對(duì)象添加觀察者時(shí)Runtime會(huì)動(dòng)態(tài)創(chuàng)建一個(gè)該類的子類重寫被觀察屬性的setter方法在setter里調(diào)用willChangeValueForKey和didChangeValueForKey從而把變化通知給觀察者。這個(gè)動(dòng)態(tài)子類的過程很多人只是聽過名字但不知道細(xì)節(jié)面試官一問“子類叫什么名字isa指針怎么變化的”就容易卡住。KVC的考察點(diǎn)則集中在setValue:forKey的查找順序上。你要知道它的完整查找路徑先找setKey方法如果沒有再找_key、_isKey、key、isKey這些實(shí)例變量都找不到才會(huì)調(diào)用setValue:forUndefinedKey。這個(gè)順序我建議每個(gè)準(zhǔn)備面試的人都畫一遍因?yàn)楹芏鄬?shí)戰(zhàn)中的奇怪問題歸根到底都是這個(gè)查找順序引起的。Category與Extension的區(qū)別也是高頻題。一句話總結(jié)Extension在編譯期決定有源碼才能添加添加的方法和屬性是直接加在本類上的Category在運(yùn)行時(shí)合并沒有源碼也能添加但不能直接添加實(shí)例變量可以通過關(guān)聯(lián)對(duì)象實(shí)現(xiàn)。這里有個(gè)隱含考點(diǎn)就是Category的方法覆蓋優(yōu)先級(jí)——多個(gè)Category都實(shí)現(xiàn)了同一個(gè)方法時(shí)最后編譯的那個(gè)會(huì)“生效”但本質(zhì)上不是覆蓋而是方法列表里排在前面被先找到。這個(gè)問題我在真實(shí)項(xiàng)目中就踩過坑兩個(gè)庫的Category都實(shí)現(xiàn)了同名方法結(jié)果調(diào)到的跟預(yù)期的不一樣排查了很久。2.2 內(nèi)存管理與Block內(nèi)存管理在筆試?yán)飵缀鯊牟蝗毕绕涫茿RC自動(dòng)引用計(jì)數(shù)相關(guān)的概念辨析。你需要搞清楚strong、weak、copy、assign這幾個(gè)修飾符的本質(zhì)區(qū)別。strong是強(qiáng)引用引用計(jì)數(shù)加一weak是弱引用不增加引用計(jì)數(shù)對(duì)象釋放后自動(dòng)置為nilcopy會(huì)拷貝一份對(duì)象修飾Block時(shí)會(huì)把棧上的Block拷貝到堆上assign通常用來修飾基本類型如果修飾對(duì)象類型對(duì)象釋放后指針不會(huì)置空繼續(xù)訪問會(huì)野指針崩潰。這套題如果考到這些一般不會(huì)直接問“strong和weak有什么區(qū)別”而是給你一段代碼讓你分析引用計(jì)數(shù)變化和最終打印結(jié)果。這種題考察的是有沒有真正理解ARC的機(jī)制而不是背修飾符的定義。我建議你做題的時(shí)候把每一行代碼涉及的引用計(jì)數(shù)變化都在草稿紙上標(biāo)出來養(yǎng)成這個(gè)習(xí)慣遇到再復(fù)雜的題都不怕。Block的循環(huán)引用問題已經(jīng)是老生常談了但考法也在升級(jí)。最基礎(chǔ)的考法是在一個(gè)ViewController里Block捕獲了self而self又強(qiáng)引用了這個(gè)Block造成循環(huán)引用用__weak typeof(self) weakSelf self解決。進(jìn)階考法是Block里用了weakSelf之后又在異步操作里訪問weakSelf的某個(gè)屬性這時(shí)候weakSelf可能已經(jīng)被釋放了需要在Block開頭用__strong typeof(weakSelf) strongSelf weakSelf保底。這個(gè)“weak之后還要strong”的寫法很多人理解不了為什么其實(shí)是保證Block執(zhí)行期間對(duì)象不會(huì)被提前釋放執(zhí)行完再釋放。2.3 Runtime底層原理Runtime是區(qū)分“會(huì)用iOS”和“懂iOS”的分水嶺。這套題里凡是涉及Runtime的基本都是送分題和送命題并存。送分題是消息傳遞機(jī)制objc_msgSend的查找流程先從緩存里找找不到去類的方法列表里找再找不到去父類找一直找到NSObject都沒有就進(jìn)入消息轉(zhuǎn)發(fā)流程。送命題是消息轉(zhuǎn)發(fā)流程的三道防線動(dòng)態(tài)方法解析resolveInstanceMethod、快速轉(zhuǎn)發(fā)forwardingTargetForSelector、完整轉(zhuǎn)發(fā)methodSignatureForSelector和forwardInvocation。這三道防線很多同學(xué)背不全或者搞不清楚順序。結(jié)合實(shí)際開發(fā)來說動(dòng)態(tài)方法解析常用于dynamic屬性快速轉(zhuǎn)發(fā)常用于代理瘦身完整轉(zhuǎn)發(fā)可以用于AOP面向切面編程或者異常攔截。我在做崩潰治理的時(shí)候就用過完整轉(zhuǎn)發(fā)把一些unrecognized selector的崩潰轉(zhuǎn)成自定義的日志上報(bào)雖然不推薦在生產(chǎn)環(huán)境這么做但作為兜底方案確實(shí)能減少一些線上崩潰。關(guān)聯(lián)對(duì)象AssociatedObject也是Runtime的?？汀Ｋ牡讓咏Y(jié)構(gòu)是AssociationsManager維護(hù)的一張全局哈希表以對(duì)象地址為key關(guān)聯(lián)字典為value。用的時(shí)候要注意關(guān)聯(lián)對(duì)象不會(huì)因?yàn)閷?duì)象dealloc自動(dòng)清理需要在dealloc里手動(dòng)移除不然會(huì)有內(nèi)存泄漏的風(fēng)險(xiǎn)。另一個(gè)坑是關(guān)聯(lián)對(duì)象不參與對(duì)象的釋放過程所以用weak策略關(guān)聯(lián)時(shí)對(duì)象釋放后關(guān)聯(lián)值也會(huì)變成空這點(diǎn)跟實(shí)例變量的行為不太一樣。3. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 UI事件傳遞與響應(yīng)鏈UI部分考察頻率最高的應(yīng)該就是事件傳遞和響應(yīng)鏈了。這套題如果出一個(gè)場(chǎng)景題一個(gè)Button嵌套在View里View嵌套在ViewController的View上點(diǎn)擊Button事件是怎么傳遞和響應(yīng)的很多同學(xué)能答出前半段——hitTest和pointInside的遞歸調(diào)用事件從UIApplication傳給UIWindow再傳給根視圖一層層找最適合的響應(yīng)者。但后半段容易漏——找到最適合的響應(yīng)者之后事件沿著響應(yīng)鏈從Button傳到父View再傳ViewController的View再傳到ViewController一直到UIApplication如果每一層的nextResponder都沒處理事件就丟棄了。真實(shí)開發(fā)中跟響應(yīng)鏈相關(guān)的坑也很多。比如Button的點(diǎn)擊區(qū)域太小你加了一個(gè)父View的點(diǎn)擊手勢(shì)來擴(kuò)大響應(yīng)區(qū)域結(jié)果Button的點(diǎn)擊就失效了。原理是手勢(shì)識(shí)別器比正常的觸摸事件響應(yīng)優(yōu)先父View的手勢(shì)識(shí)別器把觸摸事件攔截了Button根本收不到touch事件。解決方法是實(shí)現(xiàn)手勢(shì)識(shí)別器的delegate方法判斷觸摸點(diǎn)是否在Button范圍內(nèi)返回NO讓事件繼續(xù)傳給Button。TableView的優(yōu)化也是筆試和面試的高頻題?；A(chǔ)答法是復(fù)用cell、高度緩存、避免在cellForRowAtIndexPath里做耗時(shí)操作、異步加載圖片。深一層答法是預(yù)排版、預(yù)渲染、按需加載、避免離屏渲染。再深一層就是diff算法、異步繪制、滑動(dòng)幀率監(jiān)控。這套題如果考到TableView優(yōu)化建議盡量往深處答因?yàn)槌鲱}人想看到的不是你會(huì)不會(huì)用UITableView而是你有沒有做過大列表的性能治理。愛奇藝這種視頻App信息流列表的流暢度直接影響用戶體驗(yàn)所以這塊幾乎是必考的。3.2 不同iOS系統(tǒng)版本適配策略視頻類App的系統(tǒng)適配是一個(gè)繞不開的工程問題。愛奇藝的題如果涉及系統(tǒng)版本適配考察重點(diǎn)肯定不是“怎么判斷系統(tǒng)版本”而是“你的適配策略是什么”。我的經(jīng)驗(yàn)是比較大的版本迭代比如iOS 11到iOS 12需要做全量回歸小版本更新做定向驗(yàn)證就夠了。但有一點(diǎn)要注意系統(tǒng)版本的兼容性測(cè)試不能只看UI表現(xiàn)還要關(guān)注API行為變化。舉一個(gè)我實(shí)際踩過的例子iOS 13之后Apple改了KVC的取值行為直接通過KVC訪問私有屬性會(huì)觸發(fā)NSGenericException異常原來很多第三方庫用KVC修改UITextField的placeholder顏色等操作一下子全崩了。這類問題不真機(jī)測(cè)到光靠看文檔是發(fā)現(xiàn)不了的。所以適配策略里一定要包含一個(gè)環(huán)節(jié)用真實(shí)設(shè)備跑一遍核心功能和關(guān)鍵頁面模擬器替代不了。另外iOS 11的安全區(qū)域適配也算是個(gè)經(jīng)典考點(diǎn)了。在iPhone X發(fā)布之后所有App都要處理劉海屏safeAreaInsets的獲取、SafeAreaLayoutGuide的使用、導(dǎo)航欄和TabBar的高度適配都是必考內(nèi)容。這種題考察的是你有沒有真正經(jīng)歷過適配打磨這不光是代碼問題更是產(chǎn)品體驗(yàn)問題。我在項(xiàng)目里通常的做法是統(tǒng)一封裝一套布局基類把安全區(qū)域的邊距都抽象成常量這樣就算出了新機(jī)型也只需要更新這一個(gè)地方。3.3 多線程與并發(fā)編程多線程和并發(fā)編程是大廠筆試的重災(zāi)區(qū)因?yàn)檫@塊既考概念又考代碼還考實(shí)際踩坑的經(jīng)驗(yàn)。GCDGrand Central Dispatch是考察重點(diǎn)你必須能說清楚串行隊(duì)列和并發(fā)隊(duì)列的區(qū)別同步任務(wù)和異步任務(wù)的區(qū)別以及任務(wù)和隊(duì)列組合出來的各種效果。其中最容易出錯(cuò)的是死鎖問題。經(jīng)典的“死鎖題目”是這樣的在主隊(duì)列上調(diào)用dispatch_sync會(huì)死鎖。為什么因?yàn)橹麝?duì)列是串行隊(duì)列同步提交一個(gè)Block到當(dāng)前串行隊(duì)列而這個(gè)Block要等前面的任務(wù)執(zhí)行完才執(zhí)行但前面的任務(wù)正在等這個(gè)Block執(zhí)行完互相等待就死鎖了。如果你在同步提交的Block里又嵌套了一層dispatch_sync提交到同一個(gè)隊(duì)列同樣是死鎖。我在面試時(shí)經(jīng)常出這道題能答對(duì)的應(yīng)屆生比例并不高。鎖的選擇也是一個(gè)很好的考察點(diǎn)。synchronized、NSLock、NSRecursiveLock、OSSpinLock、os_unfair_lock、dispatch_semaphore這些鎖的性能和適用場(chǎng)景各不相同。OSSpinLock因?yàn)閮?yōu)先級(jí)反轉(zhuǎn)問題已經(jīng)被廢棄了面試時(shí)如果你還推薦它會(huì)被扣印象分?，F(xiàn)在的主流選擇是os_unfair_lock做輕量級(jí)互斥dispatch_semaphore做信號(hào)量控制synchronized因?yàn)榈讓邮沁f歸鎖性能最差但容錯(cuò)最好適合簡(jiǎn)單場(chǎng)景標(biāo)保護(hù)。RunLoop也是這套題里經(jīng)常出現(xiàn)的內(nèi)容?？疾禳c(diǎn)通常是RunLoop的Source、Timer、Observer三類事件源以及RunLoop的Mode切換。在iOS開發(fā)中RunLoop最經(jīng)典的應(yīng)用就是滑動(dòng)TableView時(shí)暫停非緊急任務(wù)用Observer監(jiān)聽kCFRunLoopBeforeWaiting在空閑時(shí)執(zhí)行預(yù)先分派的輕量級(jí)任務(wù)這樣能顯著提升滾動(dòng)的流暢度。另外AFNetworking早期版本也有一道經(jīng)典面試題就是為什么要在子線程里添加RunLoop因?yàn)镹SURLConnection的代理回調(diào)需要RunLoop來驅(qū)動(dòng)而主線程的RunLoop可能被UI操作阻塞。4. 常見問題與排查技巧實(shí)錄4.1 筆試中常見的“陷阱題”類型我?guī)筒簧偻瑢W(xué)做過筆試復(fù)盤發(fā)現(xiàn)大家在愛奇藝這類筆試?yán)镌愿^的地方往往出奇一致。第一種是“看似簡(jiǎn)單實(shí)則復(fù)雜”的題比如給你一段MemoryLayout相關(guān)的代碼問打印結(jié)果很多人憑直覺就答了沒注意深拷貝和淺拷貝的問題。第二種是“概念辨析”的題比如問“atomic一定線程安全嗎”正確答案是不一定atomic只能保證屬性的讀寫原子性不能保證業(yè)務(wù)邏輯的線程安全很多人一看到atomic就選安全這是典型的概念混淆。第三種是“讀過沒理解”的題比如考autoreleasepool的底層實(shí)現(xiàn)很多人知道它是通過AutoreleasePoolPage來管理的但問到對(duì)象什么時(shí)候真正釋放就說不清了。面對(duì)這些陷阱題我的建議是下筆之前先畫圖。無論是一個(gè)對(duì)象引用的關(guān)系圖還是一個(gè)事件的傳遞路徑圖畫出圖來邏輯就清楚了一半。另外遇到不會(huì)的題不要空著把能想到的相關(guān)知識(shí)點(diǎn)寫上去有些筆試是人工閱卷的步驟分和思路分也是分。一條答題經(jīng)驗(yàn)筆試不只是考察結(jié)果更是考察你的思考過程。4.2 從筆試到面試的高頻追問點(diǎn)做好筆試只是第一步接下來面試官會(huì)根據(jù)你筆試的答案做深入追問。比如筆試考了KVO面試官就可能追問KVO注冊(cè)的觀察者在dealloc時(shí)沒有移除會(huì)怎么樣在iOS 11之后系統(tǒng)會(huì)在對(duì)象釋放時(shí)自動(dòng)移除觀察者但在iOS 11之前不會(huì)析構(gòu)時(shí)會(huì)崩潰。再比如筆試考了Block面試官會(huì)追問Block的截獲變量是怎么實(shí)現(xiàn)的為什么局部變量默認(rèn)是值捕獲而static變量和全局變量不需要捕獲這兩個(gè)問題能答上來Block這塊基本就是滿分了。我的建議是做筆試準(zhǔn)備的時(shí)候每道題都往深了問自己三個(gè)“為什么”。當(dāng)你把一道題背后的三個(gè)“為什么”都弄明白的時(shí)候筆試那道題就算得分不高面試也一定能翻盤。因?yàn)槊嬖嚬倏粗氐牟皇悄惚沉硕嗌僦R(shí)點(diǎn)而是你有沒有自己的思考深度。我?guī)н^的一個(gè)學(xué)員就是這樣筆試答得一般但面試時(shí)因?yàn)閷?duì)RunLoop的理解特別深最終拿到了offer。4.3 實(shí)用的其他備考建議關(guān)于備考材料我建議不要只抱著那一兩本iOS面試書死啃。比較好的組合是官方文檔加源碼加實(shí)際項(xiàng)目。官方文檔看API設(shè)計(jì)思路源碼看實(shí)現(xiàn)細(xì)節(jié)實(shí)際項(xiàng)目把理論應(yīng)用一遍。三者缺一不可?？丛创a的時(shí)候我強(qiáng)烈建議從objc4和GCD的開源代碼開始看這兩個(gè)是iOS的基石也是面試官最喜歡深挖的地方。第一次看源碼可能會(huì)比較吃力但你只需要關(guān)注跟面試相關(guān)的關(guān)鍵路徑不必逐行讀懂。刷題的時(shí)間安排也很有講究。我見過不少同學(xué)是在投簡(jiǎn)歷前兩周才開始刷題這基本是來不及的。比較合理的安排是提前一到兩個(gè)月每天固定刷十道題每道題連帶把考點(diǎn)擴(kuò)展一遍。這樣到筆試前你已經(jīng)建立起完整的知識(shí)網(wǎng)絡(luò)而不是零散的知識(shí)點(diǎn)集合。另外我建議做一套自己的“錯(cuò)題本”不是抄題目和答案而是寫清楚這道題考了什么知識(shí)點(diǎn)、我當(dāng)時(shí)為什么錯(cuò)、正確的思考路徑是什么。這個(gè)錯(cuò)題本在面試前翻一遍比盲目刷題有效得多。我個(gè)人的習(xí)慣是每做完一套真題都會(huì)花兩倍于做題的時(shí)間去做復(fù)盤。先對(duì)著答案檢查對(duì)錯(cuò)然后不看答案把每一道題的完整解題思路和涉及的知識(shí)點(diǎn)自己講一遍講不出來的地方就是知識(shí)盲區(qū)重點(diǎn)補(bǔ)。這個(gè)過程很費(fèi)時(shí)間但效果也是最好的。準(zhǔn)備筆試這件事沒有捷徑但找對(duì)了方法效率差距可以非常大。