做小紅書(shū)2020校招iOS方向筆試題卷三的時(shí)候我第一反應(yīng)是這套卷子不適合考前突擊。和很多公司直接甩出一堆“八股文流水賬”不同卷三里的題目翻來(lái)覆去都在問(wèn)一個(gè)問(wèn)題——你平時(shí)敲代碼的時(shí)候到底有沒(méi)有想過(guò)它為什么這么寫(xiě)?？纪晡一藘芍馨丫碜永锩總€(gè)知識(shí)點(diǎn)重新過(guò)了一遍整理出這份解析。對(duì)于正在準(zhǔn)備校招的同學(xué)它是一張復(fù)習(xí)地圖對(duì)于已經(jīng)工作的iOS開(kāi)發(fā)它更像一套自測(cè)題這些考點(diǎn)你還能拍著胸脯說(shuō)全都會(huì)嗎1. 考情速覽這套卷子到底在考什么1.1 題型結(jié)構(gòu)與考點(diǎn)分布先聊考情。據(jù)我印象整理卷三的題型大致分四塊單選/多選、編程題、原理簡(jiǎn)答題、開(kāi)放設(shè)計(jì)題。選擇題考察的都是iOS日常開(kāi)發(fā)繞不開(kāi)的基礎(chǔ)但絕對(duì)沒(méi)有“白送分”的選項(xiàng)每個(gè)干擾項(xiàng)都有迷惑性編程題集中在數(shù)據(jù)結(jié)構(gòu)和字符串處理難度不低但也不至于勸退原理題則圍繞Runtime、內(nèi)存管理、多線(xiàn)程這幾個(gè)老生常談的方向深挖光會(huì)背概念根本應(yīng)付不了最后一道開(kāi)放題很考驗(yàn)平時(shí)有沒(méi)有真正做過(guò)項(xiàng)目因?yàn)榇鸢笡](méi)有標(biāo)準(zhǔn)只看你的表達(dá)和思路。考點(diǎn)分布我做了一個(gè)大致估算方便對(duì)癥復(fù)習(xí)方向題型高頻考點(diǎn)大致占比Objective-C語(yǔ)言基礎(chǔ)單選/多選分類(lèi)、屬性修飾符、block、KVC/KVO25%iOS系統(tǒng)框架單選/簡(jiǎn)答Runtime、Runloop、多線(xiàn)程、內(nèi)存管理30%數(shù)據(jù)結(jié)構(gòu)與算法編程題LRU緩存、鏈表、樹(shù)、字符串25%網(wǎng)絡(luò)與存儲(chǔ)單選/簡(jiǎn)答TCP三次握手、HTTPS、沙盒目錄、持久化10%性能優(yōu)化與架構(gòu)簡(jiǎn)答/開(kāi)放卡頓優(yōu)化、圖片加載方案10%這個(gè)配比透露了一個(gè)信息iOS校招筆試不再只考“你會(huì)不會(huì)用UIKit拖一個(gè)頁(yè)面”而是把重點(diǎn)放在底層機(jī)制和工程決策上。尤其是Runtime和內(nèi)存管理加起來(lái)占了近三成說(shuō)明官方想招的不是只會(huì)調(diào)用API的“業(yè)務(wù)仔”而是遇到線(xiàn)上問(wèn)題能獨(dú)立排查的人。1.2 卷三傳遞的信號(hào)能力模型變了很多同學(xué)刷題時(shí)容易陷入一個(gè)誤區(qū)覺(jué)得“把LeetCode刷夠500題就能穩(wěn)過(guò)筆試”。但卷三里真正卡人的往往不是純算法題而是那些看起來(lái)很簡(jiǎn)單、實(shí)際非常容易答偏的OC語(yǔ)言題。舉個(gè)典型的例子分類(lèi)到底能不能添加實(shí)例變量如果只答“不能”基本拿不到分要說(shuō)出“為什么不能、關(guān)聯(lián)對(duì)象是什么、底層如何實(shí)現(xiàn)”才算過(guò)關(guān)。這道題背后想考察的是你有沒(méi)有認(rèn)真看過(guò)Objective-C的類(lèi)結(jié)構(gòu)是否知道編譯期和運(yùn)行期的職責(zé)劃分。再比如多選里如果出現(xiàn)“下列哪些方式會(huì)引發(fā)循環(huán)引用”ABCD四個(gè)選項(xiàng)看起來(lái)都對(duì)但實(shí)際要對(duì)“NSTimer的target持有、block內(nèi)直接使用self、delegate用strong修飾、GCD閉包持有self”做逐一辨析。這就是經(jīng)驗(yàn)和基礎(chǔ)的雙重考驗(yàn)。整場(chǎng)做下來(lái)我的感受是這套卷子不是為了挑選“背得最熟的人”而是為了挑選“理解最深刻的人”。2. 算法與數(shù)據(jù)結(jié)構(gòu)題不只考“會(huì)寫(xiě)”還考“為什么這么寫(xiě)”2.1 LRU緩存數(shù)據(jù)結(jié)構(gòu)選型背后的工程邏輯卷三的編程題部分我印象最深的是手寫(xiě)LRU緩存。題目要求實(shí)現(xiàn)一個(gè)滿(mǎn)足“最近最少使用”策略的緩存結(jié)構(gòu)支持get和put并且要求時(shí)間復(fù)雜度為O(1)。LRU這個(gè)考點(diǎn)之所以高頻是因?yàn)閮?nèi)容型App的圖片緩存、內(nèi)存緩存、數(shù)據(jù)庫(kù)頁(yè)緩存全都能用到這套機(jī)制。實(shí)現(xiàn)它的核心是“哈希表雙向鏈表”哈希表負(fù)責(zé)O(1)的時(shí)間復(fù)雜度找到節(jié)點(diǎn)雙向鏈表負(fù)責(zé)維護(hù)訪(fǎng)問(wèn)順序。為什么不能用數(shù)組因?yàn)閿?shù)組的插入和刪除是O(n)鏈表改指針是O(1)。為什么不能只用鏈表因?yàn)椴檎夜?jié)點(diǎn)需要遍歷是O(n)。兩者的結(jié)合是經(jīng)典的空間換時(shí)間方案。我在整理代碼時(shí)用Swift重新寫(xiě)了一個(gè)可運(yùn)行的版本核心邏輯如下final class LRUCache { private final class Node { let key: Int var value: Int var prev: Node? var next: Node? init(_ key: Int, _ value: Int) { self.key key self.value value } } private let capacity: Int private var dict [Int: Node]() private let head Node(-1, -1) // 哨兵節(jié)點(diǎn) private let tail Node(-1, -1) init(_ capacity: Int) { self.capacity capacity head.next tail tail.prev head } func get(_ key: Int) - Int { guard let node dict[key] else { return -1 } moveToTail(node) // 每次訪(fǎng)問(wèn)都移動(dòng)到尾部 return node.value } func put(_ key: Int, _ value: Int) { if let node dict[key] { node.value value moveToTail(node) return } let node Node(key, value) dict[key] node addToTail(node) if dict.count capacity, let removed head.next { removeNode(removed) dict.removeValue(forKey: removed.key) } } private func removeNode(_ node: Node) { node.prev?.next node.next node.next?.prev node.prev } private func addToTail(_ node: Node) { node.prev tail.prev node.next tail tail.prev?.next node tail.prev node } private func moveToTail(_ node: Node) { removeNode(node) addToTail(node) } }代碼本身不復(fù)雜但有幾個(gè)細(xì)節(jié)特別容易在筆試時(shí)翻車(chē)。第一邊界條件是容量為1此時(shí)head和tail相鄰每一次moveToTail和remove都要保證指針不斷。第二put一個(gè)已經(jīng)存在的key時(shí)要先更新值再移動(dòng)位置到尾部而不是簡(jiǎn)單丟棄。第三內(nèi)存溢出時(shí)移除鏈表尾節(jié)點(diǎn)時(shí)一定要同步從字典中移除否則后面會(huì)越查越大。我認(rèn)為這道題真正的得分點(diǎn)在于向面試官解釋“為什么用雙向鏈表而不是單向鏈表”。單向鏈表雖然也能維護(hù)順序但當(dāng)需要?jiǎng)h除一個(gè)節(jié)點(diǎn)時(shí)必須知道它的前驅(qū)節(jié)點(diǎn)在O(1)要求下要么額外存儲(chǔ)前驅(qū)指針要么把后繼節(jié)點(diǎn)的值拷貝上來(lái)再刪除后繼節(jié)點(diǎn)操作非常別扭。雙向鏈表直接讓刪除和移動(dòng)都變成指針操作代碼簡(jiǎn)潔且不容易出錯(cuò)。能把這個(gè)理由講清楚比你默寫(xiě)出完整代碼更能體現(xiàn)水平。2.2 字符串、鏈表與樹(shù)高頻題型的標(biāo)配解法除了LRU卷三的算法題里還出現(xiàn)過(guò)字符串相關(guān)和二叉樹(shù)相關(guān)的題目這些都屬于校招筆試“標(biāo)配”范圍。字符串題里有一個(gè)經(jīng)典版找出字符串中第一個(gè)不重復(fù)的字符。常規(guī)解法是兩輪遍歷第一輪用字典記錄每個(gè)字符出現(xiàn)的次數(shù)第二輪從頭掃描找到第一個(gè)計(jì)數(shù)為1的字符。這個(gè)題本身不難但要注意使用OC的NSString時(shí)遍歷字符的方式會(huì)影響性能更推薦用unichar數(shù)組或者Swift的Character視圖避免在循環(huán)里頻繁進(jìn)行字符串截取。還有邊界條件要問(wèn)清楚字符串為空返回什么沒(méi)有不重復(fù)字符返回什么很多人在LeetCode上寫(xiě)慣了return -1但筆試平臺(tái)可能要求返回\0或者nil題目沒(méi)說(shuō)清楚就默認(rèn)用nil并注釋說(shuō)明。鏈表題里反轉(zhuǎn)鏈表是“背了就能寫(xiě)”的題目但很多同學(xué)一緊張就丟邊界。核心就是三指針迭代func reverseList(_ head: ListNode?) - ListNode? { var prev: ListNode? var cur head while cur ! nil { let next cur?.next cur?.next prev prev cur cur next } return prev }關(guān)鍵是確認(rèn)循環(huán)結(jié)束后prev才是新頭節(jié)點(diǎn)而原來(lái)的head會(huì)成為新的尾節(jié)點(diǎn)它的next必須是nil。有些實(shí)現(xiàn)會(huì)在紙上推過(guò)程的時(shí)候漏掉這一步導(dǎo)致鏈表成環(huán)筆試平臺(tái)會(huì)直接判超時(shí)或死循環(huán)。建議平時(shí)多練手寫(xiě)而不是只在IDE里跑通。二叉樹(shù)題目里最近公共祖先LCA是高頻中的高頻。遞歸解法最直觀(guān)從葉子往上找如果某個(gè)節(jié)點(diǎn)的左右子樹(shù)分別包含了p和q那它就是公共祖先。這里有一個(gè)細(xì)節(jié)使用遞歸時(shí)要明確“邊界條件是遇到nil或者說(shuō)遇到了p或q本身”。很多深度優(yōu)先的遞歸題起手式都是這幾個(gè)判斷模板感很強(qiáng)練熟了對(duì)筆試速度幫助很大。2.3 面試官真正想看的邊界意識(shí)筆試算法題和日常刷題有一個(gè)微妙差別平臺(tái)不會(huì)給你用例的詳細(xì)解釋只有輸出對(duì)不對(duì)。所以“邊界意識(shí)”就成了區(qū)分度最高的能力。卷三里不少題目看起來(lái)容易其實(shí)陷阱就藏在邊界里。舉一個(gè)鏈表題里常見(jiàn)的坑合并兩個(gè)有序鏈表。很多同學(xué)寫(xiě)完主循環(huán)忘記處理“其中一個(gè)鏈表已經(jīng)走到尾部”的情況導(dǎo)致結(jié)果少了一段。正確做法是在循環(huán)結(jié)束后把剩余的鏈表節(jié)點(diǎn)接上去。這個(gè)處理只要兩行但遺漏了基本只能拿一半分?jǐn)?shù)。另一個(gè)邊界問(wèn)題是空值處理。LRU的get對(duì)不存在的key返回什么字符串題里找不到目標(biāo)字符返回什么二叉樹(shù)的根節(jié)點(diǎn)是nil時(shí)怎么辦這些看起來(lái)是細(xì)節(jié)但筆試平臺(tái)是按用例給分的邊界用例往往占比不低。我自己的習(xí)慣是寫(xiě)任何算法題先跟面試官或者自己在注釋里確認(rèn)三個(gè)問(wèn)題——輸入能否為空、輸出類(lèi)型是什么、極端值比如最大/最小整數(shù)是否特殊。這套習(xí)慣幫我避免了很多無(wú)謂的丟分。3. Objective-C語(yǔ)言底層分類(lèi)、屬性關(guān)鍵字和對(duì)象模型3.1 分類(lèi)能不能加屬性標(biāo)準(zhǔn)答案與關(guān)聯(lián)對(duì)象卷三的選擇題里有一道題幾乎年年出現(xiàn)分類(lèi)Category能否添加實(shí)例變量答案是不能但很多人會(huì)在這里栽跟頭因?yàn)榉诸?lèi)聲明中使用property時(shí)編譯器并不會(huì)報(bào)錯(cuò)只是不會(huì)自動(dòng)生成_變量名和對(duì)應(yīng)的getter/setter實(shí)現(xiàn)。根本原因在于實(shí)例變量的內(nèi)存空間在類(lèi)對(duì)象創(chuàng)建時(shí)就已經(jīng)確定了而分類(lèi)是運(yùn)行時(shí)才被加載的它無(wú)法改變類(lèi)已經(jīng)分配好的內(nèi)存布局所以分類(lèi)只能添加方法不能直接添加實(shí)例變量。那如果開(kāi)發(fā)中確實(shí)需要“給已有類(lèi)添加一個(gè)帶存儲(chǔ)能力的屬性”怎么辦通用做法是關(guān)聯(lián)對(duì)象。底層是objc_setAssociatedObject和objc_getAssociatedObject兩個(gè)C函數(shù)通過(guò)一個(gè)全局的AssociationsManager哈希表來(lái)維護(hù)“對(duì)象地址關(guān)聯(lián)key - 關(guān)聯(lián)值”的關(guān)系。但要注意關(guān)聯(lián)對(duì)象也并非完全沒(méi)有成本它本質(zhì)上是把存儲(chǔ)挪到了類(lèi)的內(nèi)存結(jié)構(gòu)之外不會(huì)自動(dòng)釋放依賴(lài)對(duì)象本身在dealloc時(shí)由runtime統(tǒng)一清理。筆試如果只答到這里大概能拿70%的分?jǐn)?shù)。加分項(xiàng)是把“為什么不能”說(shuō)清楚Objective-C的類(lèi)和實(shí)例變量在編譯期就完成了布局之后不能動(dòng)態(tài)增加ivar否則會(huì)破壞所有已經(jīng)創(chuàng)建實(shí)例的內(nèi)存連續(xù)性。而關(guān)聯(lián)對(duì)象相當(dāng)于在類(lèi)外掛了一張表用key關(guān)聯(lián)value所以它可以“動(dòng)態(tài)增加”但它不是真正的實(shí)例變量。能答出這層區(qū)別說(shuō)明你不只是記住了結(jié)論而是理解了兩套機(jī)制的底層差異。3.2 屬性修飾符不是背出來(lái)的是用出來(lái)的屬性修飾符是iOS開(kāi)發(fā)的基礎(chǔ)也是筆試卷子里的?？?。卷三選擇的干擾項(xiàng)特別喜歡把strong和copy混在一起考察你知不知道什么時(shí)候該用哪個(gè)。修飾符語(yǔ)義典型使用場(chǎng)景copy拷貝一個(gè)新對(duì)象不共享可變內(nèi)容NSString、NSArray、Blockstrong持有引用引用計(jì)數(shù)1一般對(duì)象屬性weak不持有引用釋放后自動(dòng)置nildelegate、Outletassign直接賦值不參與內(nèi)存管理基礎(chǔ)類(lèi)型、CGFloat、NSInteger這里有兩個(gè)高頻知識(shí)點(diǎn)。第一為什么NSString要用copy修飾因?yàn)橥獠靠赡軅鬟M(jìn)來(lái)一個(gè)NSMutableString如果你用strong持有它外部后續(xù)修改這個(gè)可變字符串你的屬性?xún)?nèi)容也會(huì)跟著變化這是非常隱蔽的Bug。用copy就會(huì)生成一個(gè)不可變副本從此與外界無(wú)關(guān)。第二為什么Block屬性要用copy因?yàn)樵贛RC時(shí)代Block默認(rèn)存放在棧區(qū)離開(kāi)作用域可能被回收copy將其拷貝到堆區(qū)保證屬性在之后的任意時(shí)間點(diǎn)都能夠安全調(diào)用。ARC下編譯器在賦值時(shí)已經(jīng)幫我們做了類(lèi)似處理但保留copy依舊是約定俗成的規(guī)范寫(xiě)法。還要特別強(qiáng)調(diào)一個(gè)易錯(cuò)點(diǎn)assign修飾對(duì)象類(lèi)型是不安全的如果被修飾的對(duì)象被釋放assign屬性會(huì)變成一個(gè)懸垂指針再次訪(fǎng)問(wèn)就會(huì)野指針崩潰。正確答案是對(duì)象類(lèi)型用weak基礎(chǔ)類(lèi)型用assign。這個(gè)知識(shí)點(diǎn)在多選題里經(jīng)常作為一個(gè)干擾項(xiàng)出現(xiàn)選錯(cuò)了整題扣分。3.3 isa指針從對(duì)象到元類(lèi)的完整鏈路在OC對(duì)象模型相關(guān)題目里isa指針是繞不開(kāi)的重點(diǎn)。這里有個(gè)容易混淆的細(xì)節(jié)早期的isa就是簡(jiǎn)單的Class指針后來(lái)為了效率優(yōu)化變成了聯(lián)合體isa_t里面除了類(lèi)信息還會(huì)用位域存儲(chǔ)引用計(jì)數(shù)、是否弱引用等狀態(tài)。所以現(xiàn)在說(shuō)“對(duì)象的isa指向它的類(lèi)”在宏觀(guān)上沒(méi)問(wèn)題但嚴(yán)格來(lái)說(shuō)是“isa_t包含了類(lèi)的信息”。完整鏈路是實(shí)例對(duì)象的isa指向類(lèi)對(duì)象類(lèi)對(duì)象的isa指向元類(lèi)元類(lèi)的isa指向根元類(lèi)根元類(lèi)的isa指向自己形成一個(gè)閉環(huán)。類(lèi)對(duì)象的存儲(chǔ)內(nèi)容是實(shí)例方法列表、屬性列表、協(xié)議列表元類(lèi)里存儲(chǔ)的是類(lèi)方法列表。平時(shí)調(diào)用類(lèi)方法時(shí)runtime是通過(guò)“類(lèi)對(duì)象 - 元類(lèi)”這條鏈來(lái)查找方法實(shí)現(xiàn)的。這塊內(nèi)容很容易被低估因?yàn)槿粘ｉ_(kāi)發(fā)很少直接操作isa。但筆試如果考到“消息發(fā)送時(shí)實(shí)例方法從哪里找、類(lèi)方法從哪里找”你就需要把這條鏈路畫(huà)出來(lái)。建議把這張圖在腦子里記清楚對(duì)象到類(lèi)、類(lèi)到元類(lèi)、元類(lèi)到根元類(lèi)以及根元類(lèi)的isa指向自身。這個(gè)模型理解了很多Runtime題都能豁然開(kāi)朗。4. Runtime題消息機(jī)制才是iOS的“靈魂”4.1 一條消息從發(fā)送到找不到實(shí)現(xiàn)完整路徑OC的方法調(diào)用本質(zhì)上是消息發(fā)送這在卷三里幾乎必考。題目通常會(huì)問(wèn)你調(diào)用一個(gè)對(duì)象方法從開(kāi)始到執(zhí)行runtime做了什么完整路徑要分幾步講。第一步檢查目標(biāo)對(duì)象是否為nil為nil時(shí)消息直接丟棄這也是為什么向nil發(fā)送消息不會(huì)崩潰。第二步根據(jù)對(duì)象的isa找到類(lèi)對(duì)象先在方法的緩存cache_t里查找命中就直接執(zhí)行。第三步緩存未命中則遍歷類(lèi)對(duì)象的方法列表還找不到就沿著superclass鏈往上找直到NSObject。第四步如果整個(gè)繼承鏈都沒(méi)有對(duì)應(yīng)實(shí)現(xiàn)進(jìn)入動(dòng)態(tài)方法解析resolveInstanceMethod允許你動(dòng)態(tài)給類(lèi)添加方法。第五步如果動(dòng)態(tài)解析也沒(méi)處理就會(huì)走消息轉(zhuǎn)發(fā)流程先問(wèn)forwardingTargetForSelector有沒(méi)有替身對(duì)象再問(wèn)methodSignatureForSelector和forwardInvocation能否完整包一層轉(zhuǎn)發(fā)。最后都不行就會(huì)調(diào)用doesNotRecognizeSelector拋出異常。筆試不會(huì)讓你一字不差背出源碼但會(huì)以選擇題的形式考察向nil發(fā)送消息為什么不崩潰消息轉(zhuǎn)發(fā)有哪幾步resolveInstanceMethod在消息轉(zhuǎn)發(fā)之前還是之后這些細(xì)節(jié)如果只停留在“聽(tīng)說(shuō)過(guò)”的程度很容易選錯(cuò)。我的記憶方法是把它當(dāng)作一個(gè)漏斗緩存找不到就去方法列表找方法列表找不到就去父類(lèi)找父類(lèi)找不到就給你最后的三次補(bǔ)救機(jī)會(huì)機(jī)會(huì)用完就崩。這樣理解起來(lái)非常順。4.2 方法交換的正確姿勢(shì)與常見(jiàn)翻車(chē)點(diǎn)方法交換Method Swizzling是Runtime在工程中最常見(jiàn)的落地場(chǎng)景之一比如AOP打點(diǎn)、無(wú)侵入埋點(diǎn)、網(wǎng)絡(luò)日志記錄。卷三的簡(jiǎn)答題里有很大的概率考到而且會(huì)給一個(gè)場(chǎng)景“如何在不動(dòng)業(yè)務(wù)代碼的前提下統(tǒng)計(jì)所有UIViewController的viewDidAppear”標(biāo)準(zhǔn)思路是寫(xiě)一個(gè)UIViewController分類(lèi)在load里交換viewDidLoad和swizzled_viewDidLoad。之所以在load里做是因?yàn)樗窃陬?lèi)加載完成后立即調(diào)用的時(shí)機(jī)最早同時(shí)要用dispatch_once保證只交換一次避免多重加載時(shí)重復(fù)交換導(dǎo)致遞歸。正確的交換寫(xiě)法大致是 (void)load { static dispatch_once_t onceToken; dispatch_once(onceToken, ^{ SEL originalSelector selector(viewDidLoad); SEL swizzledSelector selector(swizzled_viewDidLoad); Method originalMethod class_getInstanceMethod(self, originalSelector); Method swizzledMethod class_getInstanceMethod(self, swizzledSelector); method_exchangeImplementations(originalMethod, swizzledMethod); }); } - (void)swizzled_viewDidLoad { [self swizzled_viewDidLoad]; // 在這里插入埋點(diǎn)邏輯 NSLog(頁(yè)面出現(xiàn)%, self); }這里有個(gè)特別容易翻車(chē)的點(diǎn)交換后swizzled_viewDidLoad的調(diào)用會(huì)在方法內(nèi)部遞歸調(diào)用自己。因?yàn)閮?nèi)部的[self swizzled_viewDidLoad]在實(shí)際運(yùn)行時(shí)由于IMP已經(jīng)被交換執(zhí)行的是原viewDidLoad的實(shí)現(xiàn)而外部的原始調(diào)用此時(shí)執(zhí)行的是swizzled_viewDidLoad的實(shí)現(xiàn)。很多初學(xué)者在這里繞暈以為是死循環(huán)其實(shí)是正常的。真正危險(xiǎn)的是在分類(lèi)里對(duì)父類(lèi)方法做交換或者交換非自身的方法這些操作容易破壞繼承鏈的方法查找邏輯導(dǎo)致整個(gè)App行為異常。我在準(zhǔn)備這類(lèi)題時(shí)建議把重點(diǎn)放在“為什么用dispatch_once”“為什么在load而不是initialize”“交換后的IMP對(duì)應(yīng)關(guān)系”三個(gè)問(wèn)題上。面試官問(wèn)得深一點(diǎn)也就是這三點(diǎn)。4.3 KVC/KVO底層是怎么實(shí)現(xiàn)的KVC和KVO也是校招筆試題中的?？徒?jīng)常以原理題出現(xiàn)。KVC即鍵值編碼比如[obj setValue:xx forKey:name]。它的查找順序有固定套路設(shè)置值時(shí)會(huì)先找setName:方法找不到再找_setName:還沒(méi)有就看accessInstanceVariablesDirectly是否為YES是則依次查找_name、_isName、name、isName實(shí)例變量全部找不到最后調(diào)用setValue:forUndefinedKey:。取值時(shí)順序反過(guò)來(lái)依次找getName:、name、isName、_name等。這套查找機(jī)制讓KVC有了讀寫(xiě)私有變量的能力比如通過(guò)valueForKey讀取_xxx開(kāi)頭的成員變量。KVO則依賴(lài)動(dòng)態(tài)生成子類(lèi)。當(dāng)你對(duì)一個(gè)對(duì)象添加觀(guān)察者時(shí)runtime會(huì)動(dòng)態(tài)創(chuàng)建一個(gè)新的子類(lèi)并把對(duì)象的isa指針指向這個(gè)子類(lèi)。這個(gè)子類(lèi)重寫(xiě)了被觀(guān)察屬性的setter方法在設(shè)置值前后分別調(diào)用willChangeValueForKey:和didChangeValueForKey:從而觸發(fā)回調(diào)。這也是為什么KVO默認(rèn)只能監(jiān)聽(tīng)屬性變化而不能直接監(jiān)聽(tīng)實(shí)例變量的賦值。一個(gè)隱藏的考點(diǎn)是手動(dòng)觸發(fā)KVO。如果你直接修改_name實(shí)例變量KVO默認(rèn)不會(huì)被觸發(fā)因?yàn)閟etter沒(méi)有被調(diào)用。要做到手動(dòng)觸發(fā)需要自己在修改前后調(diào)用willChangeValueForKey:和didChangeValueForKey:。這個(gè)知識(shí)點(diǎn)在筆試?yán)锖苌僬婵嫉珪?huì)導(dǎo)致一個(gè)很有意思的追問(wèn)KVO只對(duì)屬性有效對(duì)嗎這時(shí)候你如果能回答“不對(duì)是只有通過(guò)setter修改才有效”印象分會(huì)高不少。5. 內(nèi)存管理、并發(fā)與Runloop最容易丟分的組合拳5.1 循環(huán)引用的高發(fā)場(chǎng)景與修復(fù)內(nèi)存管理相關(guān)的題目起手式往往是“一個(gè)對(duì)象持有blockblock里又用了self會(huì)造成循環(huán)引用嗎”答案是會(huì)因?yàn)閷?duì)象持有blockblock又會(huì)把外部變量捕獲進(jìn)去如果捕獲的是self兩者就形成了持有環(huán)誰(shuí)都無(wú)法釋放。卷三的多選題里這個(gè)考點(diǎn)被拆成了幾個(gè)場(chǎng)景。第一個(gè)是block解決方法是__weak typeof(self) weakSelf self在block內(nèi)部用weakSelf如果需要保證block執(zhí)行期間self不被釋放再在外面持有__strong局部變量。第二個(gè)是代理delegate如果用strong修飾就會(huì)造成持有環(huán)應(yīng)該用weak。第三個(gè)是NSTimerNSTimer的target是強(qiáng)持有的如果控制器持有timertimer又強(qiáng)持有控制器就循環(huán)了iOS 10之后可以通過(guò)block方式創(chuàng)建timer并在dealloc中調(diào)用invalidate或者用一個(gè)中間代理對(duì)象破環(huán)。第四個(gè)是CADisplayLink它同樣強(qiáng)持有target處理方式類(lèi)似。這里我要特別強(qiáng)調(diào)NSTimer的坑即使你用了__weak typeof(self) weakSelf如果timer的target強(qiáng)持有控制器循環(huán)依然存在因?yàn)閣eakSelf只是block內(nèi)部不持有而timer的target賦值本身就是強(qiáng)持有。所以解決NSTimer循環(huán)引用的關(guān)鍵是“不把self作為target”要么換成block方式要么通過(guò)一個(gè)代理對(duì)象轉(zhuǎn)發(fā)。很多同學(xué)一看到block就條件反射寫(xiě)weakSelf結(jié)果在NSTimer這里反而丟分。5.2 weak到底是怎么做到自動(dòng)置nil的弱引用weak的自動(dòng)置nil機(jī)制是iOS內(nèi)存管理里最值得深挖的問(wèn)題之一筆試簡(jiǎn)答題出現(xiàn)頻率很高。底層邏輯是這樣runtime維護(hù)了一個(gè)全局的SideTables哈希表以對(duì)象地址為keyvalue是一個(gè)SideTable里面包含了該對(duì)象的引用計(jì)數(shù)表和弱引用表。當(dāng)對(duì)對(duì)象添加weak引用時(shí)系統(tǒng)會(huì)把“weak指針的地址”注冊(cè)進(jìn)這個(gè)對(duì)象的弱引用表。當(dāng)對(duì)象引用計(jì)數(shù)歸零、執(zhí)行dealloc時(shí)runtime會(huì)從哈希表中找到該對(duì)象對(duì)應(yīng)的表把弱引用表里所有的指針全部置為nil再繼續(xù)銷(xiāo)毀對(duì)象。理解這套機(jī)制后有幾個(gè)延伸考點(diǎn)為什么__weak變量在A(yíng)RC下使用前要賦值給一個(gè)__strong變量因?yàn)閺膚eak表取出對(duì)象到使用之間這個(gè)對(duì)象可能被其他線(xiàn)程釋放賦值給strong變量可以保證在使用期間它不會(huì)被回收。這其實(shí)是很多并發(fā)崩潰的根源也是面試官用來(lái)區(qū)分“會(huì)寫(xiě)代碼”和“懂原理”的高頻問(wèn)題。5.3 主隊(duì)列同步任務(wù)為什么必死鎖GCD的題卷三最?？嫉木褪撬梨i。最經(jīng)典的莫過(guò)于“在主線(xiàn)程/主隊(duì)列上調(diào)用dispatch_sync代碼會(huì)死鎖嗎”答案是會(huì)。原因在于主隊(duì)列是一個(gè)串行隊(duì)列dispatch_sync提交的任務(wù)必須等待之前所有任務(wù)執(zhí)行完畢才能開(kāi)始而當(dāng)前正在執(zhí)行的代碼塊本身就在主隊(duì)列里它也在等待dispatch_sync完成然后才能繼續(xù)后續(xù)邏輯。兩個(gè)任務(wù)互相等待誰(shuí)也走不了就死鎖了。同樣的情況也會(huì)發(fā)生在自己創(chuàng)建的串行隊(duì)列中在隊(duì)列A的任務(wù)里向隊(duì)列A同步提交新任務(wù)也會(huì)死鎖。這個(gè)概念對(duì)開(kāi)發(fā)者的實(shí)際意義是UI刷新和耗時(shí)操作一定要通過(guò)dispatch_async切到不同隊(duì)列不要在主線(xiàn)程里同步等結(jié)果。筆試如果出到GCD題還有一個(gè)高頻變種dispatch_sync到一個(gè)并發(fā)隊(duì)列會(huì)死鎖嗎答案是“不會(huì)立即死鎖”因?yàn)椴l(fā)隊(duì)列可以同時(shí)執(zhí)行多個(gè)任務(wù)同步提交的任務(wù)可以立刻被執(zhí)行但依然不建議在業(yè)務(wù)代碼里這么寫(xiě)因?yàn)闆](méi)有必要阻塞當(dāng)前線(xiàn)程。5.4 Runloop把“現(xiàn)象”變“原理”Runloop相關(guān)的題在卷三里占比不小出題方式往往是“為什么定時(shí)器在主線(xiàn)程滑動(dòng)列表時(shí)不準(zhǔn)了”或者“為什么performSelector:afterDelay:在子線(xiàn)程不執(zhí)行”。Runloop本質(zhì)是一個(gè)“不退出的事件循環(huán)”。它管理了多種輸入源Source0手動(dòng)事件、Source1系統(tǒng)事件、Timer定時(shí)器、Observer觀(guān)察者每一種源發(fā)生就會(huì)觸發(fā)對(duì)應(yīng)的處理回調(diào)。iOS在滾動(dòng)列表時(shí)主線(xiàn)程的Runloop會(huì)切換到UITracking模式這個(gè)模式下默認(rèn)不處理普通模式下的Timer所以NSTimer就出現(xiàn)了延遲。解決辦法是把Timer加入到CommonMode中或者用基于GCD的定時(shí)器。performSelector:afterDelay:底層也是基于Timer實(shí)現(xiàn)的它要求當(dāng)前線(xiàn)程必須有一個(gè)處于運(yùn)行狀態(tài)的Runloop。子線(xiàn)程默認(rèn)沒(méi)有開(kāi)啟Runloop所以調(diào)用之后沒(méi)有反應(yīng)。如果堅(jiān)持要用需要先[[NSRunLoop currentRunLoop] run]讓子線(xiàn)程的Runloop跑起來(lái)。這道題很能檢驗(yàn)一個(gè)人是否真的排查過(guò)線(xiàn)上問(wèn)題因?yàn)樗皇潜掣拍钅芙鉀Q的必須動(dòng)手踩過(guò)坑才能理解。6. 網(wǎng)絡(luò)、存儲(chǔ)與性能優(yōu)化題看著基礎(chǔ)實(shí)則大有文章6.1 三次握手和HTTPS的重點(diǎn)回答策略網(wǎng)絡(luò)基礎(chǔ)題在iOS校招筆試中很少缺席卷三的選擇題和簡(jiǎn)答題都可能在TCP和HTTPS上做文章。TCP三次握手為什么必須是三次第一次SYN客戶(hù)端告訴服務(wù)端“我要發(fā)送數(shù)據(jù)了”第二次SYNACK服務(wù)端告訴客戶(hù)端“我收到了我也準(zhǔn)備好了”第三次ACK客戶(hù)端告訴服務(wù)端“我收到了你的確認(rèn)”。如果只有兩次握手服務(wù)端無(wú)法確認(rèn)客戶(hù)端是否收到了自己的SYNACK。舉個(gè)例子如果客戶(hù)端第一次的SYN因?yàn)榫W(wǎng)絡(luò)阻塞被延遲客戶(hù)端已經(jīng)超時(shí)重發(fā)并建立了連接之后舊SYN才到達(dá)服務(wù)端服務(wù)端如果直接建立連接就會(huì)造成資源浪費(fèi)。三次握手能同時(shí)確認(rèn)雙方的收發(fā)能力都正常這是它存在的根本原因。HTTPS相比HTTP多了一層TLS握手。重點(diǎn)在于先用非對(duì)稱(chēng)加密協(xié)商出對(duì)稱(chēng)密鑰之后的數(shù)據(jù)傳輸用對(duì)稱(chēng)加密兼顧安全性和速度。如果追問(wèn)證書(shū)就要提到CA數(shù)字證書(shū)的作用防止中間人攻擊客戶(hù)端通過(guò)信任鏈驗(yàn)證服務(wù)器證書(shū)的真實(shí)性。準(zhǔn)備這部分時(shí)不需要把TLS的每一步狀態(tài)機(jī)背下來(lái)但要能把“為什么用非對(duì)稱(chēng)對(duì)稱(chēng)混合”講清楚。6.2 沙盒目錄與持久化方案的選擇邏輯iOS的沙盒機(jī)制是保障數(shù)據(jù)安全的基礎(chǔ)也經(jīng)常出現(xiàn)在選擇題里。沙盒主要分四個(gè)目錄目錄作用注意點(diǎn)Documents存放用戶(hù)生成的重要數(shù)據(jù)會(huì)被iCloud自動(dòng)備份不能放緩存Library/Caches存放緩存文件系統(tǒng)可能自動(dòng)清理需要自己管理Library/Preferences存放應(yīng)用配置NSUserDefaults本質(zhì)寫(xiě)在這里tmp臨時(shí)文件隨時(shí)可能被系統(tǒng)清理筆試時(shí)經(jīng)常問(wèn)“下載一個(gè)幾十MB的圖片緩存到哪個(gè)目錄”。正確的方向是Library/Caches因?yàn)镈ocuments會(huì)參與iCloud備份可能導(dǎo)致審核被拒tmp又隨時(shí)可能被清理不適合長(zhǎng)期使用。持久化方案的選擇也是一道經(jīng)典簡(jiǎn)答NSUserDefaults適合輕量級(jí)配置但性能差不能存大量數(shù)據(jù)plist讀寫(xiě)簡(jiǎn)單適合小規(guī)模結(jié)構(gòu)化數(shù)據(jù)SQLite適合大量結(jié)構(gòu)化、需要復(fù)雜查詢(xún)的數(shù)據(jù)CoreData是對(duì)象關(guān)系映射框架學(xué)習(xí)成本高但和內(nèi)存模型結(jié)合更緊密大文件直接寫(xiě)入磁盤(pán)再由FileManager管理?；卮疬@類(lèi)題的關(guān)鍵不是說(shuō)“哪個(gè)最好”而是根據(jù)數(shù)據(jù)量、讀寫(xiě)頻率和查詢(xún)需求給出取舍。6.3 列表卡頓優(yōu)化從表象答到本質(zhì)性能優(yōu)化題的面試官最反感的是只背了一堆優(yōu)化名詞卻不知道每步優(yōu)化解決的是什么問(wèn)題。卷三里如果問(wèn)“UITableView滑動(dòng)卡頓你會(huì)怎么排查和優(yōu)化”標(biāo)準(zhǔn)回答應(yīng)該分成三層。第一層是主線(xiàn)程中避免耗時(shí)操作。圖片的解碼、JSON的解析、數(shù)據(jù)庫(kù)的讀取都不該放在主線(xiàn)程。第二層是減少主線(xiàn)程渲染工作量比如避免在cellForRowAtIndexPath中頻繁創(chuàng)建新對(duì)象、通過(guò)prepareForReuse重用cell、避免給layer設(shè)置圓角并設(shè)置masksToBounds導(dǎo)致離屏渲染。第三層是提高幀率感知比如提前計(jì)算緩存cell高度避免每次布局時(shí)重復(fù)計(jì)算。更底層的方向包括避免視圖層級(jí)過(guò)深、盡量使用不透明的背景色、減少陰影和混合圖層。我記得筆試?yán)镉袀€(gè)很陰險(xiǎn)的選項(xiàng)“把圖片從磁盤(pán)讀取放到主線(xiàn)程可以提高加載速度因?yàn)橹骶€(xiàn)程內(nèi)存訪(fǎng)問(wèn)更快?！边@個(gè)選項(xiàng)是錯(cuò)的。任何IO都應(yīng)該遠(yuǎn)離主線(xiàn)程因?yàn)橹骶€(xiàn)程一卡UI就無(wú)法響應(yīng)。能在這種細(xì)節(jié)上保持清醒說(shuō)明你對(duì)“為什么優(yōu)化”有真實(shí)體感而不是只背了“優(yōu)化三板斧”。7. 開(kāi)放設(shè)計(jì)題與考場(chǎng)策略7.1 設(shè)計(jì)一個(gè)圖片加載庫(kù)怎么組織答案卷三通常以一道開(kāi)放設(shè)計(jì)題壓軸比如“如果讓你設(shè)計(jì)一個(gè)圖片加載庫(kù)你會(huì)怎么設(shè)計(jì)”。這種題沒(méi)有唯一標(biāo)準(zhǔn)答案但想拿高分必須展示出你有工程架構(gòu)思維。一個(gè)成熟的圖片加載方案至少要包含三層。第一層是內(nèi)存緩存推薦用NSCache而不是NSMutableDictionary因?yàn)镹SCache自帶自動(dòng)清理策略?xún)?nèi)存吃緊時(shí)會(huì)自動(dòng)騰出空間防止App被系統(tǒng)殺掉。第二層是磁盤(pán)緩存把圖片文件寫(xiě)入Library/Caches用URL的MD5作為文件名下次啟動(dòng)時(shí)直接讀磁盤(pán)。第三層是網(wǎng)絡(luò)下載需要一個(gè)下載隊(duì)列管理并發(fā)數(shù)避免同時(shí)請(qǐng)求過(guò)多造成帶寬壓力同一個(gè)URL的重復(fù)請(qǐng)求要合并下載完成的回調(diào)要切回主線(xiàn)程刷新UI。還有一個(gè)容易被忽略但非常重要的點(diǎn)圖片解碼。從磁盤(pán)讀到UIImage后圖片并不會(huì)立刻解碼成位圖而是在首次繪制時(shí)才進(jìn)行解碼如果這個(gè)解碼發(fā)生在主線(xiàn)程就會(huì)卡頓。所以圖片加載庫(kù)的正確做法是在后臺(tái)線(xiàn)程提前完成解碼再在主線(xiàn)程賦值給UIImageView。能把這個(gè)點(diǎn)回答出來(lái)面試官會(huì)覺(jué)得你“真的處理過(guò)圖片加載問(wèn)題”因?yàn)檫@是SDWebImage和YYImage等開(kāi)源庫(kù)都會(huì)重點(diǎn)考慮的問(wèn)題。另外開(kāi)放題考察的是思路和表達(dá)不要只甩出幾個(gè)名詞就停筆。我建議按這個(gè)順序組織答案緩存策略、線(xiàn)程模型、解碼時(shí)機(jī)、回調(diào)方式、超時(shí)與失敗處理、清理機(jī)制。就算沒(méi)有完全實(shí)現(xiàn)過(guò)只要邏輯自洽閱卷人也會(huì)認(rèn)為你有架構(gòu)能力。7.2 時(shí)間分配與細(xì)節(jié)控分技巧最后聊聊考場(chǎng)策略。卷三整體題量不小選擇題很容易磨時(shí)間建議控制在30分鐘以?xún)?nèi)算法題留60分鐘至少保證LRU這類(lèi)大題的完整實(shí)現(xiàn)簡(jiǎn)答和開(kāi)放題留30分鐘分點(diǎn)作答優(yōu)先寫(xiě)核心結(jié)論再補(bǔ)充細(xì)節(jié)。多選和不定項(xiàng)選擇是丟分重災(zāi)區(qū)。我的經(jīng)驗(yàn)是“寧缺毋濫”拿不準(zhǔn)的選項(xiàng)不要選選對(duì)了不確定項(xiàng)不一定加分但選錯(cuò)了一定扣分。簡(jiǎn)答題盡量每一條單獨(dú)起一行術(shù)語(yǔ)準(zhǔn)確比如“方法交換”、“動(dòng)態(tài)添加方法”、“弱引用表”這些關(guān)鍵詞要清晰出現(xiàn)閱卷人一掃就能看到采分點(diǎn)。編程題如果寫(xiě)不出最優(yōu)解也要先把暴力解寫(xiě)出來(lái)并通過(guò)測(cè)試不要留白。因?yàn)楣P試平臺(tái)的判定是“過(guò)多少用例給多少分”一個(gè)沒(méi)有提交的代碼即使思路再完美也是0分。做題順序上優(yōu)先做自己有把握的題把確定性得分先拿到手再去啃難題。如果讓我總結(jié)這套卷子一句話(huà)就夠了它不是考你會(huì)不會(huì)寫(xiě)iOS而是考你會(huì)不會(huì)像一個(gè)有經(jīng)驗(yàn)的iOS工程師一樣思考。刷題只是手段真正要反復(fù)問(wèn)自己的是“為什么這個(gè)知識(shí)點(diǎn)長(zhǎng)這樣設(shè)計(jì)者當(dāng)時(shí)在解決什么問(wèn)題”。把這個(gè)問(wèn)題想明白卷三的每一道題都會(huì)變成你知識(shí)體系里的一塊拼圖而不是一份需要死記的答案。