2023年秋招那會(huì)兒我投了小紅書(shū)的iOS開(kāi)發(fā)崗第一關(guān)就是筆試。小紅書(shū)這批筆試是線上?？途W(wǎng)做的全程開(kāi)著攝像頭限時(shí)90分鐘題量比我預(yù)期大不少客觀題加編程題加起來(lái)接近四十道?？纪曛笪易畲蟮母惺苁撬恢皇强寄銜?huì)不會(huì)寫(xiě)代碼更是在篩你有沒(méi)有完整的iOS知識(shí)體系以及對(duì)常見(jiàn)坑有沒(méi)有實(shí)際踩過(guò)的認(rèn)知。這篇文章就圍繞2023年秋招小紅書(shū)iOS開(kāi)發(fā)崗第一批筆試把題型分布、知識(shí)點(diǎn)拆解、編程題思路和備考路線一次性講清楚給后面準(zhǔn)備校招iOS崗的同學(xué)做個(gè)參考。1. 筆試整體情況與考點(diǎn)分布1.1 筆試平臺(tái)與流程安排先說(shuō)流程。小紅書(shū)秋招的筆試統(tǒng)一走?？途W(wǎng)收到郵件之后可以選時(shí)間段進(jìn)入考試。第一批發(fā)卷時(shí)間一般在9月上旬每個(gè)批次題目不完全一樣但考察范圍和難度基本是一個(gè)量級(jí)。進(jìn)入考試之后系統(tǒng)會(huì)要求打開(kāi)攝像頭、開(kāi)啟屏幕錄制權(quán)限中途切出頁(yè)面會(huì)有提醒切出次數(shù)多了會(huì)被標(biāo)記異常所以考試前最好把手機(jī)通知全關(guān)掉瀏覽器只留一個(gè)標(biāo)簽頁(yè)避免誤觸。整個(gè)筆試時(shí)長(zhǎng)90分鐘題型分單選、多選和編程題。客觀題大概占一半以上編程題一般是兩道到三道?？陀^題覆蓋的范圍很廣不只是iOS還包括數(shù)據(jù)結(jié)構(gòu)、操作系統(tǒng)、計(jì)算機(jī)網(wǎng)絡(luò)這些計(jì)算機(jī)基礎(chǔ)。我印象里iOS崗的筆試會(huì)把客觀題分成兩大部分一部分是通用計(jì)算機(jī)基礎(chǔ)另一部分是iOS專項(xiàng)。通用部分主要靠平時(shí)算法和計(jì)算機(jī)基礎(chǔ)功底iOS專項(xiàng)就是看你對(duì)OC/Swift語(yǔ)言、Runtime、RunLoop、內(nèi)存管理、UI和系統(tǒng)框架這些內(nèi)容掌握得夠不夠細(xì)。編程題的輸入輸出格式是?？蜆?biāo)準(zhǔn)模式需要自己寫(xiě)輸入解析。有些人LeetCode刷習(xí)慣了每題給的都是核心函數(shù)突然遇到這種要自己處理stdin的題目會(huì)有點(diǎn)慌這個(gè)在備考階段一定要提前適應(yīng)。1.2 客觀題考點(diǎn)圖譜我根據(jù)自己的記憶和一起筆試的同學(xué)反饋把客觀題的考點(diǎn)整理成了下面這個(gè)表。當(dāng)做一個(gè)“體檢清單”用每個(gè)點(diǎn)都能說(shuō)出個(gè)所以然筆試基本就穩(wěn)了。分類具體考點(diǎn)常見(jiàn)出題角度OC/Swift語(yǔ)言屬性關(guān)鍵字、block、KVO/KVC、Category、Swift可選型給一段代碼問(wèn)輸出/是否編譯通過(guò)內(nèi)存管理ARC、weak/strong、循環(huán)引用、autoreleasepool判斷引用計(jì)數(shù)變化、找循環(huán)引用系統(tǒng)框架RunLoop、GCD多線程、網(wǎng)絡(luò)、UI生命周期、布局問(wèn)你某種操作發(fā)生在哪個(gè)時(shí)機(jī)計(jì)算機(jī)基礎(chǔ)數(shù)組/鏈表/樹(shù)、排序、哈希、復(fù)雜度選擇題綜合考察操作系統(tǒng)進(jìn)程線程、死鎖、虛擬內(nèi)存概念辨析類網(wǎng)絡(luò)TCP三次握手、HTTPS流程、HTTP狀態(tài)碼流程排序、協(xié)議機(jī)制工程實(shí)踐調(diào)試、性能優(yōu)化、日志、崩潰分析給一個(gè)線上問(wèn)題問(wèn)排查思路這里有一個(gè)容易被忽略的趨勢(shì)小紅書(shū)這類內(nèi)容社區(qū)App非?？粗睾蜻x人對(duì)“列表流暢度”和“圖片加載”這兩塊的理解。所以筆試?yán)镪P(guān)于UITableView滑動(dòng)卡頓、圖片緩存策略的題并不少見(jiàn)。你要是只背了八股沒(méi)實(shí)際調(diào)過(guò)性能碰到這種題就會(huì)覺(jué)得每個(gè)選項(xiàng)都對(duì)實(shí)際上它們考察的粒度完全不同。1.3 編程題的題型特點(diǎn)小紅書(shū)的筆試編程題難度屬于中上游不會(huì)出那種全場(chǎng)沒(méi)人做出來(lái)的壓軸怪題但也別指望送分。我遇到的題型大概是一道偏字符串/數(shù)組處理的題一道偏數(shù)據(jù)結(jié)構(gòu)鏈表或二叉樹(shù)的題再有一道可能是動(dòng)態(tài)規(guī)劃或貪心。很多同學(xué)容易犯的錯(cuò)是把編程題當(dāng)成LeetCode原題來(lái)背實(shí)際上筆試出的題會(huì)有很強(qiáng)的“業(yè)務(wù)包裝”。比如題干會(huì)寫(xiě)成“小紅書(shū)有n篇筆記每篇有發(fā)布時(shí)間和點(diǎn)贊數(shù)需要按某種規(guī)則排序”之類的場(chǎng)景去掉包裝之后核心還是排序或區(qū)間合并。讀題時(shí)先把業(yè)務(wù)詞匯剝掉抽成純數(shù)據(jù)結(jié)構(gòu)問(wèn)題思路會(huì)清晰很多。2. iOS核心考點(diǎn)深度拆解2.1 內(nèi)存管理從ARC到循環(huán)引用排查iOS筆試對(duì)內(nèi)存管理的考察非常細(xì)致不是問(wèn)“什么是ARC”這種概念題而是給你一段代碼讓你判斷某個(gè)對(duì)象什么時(shí)候釋放、引用計(jì)數(shù)是幾、會(huì)不會(huì)造成循環(huán)引用。先說(shuō)ARC。ARC是編譯器在編譯期自動(dòng)插入retain/release/autorelease的機(jī)制它不是一個(gè)運(yùn)行時(shí)垃圾回收器。這意味著編譯器必須能靜態(tài)分析出對(duì)象的持有關(guān)系分析不出來(lái)就會(huì)產(chǎn)生錯(cuò)誤或泄漏。屬性關(guān)鍵字里strong表示強(qiáng)持有weak表示弱持有且對(duì)象釋放后自動(dòng)置nilcopy會(huì)拷貝一份新對(duì)象assing對(duì)ObjC對(duì)象不安全對(duì)基本類型沒(méi)問(wèn)題。筆試?yán)镒畛？嫉难h(huán)引用場(chǎng)景有三個(gè)。第一個(gè)是block對(duì)象持有blockblock又捕獲了self就會(huì)形成self - block - self的環(huán)。解決辦法是用__weak __typeof(self) weakSelf self; 在block里再用strongSelf判空。第二個(gè)是delegatedelegate屬性要聲明為weak而不是strong否則兩個(gè)對(duì)象互相強(qiáng)持有就泄漏了。第三個(gè)是NSTimer或CADisplayLinktarget是self時(shí)timer會(huì)被runloop持有如果不invalidate就永遠(yuǎn)不釋放。我還記得有一道題是拿__weak和__unsafe_unretained做對(duì)比很多人會(huì)忽略后者。__unsafe_unretained也是弱引用但對(duì)象釋放后它不會(huì)自動(dòng)置nil變成野指針訪問(wèn)就會(huì)crash。筆試?yán)飭?wèn)“下列哪個(gè)關(guān)鍵字在對(duì)象釋放后會(huì)產(chǎn)生野指針”答案就是它。2.2 Runtime與消息機(jī)制理解動(dòng)態(tài)性的鑰匙R(shí)untime是iOS筆試的重頭戲。ObjC是一門(mén)動(dòng)態(tài)語(yǔ)言方法調(diào)用本質(zhì)上是給對(duì)象發(fā)送消息也就是objc_msgSend。消息發(fā)送的流程是先查對(duì)象的isa指針找到類對(duì)象再在類的method_list里找method找不到就去父類找直到根類再找不到就走消息轉(zhuǎn)發(fā)流程。筆試?？嫉囊粋€(gè)點(diǎn)是消息轉(zhuǎn)發(fā)的三個(gè)階段動(dòng)態(tài)方法解析resolveInstanceMethod、快速轉(zhuǎn)發(fā)forwardingTargetForSelector、完整轉(zhuǎn)發(fā)methodSignatureForSelector forwardInvocation。你可以把這個(gè)流程理解成一個(gè)員工找不到人處理任務(wù)先問(wèn)自己能不能現(xiàn)場(chǎng)學(xué)再問(wèn)有沒(méi)有同事能幫忙最后還要把一個(gè)完整任務(wù)包發(fā)給別人。問(wèn)你“哪個(gè)方法可以為類動(dòng)態(tài)添加方法實(shí)現(xiàn)”答案就是resolveInstanceMethod它內(nèi)部調(diào)class_addMethod。KVO的底層原理也是高頻題。KVO通過(guò)isa-swizzling動(dòng)態(tài)生成一個(gè)NSKVONotifying_XX子類重寫(xiě)被觀察屬性的setter方法在setter里調(diào)用willChangeValueForKey和didChangeValueForKey從而通知觀察者。所以一個(gè)對(duì)象被KVO之后它的isa指針其實(shí)已經(jīng)變了。考到“KVO為什么能生效”時(shí)答出這個(gè)派生類和isa-swizzling就夠一半了。Method Swizzling也是常客。它利用Runtime在運(yùn)行時(shí)交換兩個(gè)方法的IMP。要注意的是交換應(yīng)該在load方法里用dispatch_once包一層避免重復(fù)交換交換的是實(shí)例方法還是類方法要看獲取Method時(shí)傳的是class還是metaClass這些細(xì)節(jié)筆試經(jīng)常挖坑。另外現(xiàn)在主流做法是盡量避免Swizzling用它要有完整的降級(jí)方案畢竟它牽扯到全局所有實(shí)例出了問(wèn)題很難復(fù)盤(pán)。2.3 RunLoop、多線程與并發(fā)RunLoop是iOS開(kāi)發(fā)者每天打交道又容易說(shuō)不清的東西。RunLoop本質(zhì)是一個(gè)事件循環(huán)iOS的App啟動(dòng)后主線程就進(jìn)入一個(gè)runloop不停地接收觸摸事件、定時(shí)器事件、網(wǎng)絡(luò)事件空閑時(shí)就睡眠有事件就喚醒處理。筆試?yán)锍？糝unLoop的Source/Timer/Observer三種輸入源以及它和AutoreleasePool之間的關(guān)系。Source1是系統(tǒng)事件源觸摸事件就是通過(guò)Source1發(fā)到App的Source0是自定義事件源需要手動(dòng)喚醒線程Timer就是定時(shí)器。每次RunLoop循環(huán)結(jié)束時(shí)會(huì)自動(dòng)釋放當(dāng)前AutoreleasePool這也是為什么主線程創(chuàng)建臨時(shí)對(duì)象不會(huì)無(wú)限堆積內(nèi)存。GCD部分考得最頻繁的是隊(duì)列和死鎖。串行隊(duì)列、并發(fā)隊(duì)列、主隊(duì)列這些概念必考dispatch_sync和dispatch_async的區(qū)別也是送分題。真正容易錯(cuò)的是死鎖場(chǎng)景在主隊(duì)列上調(diào)用dispatch_sync(主隊(duì)列)就會(huì)死鎖因?yàn)橹麝?duì)列是串行隊(duì)列你在執(zhí)行當(dāng)前block的同時(shí)又向同一個(gè)串行隊(duì)列提交一個(gè)需要等待的空block兩個(gè)互相等待永遠(yuǎn)執(zhí)行不完。類似地在一個(gè)串行queue里再dispatch_sync到它自己也會(huì)死鎖。信號(hào)量dispatch_semaphore也值得復(fù)習(xí)它用來(lái)控制并發(fā)數(shù)量或做同步等待。筆試喜歡問(wèn)“semaphore初始值為NM個(gè)任務(wù)并發(fā)最多同時(shí)執(zhí)行幾個(gè)”。這個(gè)理解源碼就清楚了每次wait信號(hào)量減1為0時(shí)阻塞所以答案是N。還有dispatch_once保證block只執(zhí)行一次內(nèi)部也是用了信號(hào)量和原子操作。2.4 UI、系統(tǒng)框架與性能優(yōu)化UI這部分的筆試題目通常在考察你是否真的理解布局和渲染而不是只會(huì)在Xcode里拖控件。UIStackView、Auto Layout、frame/muBounds的區(qū)別、UIView和CALayer的關(guān)系這些都要能說(shuō)清楚。比如UIStackView在iOS 11以后有了很多改動(dòng)stackView會(huì)根據(jù)axis、spacing、distribution自動(dòng)管理子視圖約束但它并不會(huì)自動(dòng)解決所有布局問(wèn)題子視圖的intrinsic content size、壓縮阻力和抗拉伸優(yōu)先級(jí)都會(huì)影響最終效果。如果你不理解這些優(yōu)先級(jí)遇到stackView里文字被截?cái)嗟膯?wèn)題就沒(méi)法排查。性能優(yōu)化方面的考點(diǎn)更貼近小紅書(shū)這類業(yè)務(wù)。列表卡頓的常見(jiàn)原因包括cell的layout重復(fù)計(jì)算、圖片解碼在主線程、離屏渲染過(guò)多、混用的圖層合成開(kāi)銷過(guò)大。提高列表流暢度的常規(guī)手段有cell高度緩存、異步繪制、預(yù)排版、圖片尺寸壓縮、避免在cellForRow里做耗時(shí)操作。iOS 14開(kāi)始UICollectionView的prefetching機(jī)制也是一個(gè)考點(diǎn)。還有系統(tǒng)框架的細(xì)節(jié)題比如CoreBluetooth的CBCentralManager的系統(tǒng)級(jí)藍(lán)牙授權(quán)狀態(tài)和App內(nèi)藍(lán)牙開(kāi)關(guān)狀態(tài)是兩回事系統(tǒng)彈出授權(quán)彈窗后需要回調(diào)處理。iOS 13以后新增了CBManagerStateUnauthorized等狀態(tài)App要在狀態(tài)回調(diào)里統(tǒng)一處理。這類題表面上考藍(lán)牙實(shí)際是看你對(duì)系統(tǒng)API的狀態(tài)機(jī)有沒(méi)有完整認(rèn)知。電池優(yōu)化也偶爾出現(xiàn)在校招筆試?yán)铩Ｋ饕婕岸ㄎ痪冗x擇、后臺(tái)任務(wù)、推送方式和屏幕刷新率。很多人不知道iOS的省電模式會(huì)限制CPU頻率和網(wǎng)絡(luò)請(qǐng)求行為導(dǎo)致后臺(tái)任務(wù)表現(xiàn)不一致。這類題目一般不會(huì)很尖刻但你得能把優(yōu)化方向和系統(tǒng)機(jī)制對(duì)應(yīng)起來(lái)。3. 編程題實(shí)戰(zhàn)與解題策略3.1 高頻算法題型的解題框架小紅書(shū)筆試題的算法難度約等于LeetCode中等題。我把幾個(gè)高頻題型和對(duì)應(yīng)框架整理了一下這部分備考性價(jià)比最高。字符串和數(shù)組處理是每次筆試幾乎必出的。常見(jiàn)思路是雙指針、滑動(dòng)窗口、哈希計(jì)數(shù)、區(qū)間合并。比如“找出最長(zhǎng)不含重復(fù)字符的子串長(zhǎng)度”用滑動(dòng)窗口right指針不斷右移用哈希表記錄字符最后出現(xiàn)位置遇到重復(fù)時(shí)left跳到重復(fù)位置1過(guò)程中維護(hù)最大長(zhǎng)度。筆試如果出這類題寫(xiě)出維護(hù)左右指針的循環(huán)再確認(rèn)一下left取值邏輯基本就能過(guò)。鏈表題必背的是反轉(zhuǎn)鏈表。迭代法用pre、cur、next三個(gè)指針滾動(dòng)遞歸法的核心是先翻后面再讓后面節(jié)點(diǎn)的next指向前一個(gè)節(jié)點(diǎn)。這兩套代碼順手要能10分鐘內(nèi)寫(xiě)出來(lái)。二叉樹(shù)常考層序遍歷、前中后序遍歷、最近公共祖先、路徑和。層序遍歷用隊(duì)列做BFS每層循環(huán)前先拿到當(dāng)前隊(duì)列size就是這一層的節(jié)點(diǎn)數(shù)。這個(gè)模板在LeetCode 102里就是原題筆試時(shí)候直接套。動(dòng)態(tài)規(guī)劃和貪心對(duì)很多人來(lái)說(shuō)是瓶頸。要是備考時(shí)間緊優(yōu)先把背包問(wèn)題、最長(zhǎng)遞增子序列、最大子數(shù)組和這幾個(gè)經(jīng)典模型吃透。比如最大子數(shù)組和用Kadane算法遍歷時(shí)維護(hù)當(dāng)前累加和cur和全局最大和maxcur小于0就重置為0最后max就是答案。這類題一旦理解狀態(tài)轉(zhuǎn)移方程反而比鏈表題好寫(xiě)。3.2 筆試環(huán)境下的應(yīng)試技巧編程題在筆試環(huán)境里和在IDE里刷題完全是兩種體驗(yàn)。首先是用例輸入要自己處理。?？偷妮斎胧且恍谢蚨嘈心阋肗SString讀取整行再按空格拆分成數(shù)組寫(xiě)完業(yè)務(wù)邏輯后還要記得輸出換行。很多人因?yàn)檩斎虢馕鰧?xiě)錯(cuò)全題白做特別可惜。我的做題順序是先快速看全部編程題評(píng)估難度先把最有把握的寫(xiě)完再啃難題。每題先讀一遍示例理解輸入輸出格式。然后不管是暴力解法還是最優(yōu)解法先保證能跑通普通用例至少把部分分拿到再考慮優(yōu)化。筆試判題一般是按測(cè)試用例百分比算分只過(guò)一半用例也有分千萬(wàn)別在一道題上死磕到?jīng)]時(shí)間寫(xiě)別的。寫(xiě)代碼時(shí)養(yǎng)成好習(xí)慣變量命名清楚核心邏輯邊寫(xiě)邊注釋即使最終沒(méi)有AC面試官看你的代碼也會(huì)有一個(gè)好印象。有些公司筆試是系統(tǒng)自動(dòng)評(píng)分但小紅書(shū)這類注重工程化的團(tuán)隊(duì)在后續(xù)面試時(shí)可能會(huì)看到你的代碼代碼風(fēng)格不拉胯本身就是加分項(xiàng)。4. 備考路線與工具鏈準(zhǔn)備4.1 從基礎(chǔ)到專項(xiàng)的復(fù)習(xí)規(guī)劃針對(duì)小紅書(shū)這種筆試我把備考路線分成三個(gè)階段。第一個(gè)階段是補(bǔ)計(jì)算機(jī)基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)、算法、操作系統(tǒng)、網(wǎng)絡(luò)這四門(mén)課有一個(gè)相對(duì)薄弱的筆試就很難過(guò)這個(gè)階段大概兩到三周每天固定刷算法題并復(fù)習(xí)一個(gè)操作系統(tǒng)或網(wǎng)絡(luò)專題。第二個(gè)階段是iOS專項(xiàng)突破。把上面提到的內(nèi)存管理、Runtime、RunLoop、GCD、UI、網(wǎng)絡(luò)、存儲(chǔ)這些模塊逐個(gè)過(guò)一遍每個(gè)模塊不只是看文檔要寫(xiě)demo驗(yàn)證。比如你學(xué)weak原理就在Xcode里創(chuàng)建一個(gè)對(duì)象用__weak引用它再把它置nil觀察是不是自動(dòng)變成nil學(xué)KVO就自己寫(xiě)一個(gè)派生類實(shí)現(xiàn)setter看看不觸發(fā)KVO時(shí)手動(dòng)調(diào)用will/didChangeValueForKey能不能生效。知識(shí)只有親手驗(yàn)證過(guò)筆試遇到變體題才不容易慌。第三個(gè)階段是真題模擬和節(jié)奏訓(xùn)練。用?？途W(wǎng)的真題模擬環(huán)境做兩到三套題嚴(yán)格控制90分鐘模擬考場(chǎng)狀態(tài)。我建議把刷題和筆試平臺(tái)操作分開(kāi)練習(xí)代碼在本地寫(xiě)完再貼到平臺(tái)里也要跑一遍很多平臺(tái)對(duì)函數(shù)的調(diào)用方式有區(qū)別提前適應(yīng)能減少考場(chǎng)上的低級(jí)失誤。4.2 高效工具鏈模擬器、抓包與調(diào)試iOS開(kāi)發(fā)調(diào)試離不開(kāi)模擬器和真機(jī)。模擬器現(xiàn)在可以模擬不同的設(shè)備尺寸、系統(tǒng)版本還能模擬網(wǎng)絡(luò)狀態(tài)弱網(wǎng)場(chǎng)景筆試?yán)飭?wèn)到的很多系統(tǒng)行為差異都能在模擬器里驗(yàn)證。不過(guò)模擬器不能完全代表真機(jī)比如真實(shí)的內(nèi)存壓力、CPU調(diào)度、GPU渲染、傳感器行為都有差異所以備考時(shí)常備一臺(tái)真機(jī)很有必要。網(wǎng)絡(luò)調(diào)試用Charles比較多。它做HTTPS抓包時(shí)需要安裝并信任CA證書(shū)然后在手機(jī)上安裝描述文件并開(kāi)啟“允許完全信任”。這套流程里最容易踩的坑是證書(shū)裝好但系統(tǒng)版本升級(jí)后信任開(kāi)關(guān)被重置導(dǎo)致抓包看到一堆SSLHandshake錯(cuò)誤。如果你在備考階段要分析一個(gè)App的網(wǎng)絡(luò)請(qǐng)求用Charles輔助看請(qǐng)求頭、參數(shù)、響應(yīng)體能幫你更好地理解客戶端和服務(wù)端的交互邏輯。開(kāi)發(fā)和調(diào)試時(shí)要注意開(kāi)發(fā)者模式和證書(shū)的管理。iOS開(kāi)發(fā)者賬號(hào)續(xù)費(fèi)后證書(shū)需要更新描述文件要及時(shí)重新下載安裝否則Xcode會(huì)提示“The provisioning profile is expired”。校招筆試不直接考這個(gè)但實(shí)習(xí)面試和在線測(cè)試過(guò)程中可能需要你打包一個(gè)Demo給面試官看如果這一步卡住會(huì)很尷尬。提前把開(kāi)發(fā)者相關(guān)流程跑熟屬于那種“平時(shí)用不上、用上就救命”的技能。4.3 原生iOS與跨平臺(tái)技術(shù)的視野對(duì)比小紅書(shū)技術(shù)棧以原生為主所以筆試重點(diǎn)是原生iOS。但作為iOS開(kāi)發(fā)了解一些跨平臺(tái)方案是有必要的因?yàn)槟闳肼毢罂赡芤妥鯝ndroid、前端的同事協(xié)作也可能會(huì)接觸到混編業(yè)務(wù)。原生iOS和純跨平臺(tái)方案各有利弊。原生在系統(tǒng)API調(diào)用、性能、交互體驗(yàn)上優(yōu)勢(shì)明顯尤其是復(fù)雜的動(dòng)畫(huà)和大量圖片列表場(chǎng)景原生可以精確控制渲染細(xì)節(jié)?？缙脚_(tái)方案如Flutter、React Native、uni-app主打的是多端復(fù)用開(kāi)發(fā)效率高適合業(yè)務(wù)快速迭代但遇到系統(tǒng)級(jí)能力和疑難性能問(wèn)題還是得回到原生層去處理。筆試?yán)锶绻霈F(xiàn)“App需要同時(shí)支持iOS和Android你會(huì)怎么選型”這種開(kāi)放題你要能說(shuō)出來(lái)考慮團(tuán)隊(duì)能力、業(yè)務(wù)復(fù)雜度、性能要求和系統(tǒng)能力使用深度。Android和iOS開(kāi)發(fā)的區(qū)別也是面試官喜歡問(wèn)的。iOS內(nèi)存管理用ARCAndroid用Java/Kotlin的GCiOS的UI是UIKit的響應(yīng)鏈Android是View體系iOS后臺(tái)任務(wù)限制嚴(yán)格Android有大量Service和廣播機(jī)制。這類問(wèn)題不要求你精通Android但能講清本質(zhì)區(qū)別會(huì)讓面試官覺(jué)得你有對(duì)比思維和全局視野。5. 常見(jiàn)問(wèn)題與踩坑實(shí)錄5.1 筆試平臺(tái)操作最容易翻車的幾個(gè)點(diǎn)筆試平臺(tái)的操作失誤有時(shí)候比知識(shí)盲區(qū)更致命。我總結(jié)了幾條身邊同學(xué)真實(shí)遇到過(guò)的坑先寫(xiě)出來(lái)提醒大家。第一輸入輸出格式問(wèn)題。有些編程題要求輸出精確到小數(shù)點(diǎn)后兩位有些要求最后沒(méi)有多余空格這些細(xì)節(jié)不看清格式錯(cuò)了直接判錯(cuò)。寫(xiě)完之后一定自己構(gòu)造一兩組邊界用例測(cè)試比如空數(shù)組、只有一個(gè)元素、數(shù)值上限。第二攝像頭和屏幕共享異常?？荚嚽皺z查攝像頭是否被其他程序占用瀏覽器是否開(kāi)啟了多個(gè)標(biāo)簽頁(yè)關(guān)閉所有彈窗和通知插件。如果考試中途攝像頭斷掉系統(tǒng)可能會(huì)在后臺(tái)記錄異常標(biāo)記后續(xù)有可能被判定為作弊特別冤。第三網(wǎng)絡(luò)波動(dòng)導(dǎo)致代碼沒(méi)保存。?？途W(wǎng)的代碼編輯器會(huì)自動(dòng)保存但也有延遲別在最后五分鐘大改代碼提交前確認(rèn)代碼已經(jīng)在編輯框更新了。如果提交時(shí)間很緊張優(yōu)先保已通過(guò)用例的部分不要在最后時(shí)刻重構(gòu)。5.2 iOS知識(shí)點(diǎn)的易錯(cuò)易混對(duì)照筆試和面試?yán)镉泻芏鄆OS概念容易混淆我把它們整理成一張速查表。表格里這些點(diǎn)幾乎每年都有人錯(cuò)備考時(shí)候反復(fù)看幾遍能有效減少失分。易混概念核心區(qū)別筆試常見(jiàn)考法weak vs assign vs unsafe_unretainedweak自動(dòng)置nilassign通常用于基本類型unsafe_unretained不置nil會(huì)野指針選一個(gè)不安全的弱引用關(guān)鍵字synchronous vs asynchronoussync會(huì)阻塞當(dāng)前線程async不會(huì)判斷會(huì)不會(huì)死鎖frame vs boundsframe是相對(duì)父視圖坐標(biāo)bounds是相對(duì)自身坐標(biāo)旋轉(zhuǎn)后frame變化而bounds不變的場(chǎng)景深拷貝 vs 淺拷貝指針復(fù)制 vs 內(nèi)容復(fù)制判斷copy/mutableCopy結(jié)果isKindOfClass vs isMemberOfClass前者判斷是否屬于類或子類后者必須精確匹配給繼承關(guān)系判斷True/Falsestrong vs copycopy會(huì)復(fù)制一份新對(duì)象可避免可變對(duì)象被外部修改NSString屬性用copy的原因onViewDidLoad vs viewWillAppear vs viewDidAppear生命周期各階段的觸發(fā)時(shí)機(jī)和次數(shù)判斷某操作在哪個(gè)時(shí)機(jī)執(zhí)行堆 vs 棧堆需手動(dòng)/ARC管理?xiàng)Ｗ詣?dòng)管理全局變量、局部變量的存儲(chǔ)位置TCP vs UDPTCP可靠、面向連接UDP不可靠、無(wú)連接視頻通話為什么用UDP除了這些概念題筆試中還經(jīng)常給一段代碼讓你判斷輸出。比如“NSMutableArray *arr [NSMutableArray array]; arr nil; 會(huì)不會(huì)崩潰”答案是nil發(fā)消息在OC里是安全的不會(huì)崩潰。但如果是向野指針發(fā)送消息就會(huì)崩潰這兩者很容易搞混。再比如“__block int a 0; 在block里修改a能否生效”這是可以的但block被拷貝時(shí)a的存儲(chǔ)位置會(huì)從棧上搬到堆上所以用__block修飾的本質(zhì)是讓變量變成可以捕獲和修改。5.3 出分之后的復(fù)盤(pán)動(dòng)作筆試結(jié)束后別干等結(jié)果把做錯(cuò)的題和沒(méi)答上來(lái)的知識(shí)點(diǎn)復(fù)盤(pán)一遍。牛客網(wǎng)一般能查看每個(gè)測(cè)試用例的通過(guò)情況結(jié)合自己的記憶整理出一份錯(cuò)題集。這份錯(cuò)題集會(huì)在后面的面試中起到很大作用因?yàn)槿绻P試掛了簡(jiǎn)歷可能被鎖一段時(shí)間但如果筆試過(guò)了面試官大概率會(huì)看你的筆試答題情況你答得不好的題正好是面試時(shí)最可能被追問(wèn)的點(diǎn)。我個(gè)人的習(xí)慣是給每個(gè)考點(diǎn)建一個(gè)note文件里面寫(xiě)三列考點(diǎn)、我的理解、驗(yàn)證方式。比如寫(xiě)KVO的知識(shí)點(diǎn)就先寫(xiě)下底層原理再粘貼一段自己寫(xiě)的demo代碼再寫(xiě)“用instruments觀察對(duì)象isa變化”的驗(yàn)證步驟。這樣整理出來(lái)的筆記不是為了給別人看而是確保自己真的能復(fù)述和動(dòng)手驗(yàn)證。筆試前的最后一周我只看這份note不再去搜那些零散的文章金句。寫(xiě)在最后的一些個(gè)人體會(huì)回過(guò)頭來(lái)看這次2023秋招小紅書(shū)iOS開(kāi)發(fā)崗第一批筆試我最深的感觸是筆試考的不是你臨時(shí)背了多少面經(jīng)而是你長(zhǎng)期積累下來(lái)有沒(méi)有形成一套完整的知識(shí)網(wǎng)絡(luò)。iOS開(kāi)發(fā)的知識(shí)面很寬從語(yǔ)言底層到UI渲染從并發(fā)編程到網(wǎng)絡(luò)協(xié)議每一塊都像是拼圖缺少一塊面試和筆試遇到關(guān)聯(lián)問(wèn)題就會(huì)卡殼。我自己的做法是把iOS的知識(shí)體系按“語(yǔ)言基礎(chǔ)、內(nèi)存管理、Runtime/消息機(jī)制、RunLoop、多線程、UI、網(wǎng)絡(luò)、存儲(chǔ)、性能優(yōu)化、工程化”這十個(gè)模塊去拆每做一個(gè)模塊的知識(shí)點(diǎn)都會(huì)配套寫(xiě)一個(gè)幾行的小Demo跑一遍。筆試前每天再花半小時(shí)過(guò)一遍易錯(cuò)對(duì)照表比臨時(shí)刷題有效得多。最后分享一個(gè)小技巧遇到不會(huì)的筆試客觀題別亂猜先用排除法把明顯錯(cuò)誤的選項(xiàng)去掉再用“iOS系統(tǒng)實(shí)際行為”去反推哪個(gè)更合理。iOS很多機(jī)制是有內(nèi)在一致性的比如面向?qū)ο蟮睦^承決定了消息轉(zhuǎn)發(fā)會(huì)逐級(jí)找父類既然isa鏈?zhǔn)亲缘紫蛏系哪敲碖VO通過(guò)動(dòng)態(tài)子類來(lái)攔截setter也就順理成章了。掌握這種底層邏輯比記住一百個(gè)零散結(jié)論更能幫你穩(wěn)穩(wěn)拿分。