先说明一下，这个栏目我确实持续在更新。市面上讲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的实现原理"，他答得飞快："是维护了一个SideTable，release时查找弱引用表，把指针置成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_t，Cache Hit直接跳到函数地址；Cache Miss才走方法列表线性查找或二分查找；如果走到了父类，还要处理super_class跳转。整个过程还涉及_objc_msgForward的跳转路径。
再往后就是消息转发三部曲——resolveInstanceMethod->forwardingTargetForSelector->methodSignatureForSelector+forwardInvocation。
但面试官深挖时通常会问两个实战问题：
- 动态添加方法你实际用过吗？如果只答"把方法添加到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、内存三个维度。
这就意味着你的复习资料不能只看两三年前的旧题单。我更新栏目时，会定期搜索最新面经、搜集近期真题，再结合自己的理解重新梳理答案。用这样的方式，才能保证你在面试场上遇到的知识点不是"远古题库"。推荐的更新节奏是每两周花一个晚上，把所有新增真题和新技术点归纳进你自己的体系。
我在实际使用中发现，把题库整理成"按知识点聚类+按难易递进"比按公司分类更好用。按公司分类的问题在于各公司题目重合度过高，容易重复劳动；而按知识点聚类，你能快速找出自己的薄弱面是什么，然后逐个击破。
面试准备本质上是件"慢就是快"的事。与其在面试前一周狂刷两百道题，不如提前两个月，每周吃透两到三个核心机制的完整原理链。这套方法能不能出效果，你按照上面的思路去准备一周就能感觉到——你讲出来的答案，会比以前"有底气"得多。这个栏目我会持续更新下去，每整理一批新题，我都会把当时的思考过程同步进来，希望对正在准备面试的你有所帮助。
