2023年年底那阵子我带团队把秋招iOS研发岗的试卷出完、批完正好是第二批笔试。比起第一批这一批的备选池子更杂有科班出身的也有培训转行、做了两三个仿写项目就来投的。试卷批完我最大的感受是真正拉开差距的从来不是谁刷的题多而是谁真的理解iOS开发里那些“看不见的成本”——内存、线程、渲染、审核。这篇文章就把这批笔试的出题思路、高频考点、典型的错误答案以及批卷时我们实际看的采分点完整复盘一遍。不整虚的全是针对iOS研发岗校招笔试的硬核拆解打算冲大厂iOS岗的可以拿这份清单做个自测。1. 这批笔试的整体定位与考察思路1.1 小满秋招第二批笔试与第一批的差异小满的秋招笔试分了好几批第二批比第一批晚了两周左右。岗位JD上写的还是“iOS研发工程师”但这一批的候选人画像和第一批有明显区别——第一批基本是海投的应届生很多人连App Store上架流程都说不清第二批里混进了一批已经做了两三个完整项目、甚至有过上架经验的候选人所以笔试难度必须抬一档否则区分度不够。我们内部定调子的时候对第二批笔试的要求是“不考死记硬背考能不能上线。”所谓“能不能上线”是指候选人写出来的代码、给出的方案能不能直接放进一个真实迭代中的App里经受住内存、卡顿、审核、崩溃这些现实问题的拷打。第二批笔试的时间是120分钟题型分三类客观题单选多选混合、程序题给一段iOS代码让你分析问题、编程题手写完整实现。总分100分其中客观题30分程序题30分编程题40分。从分值分布就能看出来我们更看重的是候选人“动手写”和“定位问题”的能力而不是背概念。1.2 选拔标准我们真正想从笔试中看到什么批了这么多份卷子我总结出校招iOS笔试真正在筛选的三层能力。第一层是基本功的扎实度。Objective-C和Swift能不能混合着看懂内存管理是不是真的理解ARC和循环引用多线程用的是GCD还是操作队列、知不知道怎么避免死锁。这一层不行后面全白搭。第二层是工程敏感度。同样的功能有人用最简单的方式实现了事有人会主动考虑“这会不会卡主线程”“这会不会内存暴涨”“这能不能过审”。我们考察的是后者。比如我们出过一道题问如何实现一个图片缓存库很多人的答案就剩俩字“用SDWebImage”这种我们只给一半分因为调用第三方库本身不难难的是说清楚缓存策略、磁盘清理时机、内存警告处理。第三层是问题定位能力。iOS开发里最耗时间的不是写代码而是排查线上问题。我们会给一段有明显崩溃隐患的代码考察候选人能不能看出问题在哪、为什么崩溃、怎么修复。语言组织混乱、上来就瞎猜的基本过不了。2. 客观题部分iOS基础与架构的“隐藏分水岭”2.1 从热词看高频考察点架构、内存、多线程把近两年iOS岗笔试的热词拉出来看出现频率最高的几个是iOS架构、iOS内存管理、iOS多线程、iOS自动化、iOS上架。这几个词基本勾勒出了一个大厂iOS研发日常工作的全貌——你不仅要会写界面还要能搭建稳健的代码结构处理性能和内存问题用自动化脚本提升效率最后还得把App顺利送审上架。第二批笔试的客观题我们专门出了几道跟这些热词直接相关的题。不是出于追热度而是因为这些方向正好对应着团队日常最常踩坑的地方。架构题考的是分层意识和解耦思路。我们问了MVVM和MVC的核心区别很多人都会背“MVVM多了ViewModel”这种话但真的让他们分析一段无脑把网络请求写进View的烂代码该怎么重构时能答出完整分层方案的人不到两成。内存题考的是ARC下的循环引用。这个几乎是必考题但我们把陷阱埋在了一个比较隐蔽的地方——闭包捕获。很多候选人能背出“delegate要用weak修饰”但换到Swift闭包里就忘了[weak self]。多线程题考的是数据竞争。题目是两个线程同时对同一个数组进行添加操作会怎样答案是可能崩溃也可能不会因为数组不是线程安全的。很多人上来就答“会崩溃”其实不够严谨这要看操作时机和内存布局。2.2 笔试中典型的客观题与背后逻辑这里还原几道我们实际用过的客观题每题都附上出题意图。题目一单选在iOS开发中下面哪种方式可以避免循环引用 A. 在Block中使用__weak修饰外部对象 B. 在Block中使用__strong修饰外部对象 C. 在Block中直接调用外部对象的属性 D. 关闭ARC机制答案选A。这题的正确率有七成但有意思的是很多人只知其然不知其所以然。我们追问了一道简答题为什么__weak能避免循环引用能答出“weak不增加引用计数打破引用环”的才算真正掌握。只背答案的很难解释清楚。题目二多选以下关于iOS内存管理的说法哪些是正确的 A. 在ARC环境下开发者不需要手动调用release B. 在ARC环境下仍然可能出现循环引用 C. 在ARC环境下开发者需要手动管理autoreleasepool D. 内存警告时系统会回收一些缓存对象答案是ABD。C是错项因为autoreleasepool在ARC下虽然可以手动写但日常开发中大多数场景不是必须的。这道题的正确率不到四成很多人以为ARC就是“系统全托管”完全不知道循环引用这回事。题目三单选使用GCD实现延迟3秒执行一段代码正确的API是 A. dispatch_async B. dispatch_after C. dispatch_sync D. dispatch_once答案是B。这题本身不难但我们加了道追问dispatch_after内部是基于什么机制实现的能答出“内部是用dispatch_source_t或者定时器实现只是封装成一个block接口”的人很少。这个追问帮助我们筛掉了一批只会用API、不懂原理的候选人。2.3 客观题常见失分点批下来看客观题的失分点高度集中基本可以归纳成三类情况。一类是混用OC和Swift的概念。比如有人答Swift内存管理时写“系统会在引用计数为0时自动释放等同于ARC”这句话没错但后面又补一句“Swift里没有循环引用”这就错了。Swift和OC一样有循环引用只是Swift用protocol、闭包时也容易踩这个坑。一类是过度依赖第三方库。题目只要涉及具体实现就写“用AFNetworking / SDWebImage它们都处理好了”。我们出题不是为了考你会不会用第三方库那太容易了只要是个程序员搜索下就会。我们需要的是候选人理解底层逻辑。比如SDWebImage的缓存策略是什么内存用NSCache磁盘用文件存储这个得能说出来。还有一类是对生命周期理解不深。我们对AppDelegate、ViewController生命周期的考察从来不直接问“viewDidLoad和viewWillAppear谁先调用”而是换种问法比如“在viewDidLoad里启动一个定时器页面被push到后台再回来定时器会怎样”。能想到定时器没有自动暂停的人不多这暴露了很多人对应用状态切换时的回调机制理解不到位。3. 程序题部分不仅仅是“跑通”还要“能上线”3.1 UI与布局题UIStackView与适配程序题第一道给出了一个真实业务场景App首页需要展示一行商品标签标签之间间距8pt标签可以自动换行数量不固定。要求写一个实现方案并说明Auto Layout如何处理。很多人的第一反应是用UICollectionView但这道题的正确做法其实更简单——用UIStackView设置属性axisverticalalignmentleadingspacing8再给每个标签外面套一层容器控制宽度。iOS UIStackView这个热词在最近两年的面试题里出现了好多次我们特意把它放进第二批笔试里是想考察候选人是否了解系统控件的演进。UIStackView本身不复杂复杂的是它和Auto Layout的配合。比如标签的数量不固定StackView的宽度是撑满还是自适应这决定了换行逻辑。好的实现方案会先把每个标签的宽度算出来放进horizontalStackView里一个horizontalStackView对应一行再把这些horizontalStackView放进verticalStackView里。这样自动换行的效果就有了而且不需要额外的计算。这一题还考察了iOS分屏与不同尺寸适配。面试题里出现“iOS分屏”这种热词对应的其实就是多尺寸适配问题。我们追问过在iPhone SE和iPhone 15 Pro Max上布局会怎样变化有人答“用Masonry设置约束就行”这个答案过于笼统我们想看的是是否考虑过最大宽度、换行时机、字号缩放这些细节点。3.2 网络与调试题抓包、证书、上架流程程序题第二道给了一段代码是使用URLSession发起网络请求并解析JSON。代码本身能跑通但存在一个隐蔽问题没有处理ATSApp Transport Security限制。ATS是iOS 9之后引入的安全机制默认要求网络请求必须使用HTTPS。很多开发者在调试阶段为了图方便直接在Info.plist里设置NSAllowsArbitraryLoads为YES这样确实能跑通但上架审核时会被苹果警告甚至被拒。我把charles、抓包、证书更新这些热词对应的技能都融进了这道题。题目问的是这段代码如果直接打包上线可能出现什么问题能答出ATS限制的人不少但能进一步说明“如何正确配置ATS、如何申请和更新开发者证书、如何在应用内处理证书信任”的人不到一成。这道题的后半部分考察的是上架流程。我们列了几个步骤让候选人排出正确顺序创建App ID、生成描述文件、配置Bundle Identifier、上传到TestFlight、提交审核。正确顺序是创建App ID - 配置Bundle Identifier - 生成描述文件 - 上传到TestFlight - 提交审核。很多人把“配置Bundle Identifier”和“创建App ID”搞混或者不知道TestFlight是审核前的必经环节。3.3 自动化与性能优化题程序题第三道我们给了一段Instrument相关的描述问的是一个页面滚动时掉帧可能的原因有哪些如何用工具定位这是一道开放性题目能想到的原因包括主线程做了耗时操作、图片解码没有放到子线程、Auto Layout约束过多导致计算量过大、离屏渲染过多、内存暴涨导致系统回收卡顿。定位方法是要说清楚“先看Instrument的Time Profiler和Core Animation再看主线程有没有耗时方法”。这里对应的热词是iOS自动化——自动化不仅能用来跑测试还能自动采集性能数据。比如用XCTest写UI测试配合Xcode的Performance工具可以在CI流程里跑完性能基线对比。我们团队日常就是这么做的每个版本出包后自动化测试自动跑核心页面滚动帧率帧率低于阈值就直接发告警而不是等用户反馈了才知道卡。这一题还顺便考察了电池优化。iOS电池优化在热词里出现频率很高我们问的是定位权限在后台频繁使用对电池有什么影响正确作答方向是后台持续定位会高频率唤醒CPU和网络模块导致电量迅速消耗iOS系统会弹窗提示用户最终可能被用户关闭权限。能答出“批量位置更新、降低精度、使用visit monitoring”这些策略的候选人是真正做过iOS电池优化的。4. 编程题部分手写代码的评分细则4.1 题目一实现一个线程安全的数组编程题第一道是手写一个线程安全的可变数组类要求支持add、remove、get操作并说明设计思路。这道题考察的内容非常直白多线程环境下的数据竞争问题。我们允许使用OC或Swift重点看三点是否用了锁、用的什么锁、锁的粒度是否合理。最基础的得分答案是给每个方法加synchronized或者NSLock。这能拿到6成左右的分数因为操作是安全的但性能不好。高分答案会在这基础上做优化。比如使用读写锁读操作用pthread_rwlock_rdlock写操作用pthread_rwlock_wrlock。这个答案能拿到8成以上因为体现出了候选人理解“读多写少”场景下锁性能的差异。满分答案是在OC中用dispatch_queue_t创建一个并发队列读操作使用dispatch_sync写操作使用dispatch_barrier_async。这个方案结合了GCD的高层抽象和barrier的独占特性既安全又高效代码还简洁。能写出这种方案的候选人说明对GCD的理解已经超过面试平均水平。我们批卷时发现有个候选人写出了用OSSpinLock的答案看起来很高端但这种方法其实已经废弃了因为Priority Inversion问题导致它不再被推荐。这个答案我们不扣分但会标注“需要更新知识体系”。4.2 题目二实现一个简单的图片缓存编程题第二道是实现一个简单的图片缓存要求包括内存缓存和磁盘缓存并说明清理策略。这题的本质是考察候选人设计系统组件的能力。核心得分点有几个内存缓存必须用NSCache而不是NSDictionary。为什么NSCache是系统提供的缓存类自带淘汰策略能在内存警告时自动清理部分对象而且它是线程安全的。用NSDictionary的话需要自己处理内存警告、加锁几乎就是把NSCache重新实现一遍。磁盘缓存需要说明存储路径和文件格式。高分答案会说保存在Caches目录下文件名用URL的MD5作为key这样能避免URL中的特殊字符导致文件名非法。清理策略是重点。内存清理策略监听UIApplicationDidReceiveMemoryWarningNotification收到警告后清空内存缓存。磁盘清理策略设置一个容量上限比如50MB存文件时检查当前缓存总大小超限就按写入时间从早到晚删除。能写出LRU最近最少使用的是加分项。这道题失分最多的地方是很多人只写了“内存存字典磁盘存文件”没有任何容量和清理机制的概念。这种答案说明候选人没有生产环境经验不知道缓存是双刃剑——没有淘汰策略的缓存时间久了就是内存炸弹。4.3 编程题第三题UI布局与交互实现编程题第三道给了一张设计图设计图上是一个常见的商品卡片顶部是图片中间是标题和价格底部是一个“加入购物车”按钮。要求用代码实现整个页面布局并实现按钮点击后的回调处理。这道题考察的是界面开发基本功。我们看几个点是否用了Auto Layout、是否使用SafeArea、是否对图片做了尺寸适配。得低分的答案是写一长串setFrame的代码手动计算每个UI元素的位置。这在大屏时代完全不可用一旦换了设备尺寸布局就走形。得中等分的答案是用约束来实现每个控件都有leading/trailing/top/bottom约束能保证在不同尺寸下不越界。得高分的答案是除了约束写对还考虑了动态字体、内容压缩优先级、图片的contentMode。比如标题Label的compression resistance priority设置能保证文字太多时不是简单截断而是优先压缩底部按钮的高度防止溢出。按钮点击回调我们允许用target-action或闭包但要求注意内存管理。用Swift闭包时如果闭包捕获了self需要[weak self]否则形成循环引用。很多人在这个细节上翻车。5. 常见问题与批改实录5.1 答题中最常见的问题批第二批次卷子的时候我把问题归纳成了几类有共性的问题在内部复盘中我们都讨论过。笔试题当作背诵题来做。最典型的是关于ARC的问题很多人直接写下“ARC是自动引用计数有一套编译器自动管理内存的机制”。问为什么能解决循环引用就答不上来。说明这位候选人只是背了定义完全没有参与过真实项目中的内存优化。思维局限在iOS小圈子。有一道题问的是多线程同步我们给了几个方案让候选人判断哪个最优。很多人选了dispatch_semaphore信号量这个方案能用但不是最优。最优方案是dispatch_barrier。为什么semaphore适合控制流量不适合做数据屏障。能区分这两个概念的候选人通常不仅接触过iOS还接触过操作系统的生产者消费者模型。不写思路只贴代码。编程题里我们允许两种方式作答伪代码文字说明或者完整代码。但我们发现有一部分人既不写说明代码又写不全从中间某几行跳到另一段不相关的代码。这种答案基本没法给分因为我们不知道候选人脑子里想的是什么没法判断他是真不会还是只是写的时候笔误了。5.2 高分答卷的行为习惯高分答案有一些明显的共性特征。首先要说的是答题顺序。笔试开始后我们先让候选人浏览全卷很多人一上来就死磕编程题第一道花了40分钟最后程序题和客观题时间不够。高分候选人会先花5分钟把整张卷子的题都扫一遍对每道题有个预期时间然后按客观题、程序题、编程题的顺序推进。因为客观上客观题是第一轮分组筛的核心丢分太可惜。其次是写答案的方式。高分候选人写的不是简单答案而是“结论推导过程”。比如问到为什么要用NSCache而不是NSDictionary他们会写“因为NSCache是线程安全的自带清理机制会响应系统内存警告。另外从性能角度讲NSCache的key不会像NSDictionary那样被拷贝节省内存开销。”这种答案是任何面试官都愿意给满分的答案。最后是审题仔细。我们设计了一道题题目里有一段代码用一个viewController作为另一个viewController的代理并且使用了strong修饰。问题问的是这个会不会造成循环引用。很多人只答“代理和VC互相强引用会循环引用”但没注意到代理方法里其实没用到那个VC。实际上循环引用链是否真的建立取决于delegate是否被赋值。高分答案会先分析代码执行路径再下结论。5.3 针对备选人的复盘建议笔试结束后我们内部复盘了一套针对下一轮面试的提问清单也在这里分享给参加秋招的候选人们。iOS开发面试不要只准备基础语法要往上走一层准备架构和性能。很多候选人能背出MVC和MVVM的定义但问到“你们项目里VC动辄一千行怎么拆”就懵了。这是很现实的问题但凡做过半年iOS开发都会碰到。提前准备自己的思路哪怕是“把网络请求抽到APIManager、把数据解析抽到Model层”这种简单拆法也比没有想法强。多线程几乎是必考题但不要只背GCD和OperationQueue的区别。准备几个深入的问题队列和线程是什么关系、主队列是怎么保证串行执行的、怎么避免死锁。可以自己写一段死锁代码然后用dispatch_async去修复试过一遍才算真正理解。关于iOS上架流程建议自己动手走一遍。不用真的有付费开发者账号先用Xcode的模拟器模拟一下签名逻辑再了解TestFlight的作用搞清楚一套描述文件是从哪申请的。这些内容在笔试中不会直接考但在程序设计题中如果候选人能顺带提及上架时需要注意配置证书我们就会觉得这个人有实战意识。写在最后笔试之后的几件事第二批笔试结束那天晚上我们把通过笔试的候选人的名单拉出来核对了一遍。有意思的是笔试分数最高的几个人未必是简历上项目写得最漂亮的但他们有一个共同点答题时对细节的执念特别重。比如一道关于网络请求的题目他们会主动提到“超时时间应该设置成多少”“失败重试要考虑幂等性”“JSON序列化遇到空字段怎么处理”。这种对细节的敏感度是iOS开发里最宝贵的素质之一。如果你正在准备iOS秋招我的建议是别把精力全花在刷算法题上多留点时间给自己的工程实践。去找一个你感兴趣的小功能比如图片缓存、页面性能优化、自动化测试接入亲手做一遍把每一步的原理弄懂。笔试考的不是你记了多少API而是你有没有真的动手做过、遇到过问题、踩过坑。按照我个人的经验一个能把UIImageView加载图片的完整流程包括解码、缓存、主线程回调讲清楚的候选人比一个背了三百道面试题的口头程序员要强得多。iOS这个领域不需要背诵冠军需要的是能解决问题的人。