老实说收到这份“2023年度小满春招iOS研发岗第一批笔试”的邮件时我多少有点意外。春招笔试我见过不少绝大多数是牛客网上的选择题加两道算法题做完就等通知。小满这批不一样它把笔试题和实际工程场景绑得很紧考的不是“你背过多少”而是“你排过多少坑”。我花了整整一个下午做完出来之后第一反应不是累而是想找人对一遍答案。这份笔试覆盖的面很广从OC底层到App上架从蓝牙连接参数到uniapp打包流程几乎把iOS研发日常要碰的链路都过了一遍。如果你正准备iOS春招或者社招想找一份能真正练手的笔试题这篇复盘应该能帮你省不少事。我会按我的做题顺序把每一类题型的考察意图、我的解题思路、以及我栽过跟头的地方都写出来也尽量把底层原理讲透毕竟光知道答案面试官追问一句就露馅了。1. 笔试定调这批题到底想考什么先把整体观感放在前面。这套笔试试卷并不是单纯的知识点堆积而是围绕一个iOS研发工程师从开发到上线再到维护的完整闭环来出题。我做了个分类统计题型结构大概是下面这样题型占比重点考察方向OC/Swift基础与内存管理25%weak底层、引用计数、RunLoop多线程与性能优化20%GCD死锁、卡顿检测、电池优化系统机制与UI布局20%蓝牙状态机、BLE参数、UIStackView、分屏适配工程化与打包上架20%开发者证书、加急审核、IPATest流程、抓包混合开发与开放性设计15%uniapp/混合架构选型、自动化测试方案从出题逻辑来看这份卷子很明显在筛选两类人一是基础扎实、能解释“为什么”的科班选手二是真正上线过产品、踩过发布链路坑的实战型选手。纯刷题选手和纯业务选手都容易被筛掉。有一个细节值得注意题目里多次出现了面向工程落地的场景比如“uniapp打包iOS测试包全流程”“iOS开发者App证书更新”“charles iOS抓包”这类关键词。这说明出题人默认你至少完整走过一次上架流程而不是只会写页面。如果你还没拿到过真机调试证书建议先花时间把开发者账号、描述文件、导出IPA这一套流程走通否则笔试中这部分基本就是空白状态。另外这套题对系统机制原理的挖掘比一般笔试深得多。比如蓝牙那部分它不直接问“怎么用CoreBluetooth”而是问“CBPeripheralManager系统级蓝牙状态和App级蓝牙状态能否区分”这种题如果不看WWDC的Session只靠日常API调用经验很容易答偏。我后面会单独用一大节展开。2. 技术深度题内存、并发与卡顿的真实考点2.1 weak底层原理与“无效weak引用”陷阱这批题里有一道让我印象很深问的是“weak修饰的对象在什么情况下不会被置为nil”。大多数人都知道weak的底层是SideTable里的weak_table对象释放时会遍历weak_entry_t把指针清空。但题目加了个场景对象在AutoreleasePool中被强引用当前作用域结束后weak指针不会立刻变nil。这就考到了objc_storeWeak和objc_loadWeak的调用时机以及AutoreleasePool的push/pop边界。如果只答“weak自动置nil”就踩坑了。我在答题时写了这样一段推理weak置nil的本质依赖objc_destructInstance执行完release后runtime通过synchronized对象列表遍历弱引用表。只要对象还有一份强引用在AutoreleasePool栈上持有dealloc就不会触发weak当然不会变nil。这个点我建议大家在复习时配合objc4源码看一遍尤其是weak_clear_no_lock函数的条件判断。2.2 RunLoop和性能监控的联动考法关于卡顿监控笔试没有直接问“怎么监听卡顿”而是问“卡顿检测的runLoopObserver应该在哪个activity中监听为什么有人用beforeWaiting而非afterWaiting”。这个差距很关键。afterWaiting触发时机是RunLoop刚被唤醒此时还没处理事件如果源事件本身耗时很低但系统主线程已经积压了一堆任务afterWaiting的耗时并不能真实反映用户感知的卡顿。beforeWaiting则是在处理完所有事件即将休眠前回调能反映出这一轮RunLoop迭代的完整耗时所以主流卡顿监控SDK都用beforeWaiting。题目还延伸到了离屏渲染和电池优化。有一个小题是问“为什么圆角阴影同时设置会导致掉帧”。我在答题时拆了两层圆角会造成离屏渲染阴影是另一个离屏上下文两个加一起就是多重离屏会赶在提交前把所有layer合成到backing store而Apple的渲染树提交是按事务批处理的只要有一个图层触发离屏整个图层树可能都要进入offscreen pass。更合理的做法是给shadowPath和cornerRadius分开表达或者直接使用maskToBounds并避免同时有透明边框。这块如果你平时只调UI没有在Instruments里看过Core Animation的kFPS理解起来会有点抽象但面试官很青睐这种能从渲染管线层面解释的回答。2.3 多线程同步从死锁到信号量这套题的多线程部分没有考很偏的函数经典的“同步任务在串行队列里调用sync会不会死锁”依然出现了。但真正的分水岭在于后面还跟了一道综合题在多个并发网络请求都完成后统一刷新UI要求同时给出GCD和OperationQueue两种方案。GCD用DispatchGroup加notifyOperationQueue用最大并发数加依赖关系都可以。不过题目埋了个坑如果某个请求超时两种方案默认行为不同DispatchGroup会等超时结束才走notifyOperationQueue只要被依赖的Operation被标记finish就行。题目问怎么处理超时兜底我答的是封装一个带timeout的异步闭包内部用DispatchSourceTimer做超时驱动避免因为某个请求挂死导致整个页面一直loading。这类题目考察的本质不是API记忆而是对“任务状态机”的理解。答这类题建议把同步、异步、串行、并行、栅栏、信号量这几个基础概念画成图想一遍然后结合平时的网络层封装来回答比死记结论更有说服力。3. 系统机制与UI题从蓝牙状态机到分屏适配3.1 系统级蓝牙状态与App级蓝牙状态到底能不能区分这是整份卷子我个人最喜欢的一道题“CBCentralManager系统级蓝牙状态和App级蓝牙状态能区分出来吗”先说结论能但要看系统版本。iOS 13之前CBCentralManager的state属性只有系统级含义App没有单独的授权状态。iOS 13开始蓝牙权限被拆成系统蓝牙开关和App授权两个维度系统开关关闭时centralManagerDidUpdateState拿到的是poweredOffApp被用户关闭权限时拿到的是unauthorized并且BLE授权状态和定位权限一样有“使用期间允许”这类细分。所以题目的标准答案是能区分分别对应CBCentralManagerState的poweredOff和unauthorized。我在答题时还额外补了一个容易被忽略的点CBPeripheralManager的state和CBCentralManager的state并不完全一致TM类的外设管理器有自己的授权体系如果你把这两个混用会出现“中心模式正常但外设模式回调权限拒绝”的诡异现象。做蓝牙外设的调试时建议把两套状态分开打日志。3.2 BLE连接参数规范连接间隔、从机延迟和超时这道题给了一个嵌入式设备场景手环设备连接后每20ms发一次数据但app端偶尔出现数据断流。问怎么调优BLE连接参数。我在答题时按连接参数表和实际经验分了三块连接间隔Connection Interval单位1.25ms一般建议在15ms到30ms之间平衡功耗和吞吐量。如果设备需要高频传输比如心率波形可以申请7.5ms的最小间隔但系统可能因为射频共存而拒绝实际协商结果会落在30ms左右。从机延迟Slave Latency允许设备跳过一定数量的连接事件常用于省电。如果从机延迟配置过大app端会感觉数据到达不稳定。手环场景建议设0否则明明发了数据但主机端几个连接事件后才收到。超时时间Supervision Timeout范围100ms到32s必须大于连接间隔乘以(1从机延迟)的2倍。很多断连问题不是信号问题而是这个参数配置得不合理。笔试改卷时阅卷人会看你能不能把参数落实到具体业务场景而不只是背规格。所以我写了“20ms上报数据建议连接间隔15ms、从机延迟0、超时5s起步再根据功耗测试收敛”这样一段让答案显得有决策依据。3.3 UIStackView与分屏适配UIStackView出现很多年了但笔试考得不浅。题目问“UIStackView里嵌套UIStackView在iOS分屏宽度变化时如何保持比例布局”。很多人觉得UIStackView会自动搞定一切其实它有坑当从Regular宽度变到Compact宽度StackView可能无法同时满足多个约束这时默认会压缩或拉伸而不是按你设定的distribution优先级走。我在答题时画了根因UIStackView本质是懒约束生成器它的布局信息在触发layout时才会生成约束系统根据排列方向和distribution统一生成等宽、等比或间距约束。如果父视图宽度变化太快中间未满足的约束会临时参与计算出现闪烁。解决方法是给StackView里的视图设置明确的Content Hugging和Content Compression Resistance优先级而不是只依赖StackView的distribution。另外分屏时建议用traitCollectionDidChange或者viewWillTransition监听SizeClass变化给约束做一次刷新。这题真做过的同学应该都有共鸣尤其是当StackView嵌套三个子视图、其中一个子视图还有固定宽高比时分屏表现真的会和人预期不一样。3.4 动态更换App图标setAlternateIconName的边界问题笔试题里出现了“UIApplication.shared.setAlternateIconName本身调用系统级确认弹框时报错”的场景。这个点确实有点偏但这两年越来越多人做节日换肤功能所以也拿上台面了。我答题时写的是系统弹框属于进程外系统UI不会随App激活状态变化但调用这个API时必须保证App处于活跃状态不然会抛Error。如果同时配置了多个Alternate Icon需要在Info.plist里把CFBundleAlternateIcons配置对否则即使方法名没错也会因为找不到图标资源而失败。更隐蔽的是iOS 26之后这个API的行为可能有微调系统弹框的样式和回调时机也与旧版本不同建议在真机上充分回归。4. 工程化链路题证书、上架、抓包与打包全流程4.1 iOS开发者App证书更新的完整链路与常见失败点笔试工程化部分的第一道题就是证书更新。说实话这道题对没上过架的人很不友好因为Apple开发者后台的“证书、标识符和描述文件”入口不是字面上那么简单。我按自己平时的操作流程拆解如下登录Apple Developer后台进入Certificates, Identifiers Profiles。在Keychain Access里从“证书助理”请求证书生成CSR文件这个文件是私钥归属的关键私钥一旦丢失对应证书即使下载成功也无法安装签名。上传CSR选择iOS Distribution或iOS Development下载证书双击安装到钥匙串。更新App ID配置确认Bundle Identifier与工程完全一致。修改或新建描述文件选择对应的App ID和证书下载双击安装。在Xcode的Signing Capabilities里重新选择Team和Provisioning Profile必要时执行一次Clean Build Folder。常见失败点有两类一是老证书没在开发者后台吊销新证书和旧证书同时存在导致Xcode签名时选了旧证书二是描述文件里包含的证书列表过期真机调试时提示“No valid signing certificate found”。笔试有一问专门考这个我给的答案是签名匹配是证书私钥描述文件三者的组合关系缺一不可Xcode提示unable to sign时优先检查钥匙串里是否有对应的私钥。4.2 加急审核申请与上架时间线关于上架题目不是问审核流程而是问“什么情况下可以用加急审核App Review Expedite”。很多人的第一反应是“应用被拒后急着上线”但Apple一般不接受这种理由。加急审核的真实适用场景是应用涉及在线举办的时效性活动、支付通道即将过期、或者存在严重的线上漏洞需要紧急修复。申请时要在Request Accelerated App Review里说明业务影响、提供证据截图并给出可复现步骤并最好在提交申请后打客服电话同步工单号。我在答题时补充了自己的经验加急审核不等于免检甚至可能因为信息不完整被快速拒绝。如果时间真的非常紧同时建议准备TestFlight外部测试作为临时分发渠道但不代表能绕过App Store审核只是让真机验证和业务演示不阻塞。4.3 Charles抓包与HTTPS解密这道题要求描述“charles iOS抓包”的完整过程。我按环节拆分准备Mac端安装Charles开启Proxy Settings里的SSL Proxying并勾选Include位置添加*:443。iOS端WiFi手动代理指向电脑IP和端口8888初次抓包会提示安装证书需要在Safari打开chls.pro/ssl下载并安装到描述文件。根证书安装后还要在“设置-通用-关于本机-证书信任设置”里把Charles证书设置为完全信任。App侧如果App做了SSL Pinning直接抓包会失败。需要区分是证书锁定还是公钥锁定。证书锁定可以在Charles里换用Dynamic SSL Proxying加证书替换公钥锁定只能通过Hook或重打包绕过这个放到逆向层面讨论。笔试题有个延伸问题真机抓包连不上代理可能是什么原因我列了三点电脑防火墙拦截、同一WiFi但AP隔离、iOS的“本地网络”权限未打开。最后一个最容易被忽略。4.4 uniapp打包iOS测试包全流程小满这批题出现uniapp相关题目也在意料之中现在不少公司都是原生和跨端混用。题目是让简述“uniapp iOS app打测试包全流程”我是按真实操作顺序写的用HBuilderX云打包或本地离线打包。云打包需要先在manifest.json里配置AppID、Bundle Identifier并上传打包证书和描述文件。如果选择离线打包用Xcode打开SDK里的工程模板将uni-app生成的wgt资源或完整前端资源导入工程。证书配置与原生App一致开发阶段用Development证书测试包通常走TestFlight或蒲公英等分发平台。测试包打出来后如果只有企业证书或者个人开发者证书无法直接通过扫码安装到未注册的UDID设备要么加设备UDID到描述文件要么用TestFlight。这里有一个高频报错打包时配置了iOS的uni-push功能但后端未配置对应推送证书云打包虽然能出包但推送在真机调试时永远不成功。笔试给的场景正是“云端服务器返回错误当前应用打包时配置了ios uni-push功能但uni-push未配置io级别推送证书”。我答的排查路径是先在manifest里检查Push模块是否勾选再去开发者后台确认APNs证书的Bundle ID是否匹配最后看UniPush的AppID和AppSecret配置排查顺序不能乱。4.5 iOS混合开发方案选型混合开发题更像一道路线规划题。题目问“如果现有App要嵌入一套H5支付页同时要复用原生摄像头能力选什么方案”。我答的是原生WebView JSBridge 系统相机API的组合理由是这种需求强依赖原生能力纯H5方案在iOS上调用相机涉及私有API风险而纯Flutter/RN方案要在现有原生工程里引入整套引擎体量太大。这种题没有标准答案但出题人希望看到你评估风险的能力。我提到了WKWebView的MessageHandler和cookie同步问题、H5端调用相机的权限申请流程以及页面关闭时对JS端异步回调的引用释放。虽然答得比较零碎但这些细节才是日常调研中会踩到的点。5. 开放题与答题策略复盘想清楚比写得多重要5.1 测试回归题iOS设备模拟的边界笔试临近结束有一道关于测试策略的开放题在只有Mac没有真机的情况下怎么验证iOS 17.5新特性兼容性。我用的是Xcode的Simulator配合XCTest UI测试优先跑最关键流程同时用“通配符描述的模拟器”覆盖不同机型尺寸。但坦白讲模拟器不能替代真机的相机、推送和蓝牙。我答题时明确写了模拟器可以验证界面和数据流蓝牙、推送、后台定位、证书信任等必须靠真机。这题后面追问的是“为什么很多团队在iOS版本兼容性测试上翻车”。我提了一点iOS系统版本与硬件绑定严重老版本iPhone不能升级到最新系统新机型又带了很多旧机型没有的特性所以“低版本系统新硬件”这种组合只有在用户手里才有。笔试题能考到这个层面说明他们内部应该吃过这个亏。5.2 我的答题策略与时间分配整套笔试给的时长是120分钟体量并不少。我做题的时间分配大致是基础题45分钟工程化题35分钟开放题和检查30分钟最后留10分钟补充之前没写完整的答案。遇到过一道题不太确定我先写了关键词和方向等后面做完再回头补细节。这种策略笔试很管用不要在一道题上死磕先把整张卷子的得分点摸到。另外一点小心得如果是线上笔试建议把题目要求复制到本地笔记里边答题边留痕。尤其是像“charles ios抓包”这种流程题你的步骤顺序就是阅卷人判断是否真做过的重要依据。先写安装证书再写设置信任顺序反了虽然也能抓包但阅卷人一眼就知道你没跑通过。5.3 题目背后隐藏的能力坐标整份试卷写完我最大的感受是这批题目不在于难而在于全。它像一名iOS负责人的能力坐标轴横轴是语言基础、系统框架、UI/交互、网络、存储、并发、性能纵轴是开发、调试、打包、上架、运维、迭代。你只要在任何一个环节有真实项目的强化经验答起来都会比死背书顺畅很多。尤其那些工程化题比如“iOS开发者App证书更新”“加急审核地址”“TestFlight测试包全流程”如果只是看过博客没实操过很容易卡在“下一步该点什么”上。我建议今年准备春招的iOS岗位同学别只刷LeetCode和八股模板把一整个外包项目从创建到上架的链路亲手走一遍再回头做这套题会轻松很多。6. 踩过坑之后的几点备考建议笔试结束后我把自己答题卡上标注过“不确定”的点重新过了一遍发现不少地方其实和我日常开发中的习惯有关。比如UIStackView分屏的坑我虽然在项目里用过但从没主动在Compact宽度下测试再比如BLE连接参数我只知道选30ms、0延迟、5s超时却从没算过和连接间隔的倍数关系。备考与日常开发之间的差距往往就体现在这里。对正在准备iOS春招的同学我建议优先补这四块内存管理与RunLoop原理建议直接看objc4官方源码配合《Objective-C高级编程》那本小册子吃透weak、autorelease、runloop observer。系统状态机蓝牙授权、相机权限、定位权限这类“系统级与App级状态”的差异题多看Apple的About Privacy和WWDC Session。完整上架流程从申请证书到TestFlight外测再到App Store审核每一步动手过一遍别只看教程。跨端工程化uniapp或Flutter打包流程要了解现在很多岗位要求原生和跨端混合开发知道云打包、离线打包、推送证书配置是怎么回事就够用。笔试只是第一关面试大概率会顺着卷子里某道题继续追问到底层原理。如果时间有限最值得深挖的是weak的SideTable和RunLoop的observer回调时机这两个点几乎被所有iOS面试官偏爱我这次笔试个人感觉也是这两道题拿分最有底气。