做小红书2020校招iOS方向笔试题卷三的时候我第一反应是这套卷子不适合考前突击。和很多公司直接甩出一堆“八股文流水账”不同卷三里的题目翻来覆去都在问一个问题——你平时敲代码的时候到底有没有想过它为什么这么写。考完我花了两周把卷子里每个知识点重新过了一遍整理出这份解析。对于正在准备校招的同学它是一张复习地图对于已经工作的iOS开发它更像一套自测题这些考点你还能拍着胸脯说全都会吗1. 考情速览这套卷子到底在考什么1.1 题型结构与考点分布先聊考情。据我印象整理卷三的题型大致分四块单选/多选、编程题、原理简答题、开放设计题。选择题考察的都是iOS日常开发绕不开的基础但绝对没有“白送分”的选项每个干扰项都有迷惑性编程题集中在数据结构和字符串处理难度不低但也不至于劝退原理题则围绕Runtime、内存管理、多线程这几个老生常谈的方向深挖光会背概念根本应付不了最后一道开放题很考验平时有没有真正做过项目因为答案没有标准只看你的表达和思路。考点分布我做了一个大致估算方便对症复习方向题型高频考点大致占比Objective-C语言基础单选/多选分类、属性修饰符、block、KVC/KVO25%iOS系统框架单选/简答Runtime、Runloop、多线程、内存管理30%数据结构与算法编程题LRU缓存、链表、树、字符串25%网络与存储单选/简答TCP三次握手、HTTPS、沙盒目录、持久化10%性能优化与架构简答/开放卡顿优化、图片加载方案10%这个配比透露了一个信息iOS校招笔试不再只考“你会不会用UIKit拖一个页面”而是把重点放在底层机制和工程决策上。尤其是Runtime和内存管理加起来占了近三成说明官方想招的不是只会调用API的“业务仔”而是遇到线上问题能独立排查的人。1.2 卷三传递的信号能力模型变了很多同学刷题时容易陷入一个误区觉得“把LeetCode刷够500题就能稳过笔试”。但卷三里真正卡人的往往不是纯算法题而是那些看起来很简单、实际非常容易答偏的OC语言题。举个典型的例子分类到底能不能添加实例变量如果只答“不能”基本拿不到分要说出“为什么不能、关联对象是什么、底层如何实现”才算过关。这道题背后想考察的是你有没有认真看过Objective-C的类结构是否知道编译期和运行期的职责划分。再比如多选里如果出现“下列哪些方式会引发循环引用”ABCD四个选项看起来都对但实际要对“NSTimer的target持有、block内直接使用self、delegate用strong修饰、GCD闭包持有self”做逐一辨析。这就是经验和基础的双重考验。整场做下来我的感受是这套卷子不是为了挑选“背得最熟的人”而是为了挑选“理解最深刻的人”。2. 算法与数据结构题不只考“会写”还考“为什么这么写”2.1 LRU缓存数据结构选型背后的工程逻辑卷三的编程题部分我印象最深的是手写LRU缓存。题目要求实现一个满足“最近最少使用”策略的缓存结构支持get和put并且要求时间复杂度为O(1)。LRU这个考点之所以高频是因为内容型App的图片缓存、内存缓存、数据库页缓存全都能用到这套机制。实现它的核心是“哈希表双向链表”哈希表负责O(1)的时间复杂度找到节点双向链表负责维护访问顺序。为什么不能用数组因为数组的插入和删除是O(n)链表改指针是O(1)。为什么不能只用链表因为查找节点需要遍历是O(n)。两者的结合是经典的空间换时间方案。我在整理代码时用Swift重新写了一个可运行的版本核心逻辑如下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) // 哨兵节点 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) } }代码本身不复杂但有几个细节特别容易在笔试时翻车。第一边界条件是容量为1此时head和tail相邻每一次moveToTail和remove都要保证指针不断。第二put一个已经存在的key时要先更新值再移动位置到尾部而不是简单丢弃。第三内存溢出时移除链表尾节点时一定要同步从字典中移除否则后面会越查越大。我认为这道题真正的得分点在于向面试官解释“为什么用双向链表而不是单向链表”。单向链表虽然也能维护顺序但当需要删除一个节点时必须知道它的前驱节点在O(1)要求下要么额外存储前驱指针要么把后继节点的值拷贝上来再删除后继节点操作非常别扭。双向链表直接让删除和移动都变成指针操作代码简洁且不容易出错。能把这个理由讲清楚比你默写出完整代码更能体现水平。2.2 字符串、链表与树高频题型的标配解法除了LRU卷三的算法题里还出现过字符串相关和二叉树相关的题目这些都属于校招笔试“标配”范围。字符串题里有一个经典版找出字符串中第一个不重复的字符。常规解法是两轮遍历第一轮用字典记录每个字符出现的次数第二轮从头扫描找到第一个计数为1的字符。这个题本身不难但要注意使用OC的NSString时遍历字符的方式会影响性能更推荐用unichar数组或者Swift的Character视图避免在循环里频繁进行字符串截取。还有边界条件要问清楚字符串为空返回什么没有不重复字符返回什么很多人在LeetCode上写惯了return -1但笔试平台可能要求返回\0或者nil题目没说清楚就默认用nil并注释说明。链表题里反转链表是“背了就能写”的题目但很多同学一紧张就丢边界。核心就是三指针迭代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 }关键是确认循环结束后prev才是新头节点而原来的head会成为新的尾节点它的next必须是nil。有些实现会在纸上推过程的时候漏掉这一步导致链表成环笔试平台会直接判超时或死循环。建议平时多练手写而不是只在IDE里跑通。二叉树题目里最近公共祖先LCA是高频中的高频。递归解法最直观从叶子往上找如果某个节点的左右子树分别包含了p和q那它就是公共祖先。这里有一个细节使用递归时要明确“边界条件是遇到nil或者说遇到了p或q本身”。很多深度优先的递归题起手式都是这几个判断模板感很强练熟了对笔试速度帮助很大。2.3 面试官真正想看的边界意识笔试算法题和日常刷题有一个微妙差别平台不会给你用例的详细解释只有输出对不对。所以“边界意识”就成了区分度最高的能力。卷三里不少题目看起来容易其实陷阱就藏在边界里。举一个链表题里常见的坑合并两个有序链表。很多同学写完主循环忘记处理“其中一个链表已经走到尾部”的情况导致结果少了一段。正确做法是在循环结束后把剩余的链表节点接上去。这个处理只要两行但遗漏了基本只能拿一半分数。另一个边界问题是空值处理。LRU的get对不存在的key返回什么字符串题里找不到目标字符返回什么二叉树的根节点是nil时怎么办这些看起来是细节但笔试平台是按用例给分的边界用例往往占比不低。我自己的习惯是写任何算法题先跟面试官或者自己在注释里确认三个问题——输入能否为空、输出类型是什么、极端值比如最大/最小整数是否特殊。这套习惯帮我避免了很多无谓的丢分。3. Objective-C语言底层分类、属性关键字和对象模型3.1 分类能不能加属性标准答案与关联对象卷三的选择题里有一道题几乎年年出现分类Category能否添加实例变量答案是不能但很多人会在这里栽跟头因为分类声明中使用property时编译器并不会报错只是不会自动生成_变量名和对应的getter/setter实现。根本原因在于实例变量的内存空间在类对象创建时就已经确定了而分类是运行时才被加载的它无法改变类已经分配好的内存布局所以分类只能添加方法不能直接添加实例变量。那如果开发中确实需要“给已有类添加一个带存储能力的属性”怎么办通用做法是关联对象。底层是objc_setAssociatedObject和objc_getAssociatedObject两个C函数通过一个全局的AssociationsManager哈希表来维护“对象地址关联key - 关联值”的关系。但要注意关联对象也并非完全没有成本它本质上是把存储挪到了类的内存结构之外不会自动释放依赖对象本身在dealloc时由runtime统一清理。笔试如果只答到这里大概能拿70%的分数。加分项是把“为什么不能”说清楚Objective-C的类和实例变量在编译期就完成了布局之后不能动态增加ivar否则会破坏所有已经创建实例的内存连续性。而关联对象相当于在类外挂了一张表用key关联value所以它可以“动态增加”但它不是真正的实例变量。能答出这层区别说明你不只是记住了结论而是理解了两套机制的底层差异。3.2 属性修饰符不是背出来的是用出来的属性修饰符是iOS开发的基础也是笔试卷子里的常客。卷三选择的干扰项特别喜欢把strong和copy混在一起考察你知不知道什么时候该用哪个。修饰符语义典型使用场景copy拷贝一个新对象不共享可变内容NSString、NSArray、Blockstrong持有引用引用计数1一般对象属性weak不持有引用释放后自动置nildelegate、Outletassign直接赋值不参与内存管理基础类型、CGFloat、NSInteger这里有两个高频知识点。第一为什么NSString要用copy修饰因为外部可能传进来一个NSMutableString如果你用strong持有它外部后续修改这个可变字符串你的属性内容也会跟着变化这是非常隐蔽的Bug。用copy就会生成一个不可变副本从此与外界无关。第二为什么Block属性要用copy因为在MRC时代Block默认存放在栈区离开作用域可能被回收copy将其拷贝到堆区保证属性在之后的任意时间点都能够安全调用。ARC下编译器在赋值时已经帮我们做了类似处理但保留copy依旧是约定俗成的规范写法。还要特别强调一个易错点assign修饰对象类型是不安全的如果被修饰的对象被释放assign属性会变成一个悬垂指针再次访问就会野指针崩溃。正确答案是对象类型用weak基础类型用assign。这个知识点在多选题里经常作为一个干扰项出现选错了整题扣分。3.3 isa指针从对象到元类的完整链路在OC对象模型相关题目里isa指针是绕不开的重点。这里有个容易混淆的细节早期的isa就是简单的Class指针后来为了效率优化变成了联合体isa_t里面除了类信息还会用位域存储引用计数、是否弱引用等状态。所以现在说“对象的isa指向它的类”在宏观上没问题但严格来说是“isa_t包含了类的信息”。完整链路是实例对象的isa指向类对象类对象的isa指向元类元类的isa指向根元类根元类的isa指向自己形成一个闭环。类对象的存储内容是实例方法列表、属性列表、协议列表元类里存储的是类方法列表。平时调用类方法时runtime是通过“类对象 - 元类”这条链来查找方法实现的。这块内容很容易被低估因为日常开发很少直接操作isa。但笔试如果考到“消息发送时实例方法从哪里找、类方法从哪里找”你就需要把这条链路画出来。建议把这张图在脑子里记清楚对象到类、类到元类、元类到根元类以及根元类的isa指向自身。这个模型理解了很多Runtime题都能豁然开朗。4. Runtime题消息机制才是iOS的“灵魂”4.1 一条消息从发送到找不到实现完整路径OC的方法调用本质上是消息发送这在卷三里几乎必考。题目通常会问你调用一个对象方法从开始到执行runtime做了什么完整路径要分几步讲。第一步检查目标对象是否为nil为nil时消息直接丢弃这也是为什么向nil发送消息不会崩溃。第二步根据对象的isa找到类对象先在方法的缓存cache_t里查找命中就直接执行。第三步缓存未命中则遍历类对象的方法列表还找不到就沿着superclass链往上找直到NSObject。第四步如果整个继承链都没有对应实现进入动态方法解析resolveInstanceMethod允许你动态给类添加方法。第五步如果动态解析也没处理就会走消息转发流程先问forwardingTargetForSelector有没有替身对象再问methodSignatureForSelector和forwardInvocation能否完整包一层转发。最后都不行就会调用doesNotRecognizeSelector抛出异常。笔试不会让你一字不差背出源码但会以选择题的形式考察向nil发送消息为什么不崩溃消息转发有哪几步resolveInstanceMethod在消息转发之前还是之后这些细节如果只停留在“听说过”的程度很容易选错。我的记忆方法是把它当作一个漏斗缓存找不到就去方法列表找方法列表找不到就去父类找父类找不到就给你最后的三次补救机会机会用完就崩。这样理解起来非常顺。4.2 方法交换的正确姿势与常见翻车点方法交换Method Swizzling是Runtime在工程中最常见的落地场景之一比如AOP打点、无侵入埋点、网络日志记录。卷三的简答题里有很大的概率考到而且会给一个场景“如何在不动业务代码的前提下统计所有UIViewController的viewDidAppear”标准思路是写一个UIViewController分类在load里交换viewDidLoad和swizzled_viewDidLoad。之所以在load里做是因为它是在类加载完成后立即调用的时机最早同时要用dispatch_once保证只交换一次避免多重加载时重复交换导致递归。正确的交换写法大致是 (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]; // 在这里插入埋点逻辑 NSLog(页面出现%, self); }这里有个特别容易翻车的点交换后swizzled_viewDidLoad的调用会在方法内部递归调用自己。因为内部的[self swizzled_viewDidLoad]在实际运行时由于IMP已经被交换执行的是原viewDidLoad的实现而外部的原始调用此时执行的是swizzled_viewDidLoad的实现。很多初学者在这里绕晕以为是死循环其实是正常的。真正危险的是在分类里对父类方法做交换或者交换非自身的方法这些操作容易破坏继承链的方法查找逻辑导致整个App行为异常。我在准备这类题时建议把重点放在“为什么用dispatch_once”“为什么在load而不是initialize”“交换后的IMP对应关系”三个问题上。面试官问得深一点也就是这三点。4.3 KVC/KVO底层是怎么实现的KVC和KVO也是校招笔试题中的常客经常以原理题出现。KVC即键值编码比如[obj setValue:xx forKey:name]。它的查找顺序有固定套路设置值时会先找setName:方法找不到再找_setName:还没有就看accessInstanceVariablesDirectly是否为YES是则依次查找_name、_isName、name、isName实例变量全部找不到最后调用setValue:forUndefinedKey:。取值时顺序反过来依次找getName:、name、isName、_name等。这套查找机制让KVC有了读写私有变量的能力比如通过valueForKey读取_xxx开头的成员变量。KVO则依赖动态生成子类。当你对一个对象添加观察者时runtime会动态创建一个新的子类并把对象的isa指针指向这个子类。这个子类重写了被观察属性的setter方法在设置值前后分别调用willChangeValueForKey:和didChangeValueForKey:从而触发回调。这也是为什么KVO默认只能监听属性变化而不能直接监听实例变量的赋值。一个隐藏的考点是手动触发KVO。如果你直接修改_name实例变量KVO默认不会被触发因为setter没有被调用。要做到手动触发需要自己在修改前后调用willChangeValueForKey:和didChangeValueForKey:。这个知识点在笔试里很少正面考但会导致一个很有意思的追问KVO只对属性有效对吗这时候你如果能回答“不对是只有通过setter修改才有效”印象分会高不少。5. 内存管理、并发与Runloop最容易丢分的组合拳5.1 循环引用的高发场景与修复内存管理相关的题目起手式往往是“一个对象持有blockblock里又用了self会造成循环引用吗”答案是会因为对象持有blockblock又会把外部变量捕获进去如果捕获的是self两者就形成了持有环谁都无法释放。卷三的多选题里这个考点被拆成了几个场景。第一个是block解决方法是__weak typeof(self) weakSelf self在block内部用weakSelf如果需要保证block执行期间self不被释放再在外面持有__strong局部变量。第二个是代理delegate如果用strong修饰就会造成持有环应该用weak。第三个是NSTimerNSTimer的target是强持有的如果控制器持有timertimer又强持有控制器就循环了iOS 10之后可以通过block方式创建timer并在dealloc中调用invalidate或者用一个中间代理对象破环。第四个是CADisplayLink它同样强持有target处理方式类似。这里我要特别强调NSTimer的坑即使你用了__weak typeof(self) weakSelf如果timer的target强持有控制器循环依然存在因为weakSelf只是block内部不持有而timer的target赋值本身就是强持有。所以解决NSTimer循环引用的关键是“不把self作为target”要么换成block方式要么通过一个代理对象转发。很多同学一看到block就条件反射写weakSelf结果在NSTimer这里反而丢分。5.2 weak到底是怎么做到自动置nil的弱引用weak的自动置nil机制是iOS内存管理里最值得深挖的问题之一笔试简答题出现频率很高。底层逻辑是这样runtime维护了一个全局的SideTables哈希表以对象地址为keyvalue是一个SideTable里面包含了该对象的引用计数表和弱引用表。当对对象添加weak引用时系统会把“weak指针的地址”注册进这个对象的弱引用表。当对象引用计数归零、执行dealloc时runtime会从哈希表中找到该对象对应的表把弱引用表里所有的指针全部置为nil再继续销毁对象。理解这套机制后有几个延伸考点为什么__weak变量在ARC下使用前要赋值给一个__strong变量因为从weak表取出对象到使用之间这个对象可能被其他线程释放赋值给strong变量可以保证在使用期间它不会被回收。这其实是很多并发崩溃的根源也是面试官用来区分“会写代码”和“懂原理”的高频问题。5.3 主队列同步任务为什么必死锁GCD的题卷三最常考的就是死锁。最经典的莫过于“在主线程/主队列上调用dispatch_sync代码会死锁吗”答案是会。原因在于主队列是一个串行队列dispatch_sync提交的任务必须等待之前所有任务执行完毕才能开始而当前正在执行的代码块本身就在主队列里它也在等待dispatch_sync完成然后才能继续后续逻辑。两个任务互相等待谁也走不了就死锁了。同样的情况也会发生在自己创建的串行队列中在队列A的任务里向队列A同步提交新任务也会死锁。这个概念对开发者的实际意义是UI刷新和耗时操作一定要通过dispatch_async切到不同队列不要在主线程里同步等结果。笔试如果出到GCD题还有一个高频变种dispatch_sync到一个并发队列会死锁吗答案是“不会立即死锁”因为并发队列可以同时执行多个任务同步提交的任务可以立刻被执行但依然不建议在业务代码里这么写因为没有必要阻塞当前线程。5.4 Runloop把“现象”变“原理”Runloop相关的题在卷三里占比不小出题方式往往是“为什么定时器在主线程滑动列表时不准了”或者“为什么performSelector:afterDelay:在子线程不执行”。Runloop本质是一个“不退出的事件循环”。它管理了多种输入源Source0手动事件、Source1系统事件、Timer定时器、Observer观察者每一种源发生就会触发对应的处理回调。iOS在滚动列表时主线程的Runloop会切换到UITracking模式这个模式下默认不处理普通模式下的Timer所以NSTimer就出现了延迟。解决办法是把Timer加入到CommonMode中或者用基于GCD的定时器。performSelector:afterDelay:底层也是基于Timer实现的它要求当前线程必须有一个处于运行状态的Runloop。子线程默认没有开启Runloop所以调用之后没有反应。如果坚持要用需要先[[NSRunLoop currentRunLoop] run]让子线程的Runloop跑起来。这道题很能检验一个人是否真的排查过线上问题因为它不是背概念能解决的必须动手踩过坑才能理解。6. 网络、存储与性能优化题看着基础实则大有文章6.1 三次握手和HTTPS的重点回答策略网络基础题在iOS校招笔试中很少缺席卷三的选择题和简答题都可能在TCP和HTTPS上做文章。TCP三次握手为什么必须是三次第一次SYN客户端告诉服务端“我要发送数据了”第二次SYNACK服务端告诉客户端“我收到了我也准备好了”第三次ACK客户端告诉服务端“我收到了你的确认”。如果只有两次握手服务端无法确认客户端是否收到了自己的SYNACK。举个例子如果客户端第一次的SYN因为网络阻塞被延迟客户端已经超时重发并建立了连接之后旧SYN才到达服务端服务端如果直接建立连接就会造成资源浪费。三次握手能同时确认双方的收发能力都正常这是它存在的根本原因。HTTPS相比HTTP多了一层TLS握手。重点在于先用非对称加密协商出对称密钥之后的数据传输用对称加密兼顾安全性和速度。如果追问证书就要提到CA数字证书的作用防止中间人攻击客户端通过信任链验证服务器证书的真实性。准备这部分时不需要把TLS的每一步状态机背下来但要能把“为什么用非对称对称混合”讲清楚。6.2 沙盒目录与持久化方案的选择逻辑iOS的沙盒机制是保障数据安全的基础也经常出现在选择题里。沙盒主要分四个目录目录作用注意点Documents存放用户生成的重要数据会被iCloud自动备份不能放缓存Library/Caches存放缓存文件系统可能自动清理需要自己管理Library/Preferences存放应用配置NSUserDefaults本质写在这里tmp临时文件随时可能被系统清理笔试时经常问“下载一个几十MB的图片缓存到哪个目录”。正确的方向是Library/Caches因为Documents会参与iCloud备份可能导致审核被拒tmp又随时可能被清理不适合长期使用。持久化方案的选择也是一道经典简答NSUserDefaults适合轻量级配置但性能差不能存大量数据plist读写简单适合小规模结构化数据SQLite适合大量结构化、需要复杂查询的数据CoreData是对象关系映射框架学习成本高但和内存模型结合更紧密大文件直接写入磁盘再由FileManager管理。回答这类题的关键不是说“哪个最好”而是根据数据量、读写频率和查询需求给出取舍。6.3 列表卡顿优化从表象答到本质性能优化题的面试官最反感的是只背了一堆优化名词却不知道每步优化解决的是什么问题。卷三里如果问“UITableView滑动卡顿你会怎么排查和优化”标准回答应该分成三层。第一层是主线程中避免耗时操作。图片的解码、JSON的解析、数据库的读取都不该放在主线程。第二层是减少主线程渲染工作量比如避免在cellForRowAtIndexPath中频繁创建新对象、通过prepareForReuse重用cell、避免给layer设置圆角并设置masksToBounds导致离屏渲染。第三层是提高帧率感知比如提前计算缓存cell高度避免每次布局时重复计算。更底层的方向包括避免视图层级过深、尽量使用不透明的背景色、减少阴影和混合图层。我记得笔试里有个很阴险的选项“把图片从磁盘读取放到主线程可以提高加载速度因为主线程内存访问更快。”这个选项是错的。任何IO都应该远离主线程因为主线程一卡UI就无法响应。能在这种细节上保持清醒说明你对“为什么优化”有真实体感而不是只背了“优化三板斧”。7. 开放设计题与考场策略7.1 设计一个图片加载库怎么组织答案卷三通常以一道开放设计题压轴比如“如果让你设计一个图片加载库你会怎么设计”。这种题没有唯一标准答案但想拿高分必须展示出你有工程架构思维。一个成熟的图片加载方案至少要包含三层。第一层是内存缓存推荐用NSCache而不是NSMutableDictionary因为NSCache自带自动清理策略内存吃紧时会自动腾出空间防止App被系统杀掉。第二层是磁盘缓存把图片文件写入Library/Caches用URL的MD5作为文件名下次启动时直接读磁盘。第三层是网络下载需要一个下载队列管理并发数避免同时请求过多造成带宽压力同一个URL的重复请求要合并下载完成的回调要切回主线程刷新UI。还有一个容易被忽略但非常重要的点图片解码。从磁盘读到UIImage后图片并不会立刻解码成位图而是在首次绘制时才进行解码如果这个解码发生在主线程就会卡顿。所以图片加载库的正确做法是在后台线程提前完成解码再在主线程赋值给UIImageView。能把这个点回答出来面试官会觉得你“真的处理过图片加载问题”因为这是SDWebImage和YYImage等开源库都会重点考虑的问题。另外开放题考察的是思路和表达不要只甩出几个名词就停笔。我建议按这个顺序组织答案缓存策略、线程模型、解码时机、回调方式、超时与失败处理、清理机制。就算没有完全实现过只要逻辑自洽阅卷人也会认为你有架构能力。7.2 时间分配与细节控分技巧最后聊聊考场策略。卷三整体题量不小选择题很容易磨时间建议控制在30分钟以内算法题留60分钟至少保证LRU这类大题的完整实现简答和开放题留30分钟分点作答优先写核心结论再补充细节。多选和不定项选择是丢分重灾区。我的经验是“宁缺毋滥”拿不准的选项不要选选对了不确定项不一定加分但选错了一定扣分。简答题尽量每一条单独起一行术语准确比如“方法交换”、“动态添加方法”、“弱引用表”这些关键词要清晰出现阅卷人一扫就能看到采分点。编程题如果写不出最优解也要先把暴力解写出来并通过测试不要留白。因为笔试平台的判定是“过多少用例给多少分”一个没有提交的代码即使思路再完美也是0分。做题顺序上优先做自己有把握的题把确定性得分先拿到手再去啃难题。如果让我总结这套卷子一句话就够了它不是考你会不会写iOS而是考你会不会像一个有经验的iOS工程师一样思考。刷题只是手段真正要反复问自己的是“为什么这个知识点长这样设计者当时在解决什么问题”。把这个问题想明白卷三的每一道题都会变成你知识体系里的一块拼图而不是一份需要死记的答案。 小红书iOS校招笔试题解析：从Runtime到内存管理的底层原理与实战
做小红书2020校招iOS方向笔试题卷三的时候我第一反应是这套卷子不适合考前突击。和很多公司直接甩出一堆“八股文流水账”不同卷三里的题目翻来覆去都在问一个问题——你平时敲代码的时候到底有没有想过它为什么这么写。考完我花了两周把卷子里每个知识点重新过了一遍整理出这份解析。对于正在准备校招的同学它是一张复习地图对于已经工作的iOS开发它更像一套自测题这些考点你还能拍着胸脯说全都会吗1. 考情速览这套卷子到底在考什么1.1 题型结构与考点分布先聊考情。据我印象整理卷三的题型大致分四块单选/多选、编程题、原理简答题、开放设计题。选择题考察的都是iOS日常开发绕不开的基础但绝对没有“白送分”的选项每个干扰项都有迷惑性编程题集中在数据结构和字符串处理难度不低但也不至于劝退原理题则围绕Runtime、内存管理、多线程这几个老生常谈的方向深挖光会背概念根本应付不了最后一道开放题很考验平时有没有真正做过项目因为答案没有标准只看你的表达和思路。考点分布我做了一个大致估算方便对症复习方向题型高频考点大致占比Objective-C语言基础单选/多选分类、属性修饰符、block、KVC/KVO25%iOS系统框架单选/简答Runtime、Runloop、多线程、内存管理30%数据结构与算法编程题LRU缓存、链表、树、字符串25%网络与存储单选/简答TCP三次握手、HTTPS、沙盒目录、持久化10%性能优化与架构简答/开放卡顿优化、图片加载方案10%这个配比透露了一个信息iOS校招笔试不再只考“你会不会用UIKit拖一个页面”而是把重点放在底层机制和工程决策上。尤其是Runtime和内存管理加起来占了近三成说明官方想招的不是只会调用API的“业务仔”而是遇到线上问题能独立排查的人。1.2 卷三传递的信号能力模型变了很多同学刷题时容易陷入一个误区觉得“把LeetCode刷够500题就能稳过笔试”。但卷三里真正卡人的往往不是纯算法题而是那些看起来很简单、实际非常容易答偏的OC语言题。举个典型的例子分类到底能不能添加实例变量如果只答“不能”基本拿不到分要说出“为什么不能、关联对象是什么、底层如何实现”才算过关。这道题背后想考察的是你有没有认真看过Objective-C的类结构是否知道编译期和运行期的职责划分。再比如多选里如果出现“下列哪些方式会引发循环引用”ABCD四个选项看起来都对但实际要对“NSTimer的target持有、block内直接使用self、delegate用strong修饰、GCD闭包持有self”做逐一辨析。这就是经验和基础的双重考验。整场做下来我的感受是这套卷子不是为了挑选“背得最熟的人”而是为了挑选“理解最深刻的人”。2. 算法与数据结构题不只考“会写”还考“为什么这么写”2.1 LRU缓存数据结构选型背后的工程逻辑卷三的编程题部分我印象最深的是手写LRU缓存。题目要求实现一个满足“最近最少使用”策略的缓存结构支持get和put并且要求时间复杂度为O(1)。LRU这个考点之所以高频是因为内容型App的图片缓存、内存缓存、数据库页缓存全都能用到这套机制。实现它的核心是“哈希表双向链表”哈希表负责O(1)的时间复杂度找到节点双向链表负责维护访问顺序。为什么不能用数组因为数组的插入和删除是O(n)链表改指针是O(1)。为什么不能只用链表因为查找节点需要遍历是O(n)。两者的结合是经典的空间换时间方案。我在整理代码时用Swift重新写了一个可运行的版本核心逻辑如下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) // 哨兵节点 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) } }代码本身不复杂但有几个细节特别容易在笔试时翻车。第一边界条件是容量为1此时head和tail相邻每一次moveToTail和remove都要保证指针不断。第二put一个已经存在的key时要先更新值再移动位置到尾部而不是简单丢弃。第三内存溢出时移除链表尾节点时一定要同步从字典中移除否则后面会越查越大。我认为这道题真正的得分点在于向面试官解释“为什么用双向链表而不是单向链表”。单向链表虽然也能维护顺序但当需要删除一个节点时必须知道它的前驱节点在O(1)要求下要么额外存储前驱指针要么把后继节点的值拷贝上来再删除后继节点操作非常别扭。双向链表直接让删除和移动都变成指针操作代码简洁且不容易出错。能把这个理由讲清楚比你默写出完整代码更能体现水平。2.2 字符串、链表与树高频题型的标配解法除了LRU卷三的算法题里还出现过字符串相关和二叉树相关的题目这些都属于校招笔试“标配”范围。字符串题里有一个经典版找出字符串中第一个不重复的字符。常规解法是两轮遍历第一轮用字典记录每个字符出现的次数第二轮从头扫描找到第一个计数为1的字符。这个题本身不难但要注意使用OC的NSString时遍历字符的方式会影响性能更推荐用unichar数组或者Swift的Character视图避免在循环里频繁进行字符串截取。还有边界条件要问清楚字符串为空返回什么没有不重复字符返回什么很多人在LeetCode上写惯了return -1但笔试平台可能要求返回\0或者nil题目没说清楚就默认用nil并注释说明。链表题里反转链表是“背了就能写”的题目但很多同学一紧张就丢边界。核心就是三指针迭代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 }关键是确认循环结束后prev才是新头节点而原来的head会成为新的尾节点它的next必须是nil。有些实现会在纸上推过程的时候漏掉这一步导致链表成环笔试平台会直接判超时或死循环。建议平时多练手写而不是只在IDE里跑通。二叉树题目里最近公共祖先LCA是高频中的高频。递归解法最直观从叶子往上找如果某个节点的左右子树分别包含了p和q那它就是公共祖先。这里有一个细节使用递归时要明确“边界条件是遇到nil或者说遇到了p或q本身”。很多深度优先的递归题起手式都是这几个判断模板感很强练熟了对笔试速度帮助很大。2.3 面试官真正想看的边界意识笔试算法题和日常刷题有一个微妙差别平台不会给你用例的详细解释只有输出对不对。所以“边界意识”就成了区分度最高的能力。卷三里不少题目看起来容易其实陷阱就藏在边界里。举一个链表题里常见的坑合并两个有序链表。很多同学写完主循环忘记处理“其中一个链表已经走到尾部”的情况导致结果少了一段。正确做法是在循环结束后把剩余的链表节点接上去。这个处理只要两行但遗漏了基本只能拿一半分数。另一个边界问题是空值处理。LRU的get对不存在的key返回什么字符串题里找不到目标字符返回什么二叉树的根节点是nil时怎么办这些看起来是细节但笔试平台是按用例给分的边界用例往往占比不低。我自己的习惯是写任何算法题先跟面试官或者自己在注释里确认三个问题——输入能否为空、输出类型是什么、极端值比如最大/最小整数是否特殊。这套习惯帮我避免了很多无谓的丢分。3. Objective-C语言底层分类、属性关键字和对象模型3.1 分类能不能加属性标准答案与关联对象卷三的选择题里有一道题几乎年年出现分类Category能否添加实例变量答案是不能但很多人会在这里栽跟头因为分类声明中使用property时编译器并不会报错只是不会自动生成_变量名和对应的getter/setter实现。根本原因在于实例变量的内存空间在类对象创建时就已经确定了而分类是运行时才被加载的它无法改变类已经分配好的内存布局所以分类只能添加方法不能直接添加实例变量。那如果开发中确实需要“给已有类添加一个带存储能力的属性”怎么办通用做法是关联对象。底层是objc_setAssociatedObject和objc_getAssociatedObject两个C函数通过一个全局的AssociationsManager哈希表来维护“对象地址关联key - 关联值”的关系。但要注意关联对象也并非完全没有成本它本质上是把存储挪到了类的内存结构之外不会自动释放依赖对象本身在dealloc时由runtime统一清理。笔试如果只答到这里大概能拿70%的分数。加分项是把“为什么不能”说清楚Objective-C的类和实例变量在编译期就完成了布局之后不能动态增加ivar否则会破坏所有已经创建实例的内存连续性。而关联对象相当于在类外挂了一张表用key关联value所以它可以“动态增加”但它不是真正的实例变量。能答出这层区别说明你不只是记住了结论而是理解了两套机制的底层差异。3.2 属性修饰符不是背出来的是用出来的属性修饰符是iOS开发的基础也是笔试卷子里的常客。卷三选择的干扰项特别喜欢把strong和copy混在一起考察你知不知道什么时候该用哪个。修饰符语义典型使用场景copy拷贝一个新对象不共享可变内容NSString、NSArray、Blockstrong持有引用引用计数1一般对象属性weak不持有引用释放后自动置nildelegate、Outletassign直接赋值不参与内存管理基础类型、CGFloat、NSInteger这里有两个高频知识点。第一为什么NSString要用copy修饰因为外部可能传进来一个NSMutableString如果你用strong持有它外部后续修改这个可变字符串你的属性内容也会跟着变化这是非常隐蔽的Bug。用copy就会生成一个不可变副本从此与外界无关。第二为什么Block属性要用copy因为在MRC时代Block默认存放在栈区离开作用域可能被回收copy将其拷贝到堆区保证属性在之后的任意时间点都能够安全调用。ARC下编译器在赋值时已经帮我们做了类似处理但保留copy依旧是约定俗成的规范写法。还要特别强调一个易错点assign修饰对象类型是不安全的如果被修饰的对象被释放assign属性会变成一个悬垂指针再次访问就会野指针崩溃。正确答案是对象类型用weak基础类型用assign。这个知识点在多选题里经常作为一个干扰项出现选错了整题扣分。3.3 isa指针从对象到元类的完整链路在OC对象模型相关题目里isa指针是绕不开的重点。这里有个容易混淆的细节早期的isa就是简单的Class指针后来为了效率优化变成了联合体isa_t里面除了类信息还会用位域存储引用计数、是否弱引用等状态。所以现在说“对象的isa指向它的类”在宏观上没问题但严格来说是“isa_t包含了类的信息”。完整链路是实例对象的isa指向类对象类对象的isa指向元类元类的isa指向根元类根元类的isa指向自己形成一个闭环。类对象的存储内容是实例方法列表、属性列表、协议列表元类里存储的是类方法列表。平时调用类方法时runtime是通过“类对象 - 元类”这条链来查找方法实现的。这块内容很容易被低估因为日常开发很少直接操作isa。但笔试如果考到“消息发送时实例方法从哪里找、类方法从哪里找”你就需要把这条链路画出来。建议把这张图在脑子里记清楚对象到类、类到元类、元类到根元类以及根元类的isa指向自身。这个模型理解了很多Runtime题都能豁然开朗。4. Runtime题消息机制才是iOS的“灵魂”4.1 一条消息从发送到找不到实现完整路径OC的方法调用本质上是消息发送这在卷三里几乎必考。题目通常会问你调用一个对象方法从开始到执行runtime做了什么完整路径要分几步讲。第一步检查目标对象是否为nil为nil时消息直接丢弃这也是为什么向nil发送消息不会崩溃。第二步根据对象的isa找到类对象先在方法的缓存cache_t里查找命中就直接执行。第三步缓存未命中则遍历类对象的方法列表还找不到就沿着superclass链往上找直到NSObject。第四步如果整个继承链都没有对应实现进入动态方法解析resolveInstanceMethod允许你动态给类添加方法。第五步如果动态解析也没处理就会走消息转发流程先问forwardingTargetForSelector有没有替身对象再问methodSignatureForSelector和forwardInvocation能否完整包一层转发。最后都不行就会调用doesNotRecognizeSelector抛出异常。笔试不会让你一字不差背出源码但会以选择题的形式考察向nil发送消息为什么不崩溃消息转发有哪几步resolveInstanceMethod在消息转发之前还是之后这些细节如果只停留在“听说过”的程度很容易选错。我的记忆方法是把它当作一个漏斗缓存找不到就去方法列表找方法列表找不到就去父类找父类找不到就给你最后的三次补救机会机会用完就崩。这样理解起来非常顺。4.2 方法交换的正确姿势与常见翻车点方法交换Method Swizzling是Runtime在工程中最常见的落地场景之一比如AOP打点、无侵入埋点、网络日志记录。卷三的简答题里有很大的概率考到而且会给一个场景“如何在不动业务代码的前提下统计所有UIViewController的viewDidAppear”标准思路是写一个UIViewController分类在load里交换viewDidLoad和swizzled_viewDidLoad。之所以在load里做是因为它是在类加载完成后立即调用的时机最早同时要用dispatch_once保证只交换一次避免多重加载时重复交换导致递归。正确的交换写法大致是 (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]; // 在这里插入埋点逻辑 NSLog(页面出现%, self); }这里有个特别容易翻车的点交换后swizzled_viewDidLoad的调用会在方法内部递归调用自己。因为内部的[self swizzled_viewDidLoad]在实际运行时由于IMP已经被交换执行的是原viewDidLoad的实现而外部的原始调用此时执行的是swizzled_viewDidLoad的实现。很多初学者在这里绕晕以为是死循环其实是正常的。真正危险的是在分类里对父类方法做交换或者交换非自身的方法这些操作容易破坏继承链的方法查找逻辑导致整个App行为异常。我在准备这类题时建议把重点放在“为什么用dispatch_once”“为什么在load而不是initialize”“交换后的IMP对应关系”三个问题上。面试官问得深一点也就是这三点。4.3 KVC/KVO底层是怎么实现的KVC和KVO也是校招笔试题中的常客经常以原理题出现。KVC即键值编码比如[obj setValue:xx forKey:name]。它的查找顺序有固定套路设置值时会先找setName:方法找不到再找_setName:还没有就看accessInstanceVariablesDirectly是否为YES是则依次查找_name、_isName、name、isName实例变量全部找不到最后调用setValue:forUndefinedKey:。取值时顺序反过来依次找getName:、name、isName、_name等。这套查找机制让KVC有了读写私有变量的能力比如通过valueForKey读取_xxx开头的成员变量。KVO则依赖动态生成子类。当你对一个对象添加观察者时runtime会动态创建一个新的子类并把对象的isa指针指向这个子类。这个子类重写了被观察属性的setter方法在设置值前后分别调用willChangeValueForKey:和didChangeValueForKey:从而触发回调。这也是为什么KVO默认只能监听属性变化而不能直接监听实例变量的赋值。一个隐藏的考点是手动触发KVO。如果你直接修改_name实例变量KVO默认不会被触发因为setter没有被调用。要做到手动触发需要自己在修改前后调用willChangeValueForKey:和didChangeValueForKey:。这个知识点在笔试里很少正面考但会导致一个很有意思的追问KVO只对属性有效对吗这时候你如果能回答“不对是只有通过setter修改才有效”印象分会高不少。5. 内存管理、并发与Runloop最容易丢分的组合拳5.1 循环引用的高发场景与修复内存管理相关的题目起手式往往是“一个对象持有blockblock里又用了self会造成循环引用吗”答案是会因为对象持有blockblock又会把外部变量捕获进去如果捕获的是self两者就形成了持有环谁都无法释放。卷三的多选题里这个考点被拆成了几个场景。第一个是block解决方法是__weak typeof(self) weakSelf self在block内部用weakSelf如果需要保证block执行期间self不被释放再在外面持有__strong局部变量。第二个是代理delegate如果用strong修饰就会造成持有环应该用weak。第三个是NSTimerNSTimer的target是强持有的如果控制器持有timertimer又强持有控制器就循环了iOS 10之后可以通过block方式创建timer并在dealloc中调用invalidate或者用一个中间代理对象破环。第四个是CADisplayLink它同样强持有target处理方式类似。这里我要特别强调NSTimer的坑即使你用了__weak typeof(self) weakSelf如果timer的target强持有控制器循环依然存在因为weakSelf只是block内部不持有而timer的target赋值本身就是强持有。所以解决NSTimer循环引用的关键是“不把self作为target”要么换成block方式要么通过一个代理对象转发。很多同学一看到block就条件反射写weakSelf结果在NSTimer这里反而丢分。5.2 weak到底是怎么做到自动置nil的弱引用weak的自动置nil机制是iOS内存管理里最值得深挖的问题之一笔试简答题出现频率很高。底层逻辑是这样runtime维护了一个全局的SideTables哈希表以对象地址为keyvalue是一个SideTable里面包含了该对象的引用计数表和弱引用表。当对对象添加weak引用时系统会把“weak指针的地址”注册进这个对象的弱引用表。当对象引用计数归零、执行dealloc时runtime会从哈希表中找到该对象对应的表把弱引用表里所有的指针全部置为nil再继续销毁对象。理解这套机制后有几个延伸考点为什么__weak变量在ARC下使用前要赋值给一个__strong变量因为从weak表取出对象到使用之间这个对象可能被其他线程释放赋值给strong变量可以保证在使用期间它不会被回收。这其实是很多并发崩溃的根源也是面试官用来区分“会写代码”和“懂原理”的高频问题。5.3 主队列同步任务为什么必死锁GCD的题卷三最常考的就是死锁。最经典的莫过于“在主线程/主队列上调用dispatch_sync代码会死锁吗”答案是会。原因在于主队列是一个串行队列dispatch_sync提交的任务必须等待之前所有任务执行完毕才能开始而当前正在执行的代码块本身就在主队列里它也在等待dispatch_sync完成然后才能继续后续逻辑。两个任务互相等待谁也走不了就死锁了。同样的情况也会发生在自己创建的串行队列中在队列A的任务里向队列A同步提交新任务也会死锁。这个概念对开发者的实际意义是UI刷新和耗时操作一定要通过dispatch_async切到不同队列不要在主线程里同步等结果。笔试如果出到GCD题还有一个高频变种dispatch_sync到一个并发队列会死锁吗答案是“不会立即死锁”因为并发队列可以同时执行多个任务同步提交的任务可以立刻被执行但依然不建议在业务代码里这么写因为没有必要阻塞当前线程。5.4 Runloop把“现象”变“原理”Runloop相关的题在卷三里占比不小出题方式往往是“为什么定时器在主线程滑动列表时不准了”或者“为什么performSelector:afterDelay:在子线程不执行”。Runloop本质是一个“不退出的事件循环”。它管理了多种输入源Source0手动事件、Source1系统事件、Timer定时器、Observer观察者每一种源发生就会触发对应的处理回调。iOS在滚动列表时主线程的Runloop会切换到UITracking模式这个模式下默认不处理普通模式下的Timer所以NSTimer就出现了延迟。解决办法是把Timer加入到CommonMode中或者用基于GCD的定时器。performSelector:afterDelay:底层也是基于Timer实现的它要求当前线程必须有一个处于运行状态的Runloop。子线程默认没有开启Runloop所以调用之后没有反应。如果坚持要用需要先[[NSRunLoop currentRunLoop] run]让子线程的Runloop跑起来。这道题很能检验一个人是否真的排查过线上问题因为它不是背概念能解决的必须动手踩过坑才能理解。6. 网络、存储与性能优化题看着基础实则大有文章6.1 三次握手和HTTPS的重点回答策略网络基础题在iOS校招笔试中很少缺席卷三的选择题和简答题都可能在TCP和HTTPS上做文章。TCP三次握手为什么必须是三次第一次SYN客户端告诉服务端“我要发送数据了”第二次SYNACK服务端告诉客户端“我收到了我也准备好了”第三次ACK客户端告诉服务端“我收到了你的确认”。如果只有两次握手服务端无法确认客户端是否收到了自己的SYNACK。举个例子如果客户端第一次的SYN因为网络阻塞被延迟客户端已经超时重发并建立了连接之后旧SYN才到达服务端服务端如果直接建立连接就会造成资源浪费。三次握手能同时确认双方的收发能力都正常这是它存在的根本原因。HTTPS相比HTTP多了一层TLS握手。重点在于先用非对称加密协商出对称密钥之后的数据传输用对称加密兼顾安全性和速度。如果追问证书就要提到CA数字证书的作用防止中间人攻击客户端通过信任链验证服务器证书的真实性。准备这部分时不需要把TLS的每一步状态机背下来但要能把“为什么用非对称对称混合”讲清楚。6.2 沙盒目录与持久化方案的选择逻辑iOS的沙盒机制是保障数据安全的基础也经常出现在选择题里。沙盒主要分四个目录目录作用注意点Documents存放用户生成的重要数据会被iCloud自动备份不能放缓存Library/Caches存放缓存文件系统可能自动清理需要自己管理Library/Preferences存放应用配置NSUserDefaults本质写在这里tmp临时文件随时可能被系统清理笔试时经常问“下载一个几十MB的图片缓存到哪个目录”。正确的方向是Library/Caches因为Documents会参与iCloud备份可能导致审核被拒tmp又随时可能被清理不适合长期使用。持久化方案的选择也是一道经典简答NSUserDefaults适合轻量级配置但性能差不能存大量数据plist读写简单适合小规模结构化数据SQLite适合大量结构化、需要复杂查询的数据CoreData是对象关系映射框架学习成本高但和内存模型结合更紧密大文件直接写入磁盘再由FileManager管理。回答这类题的关键不是说“哪个最好”而是根据数据量、读写频率和查询需求给出取舍。6.3 列表卡顿优化从表象答到本质性能优化题的面试官最反感的是只背了一堆优化名词却不知道每步优化解决的是什么问题。卷三里如果问“UITableView滑动卡顿你会怎么排查和优化”标准回答应该分成三层。第一层是主线程中避免耗时操作。图片的解码、JSON的解析、数据库的读取都不该放在主线程。第二层是减少主线程渲染工作量比如避免在cellForRowAtIndexPath中频繁创建新对象、通过prepareForReuse重用cell、避免给layer设置圆角并设置masksToBounds导致离屏渲染。第三层是提高帧率感知比如提前计算缓存cell高度避免每次布局时重复计算。更底层的方向包括避免视图层级过深、尽量使用不透明的背景色、减少阴影和混合图层。我记得笔试里有个很阴险的选项“把图片从磁盘读取放到主线程可以提高加载速度因为主线程内存访问更快。”这个选项是错的。任何IO都应该远离主线程因为主线程一卡UI就无法响应。能在这种细节上保持清醒说明你对“为什么优化”有真实体感而不是只背了“优化三板斧”。7. 开放设计题与考场策略7.1 设计一个图片加载库怎么组织答案卷三通常以一道开放设计题压轴比如“如果让你设计一个图片加载库你会怎么设计”。这种题没有唯一标准答案但想拿高分必须展示出你有工程架构思维。一个成熟的图片加载方案至少要包含三层。第一层是内存缓存推荐用NSCache而不是NSMutableDictionary因为NSCache自带自动清理策略内存吃紧时会自动腾出空间防止App被系统杀掉。第二层是磁盘缓存把图片文件写入Library/Caches用URL的MD5作为文件名下次启动时直接读磁盘。第三层是网络下载需要一个下载队列管理并发数避免同时请求过多造成带宽压力同一个URL的重复请求要合并下载完成的回调要切回主线程刷新UI。还有一个容易被忽略但非常重要的点图片解码。从磁盘读到UIImage后图片并不会立刻解码成位图而是在首次绘制时才进行解码如果这个解码发生在主线程就会卡顿。所以图片加载库的正确做法是在后台线程提前完成解码再在主线程赋值给UIImageView。能把这个点回答出来面试官会觉得你“真的处理过图片加载问题”因为这是SDWebImage和YYImage等开源库都会重点考虑的问题。另外开放题考察的是思路和表达不要只甩出几个名词就停笔。我建议按这个顺序组织答案缓存策略、线程模型、解码时机、回调方式、超时与失败处理、清理机制。就算没有完全实现过只要逻辑自洽阅卷人也会认为你有架构能力。7.2 时间分配与细节控分技巧最后聊聊考场策略。卷三整体题量不小选择题很容易磨时间建议控制在30分钟以内算法题留60分钟至少保证LRU这类大题的完整实现简答和开放题留30分钟分点作答优先写核心结论再补充细节。多选和不定项选择是丢分重灾区。我的经验是“宁缺毋滥”拿不准的选项不要选选对了不确定项不一定加分但选错了一定扣分。简答题尽量每一条单独起一行术语准确比如“方法交换”、“动态添加方法”、“弱引用表”这些关键词要清晰出现阅卷人一扫就能看到采分点。编程题如果写不出最优解也要先把暴力解写出来并通过测试不要留白。因为笔试平台的判定是“过多少用例给多少分”一个没有提交的代码即使思路再完美也是0分。做题顺序上优先做自己有把握的题把确定性得分先拿到手再去啃难题。如果让我总结这套卷子一句话就够了它不是考你会不会写iOS而是考你会不会像一个有经验的iOS工程师一样思考。刷题只是手段真正要反复问自己的是“为什么这个知识点长这样设计者当时在解决什么问题”。把这个问题想明白卷三的每一道题都会变成你知识体系里的一块拼图而不是一份需要死记的答案。