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