字节跳动2018校招iOS方向第四批这个题目放在今天看仍然值得聊。当时这一批题在求职群里传得很广不少人都说“有点东西”因为它不是单纯背概念就能过的大量题目都指向同一个核心你对iOS整个系统链路到底理解到什么程度。哪怕你不准备面试单纯把这套题当成一份基础能力自检清单也会发现很多自己平时没注意的盲区。先说结论这套题考察的不是“你会不会用某个API”而是“遇到线上问题你怎么定位、怎么设计、怎么优化”。内存管理、UI渲染、并发线程、启动链路、架构设计这几个模块基本覆盖了客户端开发的硬核部分。适不适合你如果你正在准备大厂iOS面试或者已经工作两三年但感觉自己停留在“接口调用工程师”的阶段这篇文章值得认真看一遍。1. 这套题的含金量一场围绕“App流畅与稳定”的系统体检1.1 我们说的“第四批”到底考察什么2018年字节跳动校招iOS方向分了好几个批次第四批之所以被单独拿出来讨论是因为它的题目风格和前三批有明显差异。前三批还有一些常规的基础题、算法题到了第四批算法的比重下降移动端特有的深度题明显增加尤其是内存、渲染、线程、启动这几条主线。我当时找参加过这批笔试的同学聊过大家一致的感受是题目不难读懂但每一道都像在问你“你平时写代码的时候到底有没有想过底层发生了什么”。比如让你分析一个界面卡顿的成因不是让你说“主线程别做耗时操作”这种表面话而是要把CPU、GPU、图层合成、RunLoop这几个环节串起来讲清楚。这种考察方式本质上是在筛选那些真正对技术有好奇心、愿意往底层钻的人。还有一个特点是“场景化”。题目很少直接问“什么是Block”而是给你一段代码问这段代码会不会循环引用为什么怎么改。这种问法比单纯背定义要难得多因为你得真正理解捕获变量的机制、对象持有关系、以及整个生命周期。1.2 为什么字节跳动考得这样“重”与“深”要理解这套题为什么这么设计得回到当时的业务背景。2018年正是今日头条、抖音高速增长的时候客户端团队面对的最大挑战就是用户量巨大、机型碎片化严重、线上问题复现难。一个内存泄漏在开发机上可能根本感觉不到但在低端机上就会导致闪退一个在主线程上的小操作在用户滑动时就会变成肉眼可见的掉帧。所以客户端团队对候选人的要求不是“能写界面”而是“能保证这个App在千万级用户手里不出问题”。这就必须懂底层的运行机制知道内存从哪里来、到哪里去知道一个视图从布局到显示经历了哪些步骤知道多线程并发时数据怎么保证安全。这批题就是在为这个目标筛选人。另外一个隐含点在“架构能力”。2018年头条的App已经是超大型客户端模块间如何解耦、页面间如何通信、基础组件如何沉淀这些已经不是靠个人英雄主义能解决的需要成体系的架构设计能力。所以你会发现题目里会出现“如何设计一个网络层”这类开放题没有标准答案考察的就是你的设计思路、边界考虑和工程权衡。2. 最核心的记忆点内存管理为什么值得反复考2.1 从一道retain cycle题目说起内存管理在第四批里出现的频率非常高基本每种题型都会捎带考一点。典型的一道题是这样一个ViewController持有一个BlockBlock内部又使用了self问你这里会不会循环引用如果会怎么解决。很多同学第一反应是“用weakSelf”但题目往往紧接着会问如果Block里有一个dispatch_after延时2秒执行你用了weakSelf那2秒后self已经被释放了这段代码还会执行吗这里就涉及Block对weak变量的捕获时机。实际上在Block内部weakSelf会被重新声明成一个强引用防止执行过程中对象被提前释放但如果延时结束后对象已经不在这个强引用就是nil代码照样执行只是拿不到你想要的对象。这个问题要回答完整得先讲清楚强弱共舞weak-strong dance的写法。这种题看似在考语法实际上在考 “引用计数” 这个模型本身。我建议每个iOS开发都把引用计数背后的数据结构弄清楚不光是面试对排查线上循环引用也有直接帮助。2.2 weak到底做了什么顺着上面这道题往下挖面试官可能追问weak的实现原理是什么这里有几个层次要答清楚。第一层weak修饰的变量不会增加对象的引用计数对象释放后weak变量会自动置为nil这是为了安全防止野指针。第二层Runtime维护了一张全局的weak表实际上是一个哈希表key是对象地址value是一个数组存着所有指向这个对象的weak指针地址。对象释放时Runtime会通过这张表找到所有weak指针把他们全部置为nil然后再清理这个表。第三层这也是最容易忽略的对象释放的过程中会调用objc_clear_deallocating这个操作涉及哈希表的查询和修改是有开销的。如果大量对象频繁创建、释放且都使用了weak这个哈希表操作会成为性能瓶颈。所以在高性能场景下不是所有地方都适合无脑用weak有时候用unsafe_unretained配合自己管理生命周期反而更快当然风险也更大。平时排查循环引用时Xcode的Instruments里有Leaks工具但Leaks模板对Block循环引用有时候检查不出来更好用的方式是Xcode 8之后加的Memory Graph能看到对象之间的持有关系直接找到环在哪。2.3 autoreleasepool与高并发释放另一道让我印象深刻的题是关于autoreleasepool的。题目大概是在主线程RunLoop的某个循环里大量创建临时对象内存峰值飙升怎么解决。这题考的是对自动释放池机制的理解。iOS主线程的RunLoop在每次事件循环开始前会自动创建autoreleasepool循环结束后统一释放。但如果在一次事件循环里创建了海量对象就会全部堆积到这个池子里等这轮结束才释放内存峰值自然会高。解决办法通常是在循环体内手动插入autoreleasepool块让临时对象及时释放。这个做法在写图片处理、数据库大批量导入这类逻辑时非常关键。我做音视频相关的功能时每一帧解码出来的数据如果不包在autoreleasepool里释放十几分钟就能看到内存涨到几百兆。相反包上之后内存能稳定在一个很低的水平。要注意的是autoreleasepool块本身也有开销不能不分场合地滥用。最佳实践是放在明显的循环体里而不是给每个方法都裹一层。2.4 这一部分答题思路与实操建议内存管理类题目无论怎么变形核心答题框架建议围绕三条线展开一是引用计数模型本身说清楚对象生命周期二是实战工具链说明你怎么用Memory Graph、Malloc Stack定位问题三是性能意识说明哪些方案有额外开销、怎么权衡。这三条线里最容易被看出水平的是最后一条。能说出“weak有哈希表操作成本”“autoreleasepool有创建成本”的候选人和只会背概念的人在面试官心里的分量完全不一样。平时写代码的时候可以刻意培养这种成本意识每用一个机制都想想它背后付出了什么代价。3. 渲染与流畅度UI性能优化的实战细节3.1 离屏渲染产生在哪几个环节UI渲染类题目在第四批里也占了不少分量其中最常被问到的就是离屏渲染。题目通常这样问哪些操作会触发离屏渲染怎么避免常规答案是圆角、阴影、mask等。但更深入的考察点是为什么这些操作会触发离屏渲染。这就要理解GPU的渲染管线了。正常情况下GPU把图层直接渲染到当前的framebuffer这个相对便宜。但设置圆角加maskToBounds、或者加阴影后GPU没法在一个pass里完成绘制需要先把内容渲染到一块额外的离屏buffer里做一些处理后再合成到主buffer这个切换上下文的操作非常昂贵在滚动场景下就是掉帧的元凶。这里有个常见的误区很多人以为所有圆角都会触发离屏渲染。实际上只有当圆角、边框、mask这几个条件组合触发时才会离屏渲染。单独设置cornerRadius如果contents没有内容或者layer没有额外的背景和边框有时候不一定触发。真正100%触发离屏渲染的组合是cornerRadius maskToBounds YES 有contents内容。这个细节我在面试里聊过几次说出来之后对方通常会眼前一亮。3.2 从图层合成到“避免卡顿”的最佳实践要理解渲染优化还得讲清楚Core Animation的渲染流程。App侧通过Core Animation提交layer树然后Renderer进程会把这棵树转成渲染树再交给GPU去做合成。RunLoop在beforeWaiting和exit阶段会去处理CATransaction把这一帧的改动打包提交。这里面有一句话很重要iOS的渲染不完全是App进程内的事Core Animation的提交只是第一步后面的渲染是在独立的渲染进程里完成的。所以当你的界面掉帧不一定完全是主线程卡了也有可能是因为离屏渲染导致GPU压力过大。排掉帧问题的时候不只是看主线程耗时还要用Core Animation Instruments看GPU的渲染耗时。优化手段按优先级排序第一能用图片素材代替的就不让系统做实时计算第二必须用圆角的地方用Core Graphics预裁剪一张带圆角的图而不是直接设置layer属性第三控制图层数量避免超复杂层次的视图嵌套尤其要避免在滚动视图里使用大量半透明图层叠加半透明意味着每帧都要做混合计算。3.3 自绘UI方案与异步渲染头条当年的思路2018年这批题还有一个隐藏考点就是异步渲染和自绘UI。为什么考这个因为头条App对流畅度要求极高列表滚动必须做到接近满帧。在那个年代系统控件在复杂页面下效果有限所以团队很早就开始做自绘方案。自绘的思路其实不难不依赖系统的UIView层级而是用一个自定义的绘制引擎把文本、图片、布局信息直接绘制到一个bitmap上再把这个bitmap一次性贴到屏幕。这样做的好处是大幅减少视图层级把CPU、GPU的压力都降下来。对应的开源方案就是后来大家熟知的TextureAsyncDisplayKit。我当时研究过一段Texture的源码核心就是把UIView的创建、布局、绘制都挪到后台线程做主线程只做最终提交。这套题考自绘问的角度往往是“为什么自绘能提升流畅度”。要答好这个问题得理解UIKit的性能瓶颈。UIView层级里每一个view都有frame计算、Auto Layout约束、图层对象、渲染提交等开销。层级一多主线程消耗就大。而自绘相当于跳过了中间的大量系统调用直接用底层的绘制能力。这个思路到今天依然有效SwiftUI里的Canvas、以及一些高性能列表方案本质上都是在走这条路。4. 并发与线程安全从死锁题到锁的实现4.1 典型场景锁、信号量与队列之间的选择并发类题目在第四批里出现的形态非常实操不是问你“什么是线程”而是给你一个多线程访问共享资源的场景让你设计线程安全方案。最基础的方案是加锁。iOS里常见的锁有NSLock、NSRecursiveLock、os_unfair_lock、synchronized、dispatch_semaphore等。这里最关键的不是把名字都背下来而是你得知道它们的性能差异和适用场景。比如os_unfair_lock在iOS 10之后是最轻量级的锁但它不支持递归如果在递归函数里用它会直接死锁。NSLock内部其实也封装了一个底层锁性能也不错。dispatch_semaphore虽然名字叫信号量但把value设为1时就是一个二元锁性能同样很好。实际工程里我更推荐优先考虑不共享状态其次才考虑锁。比如用串行队列来保护一块资源读操作和写操作都丢到同一个队列执行从根本上避免竞争。这个方法简单、不容易出错而且性能在大多数场景下都够用。我把这种思路总结成一句能用GCD队列解决的不上锁能上锁的不搞自旋能单例的不搞全局变量。4.2 GCD死锁与队列分析另一道经典题在主队列调用dispatch_sync会怎样答案是死锁。原因很简单主队列是串行队列你把一个同步任务添加到主队列这个任务要等前面所有任务执行完才执行而前面的任务正在等你这个任务完成互相等谁也别想跑。但有一些变体容易看走眼比如在主线程执行dispatch_sync到另一个串行队列此时该队列正在执行别的任务是不是死锁这种情况下如果两个队列不是同一个而且目标队列不在执行中通常不会死锁但如果在同一队列内部sync自己那就铁定死锁。面试里这类题目的陷阱就在于“队列”和“线程”很容易被搞混你需要先把这几个概念理清楚线程是执行任务的载体队列只是把任务按顺序排队的管理者。串行队列不等于主线程全局并发队列也不等于多线程。排查死锁问题最实用的工具就是Xcode的Thread Performance Checker以及断点时的线程堆栈看每个线程卡在哪个调用上基本能找到死锁的双方是谁。死锁的出现往往不是单个队列的问题而是多个队列互相等待把堆栈一对比真相就出来了。4.3 线程安全设计模式与读写锁如果题目继续加深还会问读写锁。比如有一个配置表读多写少怎么保证读操作能并发、写操作独占这时候就需要pthread_rwlock_t或者用GCD的barrier来实现。用GCD的dispatch_barrier_async有个细节barrier block必须提交到自定义的并发队列上才会生效如果提交到全局并发队列行为是未定义的可能不会起到拦截效果。这是我踩过坑的地方当时在全局队列上用了barrier结果发现读写会同时执行最后查文档才知道这个前提。写线程安全代码我的经验是能用不可变对象就用不可变对象能用纯函数就用纯函数实在要共享可变状态就把所有访问集中到一个类里用统一的队列或锁保护千万别让状态散落到各个页面里。这样设计的好处是将来出问题的时候你只需要审查一个类而不是全项目搜索某个属性的所有引用点。5. 启动优化与架构从“用户点击图标”到“首帧”5.1 启动链路拆解启动优化这道题在2018年的第四批里属于拉开差距的题。题目通常问App启动时间过长你怎么定位和优化。要答完整需要把启动阶段从底层到上层一条链撸清楚。从用户点击图标开始系统内核创建进程加载主二进制文件然后dyld开始动态链接加载所有依赖的动态库再执行各类初始化。大概的启动过程是dyld启动、加载动态库、Rebase和Bind、ObjC的Runtime初始化、执行所有类的load方法、然后调用main函数、UIApplicationMain启动RunLoop最后AppDelegate的didFinishLaunchingWithOptions执行完第一帧渲染出来。这中间每一段都可以优化。最常见的优化点减少动态库数量合并一些组件删掉不必要的load方法load方法里尽量不做复杂操作因为它在main之前执行把didFinishLaunchingWithOptions里的逻辑按优先级拆分不重要的延迟到首帧渲染之后再执行检查启动时创建了哪些大对象、初始化了哪些全局单例能懒加载的全部懒加载。5.2 二进制重排与load方法2018年之后很多大厂还在卷一个技术叫二进制重排。原理也不复杂dyld做符号绑定时需要处理Rebase指针和Bind符号。App启动时页错误page fault是主要耗时点之一如果关键启动路径上的代码分散在不同页里就会频繁触发缺页中断。二进制重排就是把启动时需要执行的函数重新排列到同一个内存页里减少page fault次数。虽然这套题是2018年的但二进制重排的思路在2019年后才在业界大量普及说明那批面试官其实是在考察你对底层机制的理解而不是考一个具体技巧。如果你能说出“启动慢和page fault有关”在面试里就已经超过大多数候选人了。另一个和老生常谈相关的点是load方法。load方法在main之前执行且所有load方法都执行完才执行main一个load方法写了几百毫秒启动时间就会被直接拖几百毫秒。所以现在主流做法是用initialize或者dispatch_once代替load。很多第三方SDK会在load里做方法交换这就是启动变慢的隐形元凶。5.3 从架构题看App的模块化与解耦第四批里还有一类开放题比如“如何设计一个网络层”“如何对现有工程做组件化”这类题没有标准答案考察的是你的工程视野。设计网络层我的回答框架一般是底层封装一个基于NSURLSession的统一请求入口支持GET、POST、上传、下载中间层做参数签名、公共头、加密、缓存策略上层提供业务友好的接口比如泛型回调、请求自动关联页面生命周期。关键是让业务方不直接接触底层网络API而是通过中间层隔离方便做统一监控和容灾。组件化题更现实的问题是怎么让模块间不直接依赖。常见的方案是通过协议Protocol做解耦或者用路由表以URL形式注册模块能力。但做组件化一定是为了解决真实痛点而不是为了架构而架构。如果我看到一个人一上来就说“我们要上路由”我通常会反问你的模块间依赖到底是什么有多少个模块互相引用了对方的类如果你能拿出数据说明痛点这个架构方案才立得住。6. 典型面试题实战梳理一份可直接抄的答题模板6.1 用“场景-原理-方案”三步法作答刷完第四批的题我最大的体会是面试官要的不是你背答案而是你有一套稳定的思考框架。我自己总结了一个三步法先讲清场景再讲原理最后给方案。比如问到“某页面滑动卡顿”第一步描述场景列表在快速滑动时帧率掉到40FPS左右在低端机上尤其明显。第二步分析原理列表Cell层级太多、图片无缓存导致每帧解码、主线程有大量离屏渲染这些都会拖慢渲染提交。第三步给方案减少Cell视图层级、提前对图片裁剪和缓存、把文字和富文本的绘制放到异步线程、用Instruments验证每一帧的耗时分布。这个框架最大的优势是让你的回答有结构哪怕遇到没准备过的题也能顺着场景、原理、方案这条线把自己的知识组织起来不会语无伦次。6.2 从崩溃堆栈到“逆向题”的破题角度有一类题很考验实战经验给你一个崩溃日志让你分析Crash原因。这类题不是考你背诵而是考你会不会看堆栈。看到崩溃日志我的习惯是先从异常类型看起是EXC_BAD_ACCESS还是SIGABRT还是SIGSEGV每一种对应的原因方向不同。EXC_BAD_ACCESS大概率是野指针或访问了已释放对象SIGABRT往往是断言失败或者系统检测到异常。第二步看崩溃线程的堆栈找到最后几个调用栈是系统库还是自己代码。第三步如果是内存错误还需要结合Malloc Stack和Address Sanitizer复现。我当时遇到一个很难复现的Crash反复看了很久堆栈才发现是某个Block被提前释放了但另一个对象还持有这个Block的引用回调时直接野指针。后来用Address Sanitizer把复现开关打开一下就定位到了。这块没有捷径平时多积累经验。我建议每隔一段时间就翻一翻线上崩溃平台的数据不要只看总量要看堆栈的变化和出现频率慢慢你就有了对Crash的直觉。6.3 现场手写代码时容易忽略的边界第四批也包含手写代码题一般是现场实现一个多线程安全的数组或者用GCD实现一个“可以取消的异步任务”。这种题重点不在算法难度而在边界考虑。写线程安全容器时最容易忘的点是枚举时能否修改容器、传nil参数时怎么办、类型不一致时怎么办。好的代码在这些边缘情况上有明确行为。比如我在实现一个线程安全的字典时除了加锁保护读写还会保证返回的副本不暴露内部可变对象避免外部拿到引用后绕过锁去修改。现场写代码还有一个常见问题写得很快但没检查方法签名是否完整或者忘记考虑调用场景。我的建议是写完不要急着说“好了”花30秒从头读一遍把自己当成调用方看看接口设计是否合理、有没有潜在的数据竞争。7. 复盘这套题后我建议你补的几块硬实力7.1 现在再回头看哪些知识依然不过时这套2018年的题放在今天回头看里面的技术点非但没有过时反而因为Swift和系统框架的迭代变得更加重要。内存管理依然是Swift下循环引用的常见问题渲染优化在SwiftUI高刷屏时代更加关键启动优化被各大厂商卷出了更多玩法。真正过时的可能只有具体的API。比如那会儿还在用UIWebView和WKWebView的取舍今天WKWebView已经是一统天下还可能涉及到JavaScriptCore、或者WebKit的一些新特性。但底层的思想——渲染链路、内存模型、并发模型——这些是iOS的根基不管上层怎么变根基都还在。所以如果你现在准备大厂面试与其去刷一堆“最新框架怎么用”不如先把这几个硬骨头啃透引用计数与内存结构、RunLoop与渲染链路、GCD与线程安全、启动与链接过程。这四个模块适用于任何年份的iOS面试。7.2 学习方法建议针对这套题的风格单纯刷题效果有限真正有效的是“带着问题读源码”。比如你用了很久的weak就去看objc源码里的weak实现你天天用RunLoop就去看CFRunLoop的源码你被离屏渲染坑过就去搜一下Core Animation的渲染文档弄明白为什么圆角要离屏渲染。读源码不是让你把每一行都看懂而是抓主线。比如读weak实现你只需要找到objc_initWeak、objc_storeWeak、objc_clear_deallocating这几个关键方法就能把整个机制串起来。读完这些之后面试里的追问基本就问你不住。我还有一个习惯每解决一个线上问题就把它整理成一份小的技术报告包含现象、排查过程、根因、修复方案、预防措施。这个习惯坚持下来你的经验就不再是零散的而是一条可复用的知识链。面试时候讲一个你自己排查过的线上问题比任何背诵都更有说服力。7.3 踩坑记录最后分享几个我自己在这类准备过程中踩过的坑希望你能避开。第一个坑只背概念不求甚解。我早年准备面试时也背过“weak会自动置nil”但真被问到为什么能置nil时就答不出来了。从那时起我改了学习方式每个知识点一定追到底层实现哪怕只是大概理解也比只会结论强。第二个坑忽略性能分析工具。很多题目如果你会说“用Instruments分析”已经能得不少分。但如果想拿高分一定要真正会看Instruments的Time Profiler、Core Animation、Leaks这几个模板能对着截图讲出每一列的含义、每一个颜色条代表的意义。面试官只要多追问一句“具体怎么看”是不是真用过就暴露了。第三个坑只准备热门技术不重视基础。有一段时间客户端特别流行跨端方案很多人的精力都去研究新东西了结果连引用计数都讲不清。但你看第四批这套题它不追热点就考基础因为基础决定了你能走多深。新框架可以学但基础永远不能丢。按这套思路去准备收获的不只是一份Offer更是对iOS这套系统真正的掌控感。