先说明一下这个栏目我确实持续在更新。市面上讲iOS面试题的资料很多但大多是一份题单甩给你背完照样挂。原因很简单面试官早就不满足于听你背概念了他们要的是你能在什么场景下用出这个知识点的证据。这篇文章我会把iOS面试的备考逻辑拆开揉碎不讲虚的。你会看到面试官提问时的潜台词、高频考点背后的原理链条、以及项目经历怎么讲才能扛住追问。无论你是准备社招还是校招只要把这里面的思路吃透比闷头刷两百道题有用得多。1. iOS面试的底层逻辑先搞清楚面试官在考什么很多人备考有一个误区上来就背什么是Runtime什么是RunLoop把面试当成知识问答。实际上一场技术面试通常有三个递进层次基础扎实度、项目真实度、思维深度。前两个决定了你过不过第三个决定了你能不能拿高评级。1.1 面试官不会写在JD里的考点分布以我面过的人和我自己被面的经验来看不管公司大小、不论几轮面试iOS岗位的考点大概呈现这样的分布状态语言与Runtime方向OC / Swift占基础面30%左右。考察内存管理、消息传递、指针/引用、泛型与协议等。并发与UI方向占30%左右。考察RunLoop、GCD、线程锁、卡顿优化、离屏渲染等。架构与工程化方向占20%左右。考察组件化、MVVM/MVC、模块通信、依赖管理、包体积治理等。系统底层交叉方向占20%左右。考察App启动流程、dyld加载、Mach-O结构、二进制重排等。这里有个关键认知考点不是平均分配的。你去看任何一家公司的iOS面经底层机制类问题出现的概率远远高于业务类问题。原因是业务具有偶然性而底层机制是通用能力。一个候选人能不能把API用得很熟和能把原理讲清楚完全区分开面试官第一轮就能判断出来。1.2 为什么背答案会成为简历减分项我遇到过一个候选人问weak的实现原理他答得飞快是维护了一个SideTablerelease时查找弱引用表把指针置成nil调用objc_loadWeak和objc_storeWeak…… 一字不差像从标准答案库里拉出来的一样。然后我追问了一句如果多个线程同时持有同一个weak对象释放时会发生什么需要加锁吗 他直接沉默了。这暴露了两个问题第一他从没写过一个对象在多线程环境下的释放场景脑子里没有并发这个维度第二他背的答案来自某篇博客而不是来自源码或实际调试。面试官不是反对你知道答案而是反对你只知道答案。真正有价值的回答方式是——原理是什么我在什么场景下用到了它坑在哪。哪怕你只说得出其中两项面试官都会觉得你是真的做过而不是来应试的。2. 高频必考机制的实战拆解从背概念到能讲原理这部分我把面试中几乎必问的几个主题拎出来给你一套原理场景追问的拆解思路。你不妨按照这个模板去整理自己的答案。2.1 Runtime的消息发送与转发不只是背isa和SEL先解决基础问题。Runtime的面试题基本围绕这几个关键词isa指针、类对象与元类对象、cache_t、消息发送、消息转发、method swizzling、associated object。很多人的回答链条是这样的——对象调用方法时编译成objc_msgSend(receiver, selector)然后通过isa找到类对象查method_list找不到就往父类找直到NSObject还找不到就进入消息转发。这个主线是对的但几乎所有人都漏了一个关键细节objc_msgSend的查找是经过汇编层优化的并不是每一步都走一遍完整的面向对象查询流程。面试官想听的细节是查找方法会先查类的cache_tCache Hit直接跳到函数地址Cache Miss才走方法列表线性查找或二分查找如果走到了父类还要处理super_class跳转。整个过程还涉及_objc_msgForward的跳转路径。再往后就是消息转发三部曲——resolveInstanceMethod-forwardingTargetForSelector-methodSignatureForSelectorforwardInvocation。但面试官深挖时通常会问两个实战问题动态添加方法你实际用过吗如果只答把方法添加到class_addMethod说得过去但不加分。能加分的答案是在网络层做防崩溃处理时对无法识别的selector动态生成一个空实现让Crash率下降了多少。消息转发为什么设计成三次机会这是很多人没想过的问题。三次机会的意义在于把解决问题的粒度从类动态方法解析到对象快速转发再到完整消息上下文完整转发逐级放大让不同层级的对象各自处理自己能力范围内的事。你能把这个设计动机讲出来面试官会认为你真有架构思维。2.2 RunLoop面试题里最值得深挖的是状态迁移RunLoop是OC和iOS开发中的高频考察点几乎每个面经都会出现。基础的版本问你RunLoop有几种模式source0、source1、timer、observer分别是什么。这些背一背没什么问题。但真正拉开分差的是围绕状态迁移展开的追问。比如面试官会问当一个timer在RunLoop中注册后执行中发生了用户拖动操作会发生什么答案是RunLoop会从当前Mode切换到UITrackingRunLoopMode默认模式下注册的timer会暂停。所以滚动页面时定时器失效、卡顿、不回调原因就是Mode切换。再比如为什么performSelector:afterDelay:在子线程不生效这背后的机制是该方法依赖RunLoop的timer端口而子线程默认不开启RunLoop。你在子线程中调用它timer根本没有被添加到任何Mode上自然没有回调。破解办法是在子线程中手动[[NSRunLoop currentRunLoop] run]或者改用GCD的dispatch_after。这里我要特别强调一点不要只背结论要能画出RunLoop的一次循环流程。RunLoop每一次循环是这样一个闭环进入休眠前先观察是否有需要处理的事件没有事件则进入等待等待时通过mach_msg监听端口消息一旦有事件到达就唤醒处理事件并分发到对应的Source / Timer / Observer循环结束重新进入下一次。Observer回调又分为BeforeWaiting和AfterWaiting卡顿检测就是在这两个节点之间计算时间差的。有了这条链路你再回答如何监控App卡顿就会顺理成章注册RunLoopObserver监听BeforeWaiting状态和AfterWaiting状态间隔超过阈值就记录当前主线程的调用栈。这就是很多开源的卡顿监控组件的核心思路。2.3 内存管理考察的从来不只是ARC和MRC的区别内存管理的面经题基本绕不开三个层面ARC规则、weak/strong/unsafe_unretained区别、循环引用。ARC层面你需要能说清楚引用计数是什么时候1、什么时候-1的。这里有一个很容易被忽略的点OC对象的引用计数操作在Runtime层面是通过retain和release实现的但编译器不一定每次都调用它们。因为存在一个优化——如果对象在编译期间可以明确生命周期ARC可能直接省略retain/release。这也是为什么你能在Release模式下看到更小的二进制、更快的执行速度。弱引用层面weak的原理一定要讲到位。核心是引用计数的存储机制每个对象对应一个SideTable里面有自旋锁、引用计数和weak_table。weak修饰的对象被释放时会自动置为nil。这类问题真正拉开差距的是追问weak变量在ObjC和Objective-C中存储变化的区别是怎样的答在runtime源码中weak变量是一个objc_object **指针释放时会调用objc_destroyWeak最终把指针置空。这个点背过源码的人都能答出来。Arc和MRc时代weak能否解决所有循环引用当然不能Block里捕获了局部变量还是可能持有外层对象delegate你要确认是否weak。循环引用的考察更贴近实战。最常见的场景是Block持有self、delegate没有用weak、NSTimer对target强持有。我建议在准备这类题时不要只举经典的Block例子而是准备一个我自己在项目里踩过的循环引用案例。面试官通常不满足于你背出一条定律他们更想听到你如何定位这个问题的过程——用什么工具查出的Leaks / Malloc Stack / Debug Memory Graph、复现路径是什么、修复方案是什么。只要你能完整讲出这段排查链路这道题基本就满分了。2.4 多线程和锁死锁题答得好线程安全题答得深GCD和多线程几乎是iOS面试的必考区。基础问题包括sync和async的区别。queue的串行/并发、主队列/全局队列。dispatch_group、semaphore、barrier的用途。死锁的产生条件。其中最有区分度的是死锁分析题。我见过一个经典题目在主队列执行dispatch_sync(dispatch_get_main_queue(), ^{})会发生什么。答案是主线程在等待这个block执行而主队列的任务排队等待主线程互相等待死锁。很多人第一次听到都会觉得玄但只要理解了sync是提交到指定队列并阻塞当前线程等待任务完成这一句这道题就没有悬念。线程安全方面真正拿高分不是背锁有几种而是能解释锁的适用场景和开销成本。给你一个表格可以辅助记忆不同锁在面试中的关键表述锁类型适用场景注意点synchronized简单原子性保护底层走objc_sync_enter性能差NSLock临界区互斥要配对lock/unlock容易死锁NSConditionLock条件触发复杂场景用避免过度设计dispatch_semaphore信号量控制可替代手写锁但别用wait阻塞主线程os_unfair_lock短暂临界区低层、高性能不能长期持有NSRecursiveLock递归调用场景防止同一线程重入死锁当你把这些都答完了如果能主动补一句实际项目中我优先用串行队列barrier区分需求避免在频繁路径上加锁那么面试官对你的技术评判就会从会背题上升到有工程判断力。3. 架构与设计类面试题从用过哪些架构到为什么这样设计架构类问题在社招面试中占比很高。考察点不是你会不会写MVVM而是你有没有在真实项目中做出过的架构决策。3.1 回答架构题的正确姿势先说为什么要分层很多人一上来就背MVC、MVP、MVVM、VIPER各自的优缺点面试官听完毫无感觉。他们想听的是——你手里的项目规模、团队规模、需求迭代速度是怎么推动你做出架构取舍的。我建议按这个结构组织答案业务场景这个模块/App有哪些核心业务线为什么不适合传统的MVC直写。架构选型为什么从MVC转向MVVM或为什么团队一直坚持MVC。落地方式数据绑定怎么处理网络层与业务层如何隔离可测试性如何保证。踩坑复盘模块划分后遇到过的严重耦合问题如何解决。比如讲MVVM如果你只知道ViewModel绑定数据、控制器瘦身那就太浅了。面试官更想听的是你用什么绑定机制KVO / RAC / Combine依赖注入怎么做单元测试怎么测ViewModel网络请求失败时状态如何映射到View层。这些实操细节才是架构经验的证明。3.2 组件化和模块化不要只会画架构图组件化是iOS高级岗位的常见话题。面试官最爱问你们的组件怎么通信如果A模块需要B模块的一个页面你们怎么调用如果底层基础库升级影响了所有业务模块你们怎么处理这里有几个拿分点中间层设计是采用URL路由还是使用Protocol机制。二者适用场景有何不同。依赖管理是用CocoaPods还是SPM私有库的维护责任如何划分版本如何管理。重构策略从单工程切分到多项目时哪些模块先拆、哪些后拆为什么。这些如果你都在项目里踩过答起来会非常自然。没有经验的候选人往往会去背我用了MGJRouter做页面路由这样的名词但问一句如果你做的是持续集成里的自动链路路由表的注册时机怎么处理就会卡壳。3.3 性能优化题把我优化过启动速度说成带数据的故事性能优化几乎逢面必问。准备这类问题核心技巧只有一条用数据讲故事。比如启动优化你可以这样组织答案如何度量通过Instruments Time Profiler / MetricKit / 自研工具量化App从进程启动到首页可交互的时间录制优化前后数据。定位耗时阶段区分main函数之前和main函数之后。main之前重点看dylib加载、动态库依赖、ObjC类注册main之后重点看didFinishLaunching中初始化了哪些无关业务。优化手段可以提到减少不必要动态库、合并类、二进制重排利用-order_file优化Page Fault、把非首屏业务延迟加载、懒加载统计SDK等。效果验收启动耗时从多少毫秒降到多少毫秒冷启动的崩溃率有无变化。这套打法展示出来即便你用的手段很常规面试官也会认为你是真正做过优化的人而不是只会报参数。4. 项目面试把简历上的做过变成讲得清简历写完只是第一步更关键的是如何应对面试官围绕项目本身的连珠炮式追问。很多候选人挂在项目面不是因为项目不够大而是因为他们根本讲不清楚自己做了什么、为什么这么做、有没有别的方案。4.1 一个能扛住追问的项目自我介绍结构我建议用背景-目标-个人职责-技术难点-方案选型-结果复盘这个链路来组织。以我做了一个IM模块为例不要只说我负责IM消息模块的开发要说背景公司业务需要一个即时通讯能力第三方SDK成本高且无法定制化所以决定自研。目标支持单聊、群聊、图片/语音消息首屏消息加载耗时不能超过500ms。我的职责负责消息收发链路、离线消息拉取和会话列表的数据层设计。技术难点消息时序问题客户端与服务端消息id不一致导致排序错乱多人群聊的高频写库性能。方案选型客户端消息序列化采用Protobuf而非JSON因为解析性能差距约3倍时序处理上引入了本地递增sessionid服务端全局seq的双层排序机制。结果复盘首屏加载从约800ms优化到约350ms消息乱序率从千分之三降低到接近0。把一个项目讲成一条线比堆砌一堆名词强得多。面试官也会根据你的故事走向追问具体技术点这样你就有机会展示深水区知识。4.2 面试官最爱的折磨人问题你觉得哪个点最复杂这是一道几乎必考的问题。答案不能太简单也不能太假大空。一个好的策略是选择你真正深入研究过、且能讲清楚机制的技术点。举一个示例问题链候选人说最复杂的是消息重试机制。面试官问重试策略是固定间隔还是指数退避你是如何设计重试上限的候选人答采用的是指数退避最大重试5次每次间隔为2^n倍但增加了抖动。面试官追问为什么要增加抖动如果服务端已经宕机你的重试会不会加大雪崩概率候选人如果能答出抖动是为了避免惊群效应同时结合服务端的熔断状态来提前终止重试那么面试官对候选人工程能力的认可度会明显提高。这样的问答链条完全来自你真实的项目思考而不是一道标准八股题。面试官也是人他们能分辨出你是在回忆真实经历还是在背一篇博客。4.3 跨端方案、热更新、上架合规这些周边题也要有立场从近两年的热搜词来看很多人会搜uniapp ios app打测试包全流程ios微信双开签名失败ios上架这类问题。面试中面试官也有可能问你对跨端方案或上架合规的看法。我的建议是对这些周边题主要考察你的判断力和安全意识。比如跨端方案你所在的项目是否引入过Flutter/RN/uni-app你是支持还是反对理由是什么如果被选型为某个场景的跨端方案你会如何设计原生与跨端的通信通道上架合规你是否处理过审核被拒的案例你是怎么追踪问题、修改权限声明、补充隐私信息的这背后体现的是你是否有产品边界意识。这些问题没有唯一答案但绝不能一句话回绝。至少准备一个我经历过某次上架难题并成功解决的经历。5. iOS工程师怎么持续维护自己的面试题库最后这一块结合栏目的更新聊聊我自己整理面试知识时的一些实操手段。5.1 用错题本而不是知识清单来组织复习我在维护这个栏目的时候最大的收获是不要按面经的顺序去背而要把自己答不上来的题做成错题本。错题本的结构包含三部分原题、答不出的原因、完整的回答思路。整理时用Markdown记下就可以每条控制在300-500字末尾附上面试官追问时我要主动说出的细节。比如我曾在一次模拟面试中突然卡住的问题cache_t中的bucket是如何扩容的 我当时的反应是忘了还有这个细节。后来我补上了哈希表的扩容因子是3/4超过后重新分配两倍大小并且把所有旧的bucket重新hash。这个细节一般面经不会写但一旦讲出来面试官会觉得你真读过源码。5.2 用写面试文代替背面试题我强烈推荐一个方法如果一道题你不能用大白话给一个外行讲明白说明你没有真正掌握它。所以我在整理面经的时候每道题都尝试先用自己的话写一遍再对照权威资料查漏补缺。这个过程本质上就是费曼学习法但对面试复习特别有效。举个例子RunLoop很多文章喜欢讲成事件循环机制大白话版本是RunLoop让线程一直活着但又不会一直空转没事情做的时候睡觉有事情的时候立马醒过来干活。这样讲你不仅自己理解了面试官也会觉得你讲解能力不错。5.3 保持技术和真题的同步更新iOS面试题不是一成不变的。这两年我看到的变化趋势是Swift和SwiftUI相关题目比重明显上升Open Source库底层原理比如SDWebImage、AFNetworking的实现开始成为深水区话题性能优化也开始细化到CPU、IO、内存三个维度。这就意味着你的复习资料不能只看两三年前的旧题单。我更新栏目时会定期搜索最新面经、搜集近期真题再结合自己的理解重新梳理答案。用这样的方式才能保证你在面试场上遇到的知识点不是远古题库。推荐的更新节奏是每两周花一个晚上把所有新增真题和新技术点归纳进你自己的体系。我在实际使用中发现把题库整理成按知识点聚类按难易递进比按公司分类更好用。按公司分类的问题在于各公司题目重合度过高容易重复劳动而按知识点聚类你能快速找出自己的薄弱面是什么然后逐个击破。面试准备本质上是件慢就是快的事。与其在面试前一周狂刷两百道题不如提前两个月每周吃透两到三个核心机制的完整原理链。这套方法能不能出效果你按照上面的思路去准备一周就能感觉到——你讲出来的答案会比以前有底气得多。这个栏目我会持续更新下去每整理一批新题我都会把当时的思考过程同步进来希望对正在准备面试的你有所帮助。