面了100多个Unity开发岗，面试官总结了7条经验

《面试题目》

原帖是面试官视角的经验总结，正文没有逐场题目清单；文末附录给了 5 道初级/中级 Unity 岗最常被问到的技术题：

1. 什么是 GC？为什么在 Unity 里要小心它？
2. Draw Call 是什么？怎么减少它？
3. 协程和线程、异步有什么区别？什么时候用哪个？
4. UGUI 怎么减少重建和合批？
5. AssetBundle 打包有什么要注意的？

《核心观点》

原帖作者两个月面了 100 多位候选人，主要是初级和中级的 Unity 开发岗。他的核心判断是：技术差不多的两个人，一个聊 30 分钟就敲定、一个 5 分钟就知道没戏，差距通常不在代码能力，而在下面这 7 件事上。

1. 面试有周期，别拖也别等：公司招聘是一轮接一轮往前推的，从这一轮到下一轮通常间隔一到两周，HC（名额）不会停在原地等你。两个最常见的错误：一是慢吞吞准备两周才开始投简历，等准备好了名额已经被人填掉；二是面完一家最心仪的公司，就把手上其他面试全推掉、专心等这一个结果，两周后等来一句「没通过」，这段时间彻底浪费。可执行的做法是把自己也放进同样的节奏：手里始终同时推进 2~3 家，面完一家立刻继续投、继续面；以两周为一个周期做一次盘点（哪些还在流程里、哪些已挂、下一周期补什么），再决定是收网还是进入下一个周期。手上有并行选项，心态和谈条件的余地都会好很多。

2. 用数据说话，才算真正干过：同一件事，说「我做过性能优化，让游戏变流畅了」和说「主城场景 Draw Call 从 1200 降到 300，帧率从 28 提到 55」，后者才让人相信你真正动手测过、调过、验证过——只讲结论，面试官没法区分你是真做过还是看过教程。原帖给的做法：项目描述尽量带可量化数字（优化前后对比、包体减少多少、帧率与内存变化），记不清精确值就给量级（「从一千多降到三百左右」），并且平时做项目就养成记录数据的习惯，面试前临时补是补不出来的。可以再往前一步：面试官很可能顺着数字追问「你怎么测的」，所以优化类数据要能说清测量口径——Draw Call 看 Profiler 或 Frame Debugger，同时分清材质切换带来的 SetPass Call（它往往比 Draw Call 条数更影响 CPU 提交开销），内存分配看 Profiler 里 GC Alloc 的每帧数值，而不是凭感觉说「流畅了不少」。

3. 不会就说不会，别硬想 5 分钟：这是原帖最想强调的一条，因为它在真实面试里出现频率极高。遇到没思路的问题硬撑，沉默五分钟最后还是憋出一句「不太了解」，对双方都是纯损耗，还会额外留下「遇到问题不果断、不会止损」的负面印象。做法很直接：完全没有思路就坦白说「这块我之前没接触过」；有一半思路就先把有思路的那部分讲出来，再诚实地补一句「细节我需要查一下确认」。面试官看重的不是「你什么都会」，而是「你能不能快速判断、诚实表达」。「不知道」不是减分项，「不知道还装知道、还硬撑 5 分钟」才是。

4. 简历只写技术，不写作文大赛：面试官看一份简历的平均时间可能不到 30 秒，这 30 秒里他只想搞清楚一件事——这人到底能不能干活。奖项堆得越多越显得厉害是个错觉：初中作文大赛一等奖、大学辩论赛最佳辩手、运动会 4×100 米铜牌，和 Unity 岗位毫无关系，塞进去只会稀释真正有用的信息，还显得你「没有正经项目可写，只能拿这些凑数」。自检方法：简历只保留三块——技术栈、项目经历、作品/成果；每条项目经历统一写成「做了什么 → 用了什么技术 → 达到什么结果（尽量带数字）」；删掉一切与写代码、做游戏无关的奖项和经历，宁可留白也不要拿无关内容凑数。

5. 简历要可验证，每一行都要扛得住追问：第 4 条管的是「别写没用的」，这一条管的是「写上去的必须是真的、能说清的」。简历上写了「独立完成某游戏」，面试官一定会顺着追问：你具体负责哪部分？遇到过最难的问题是什么？怎么解决的？答得支支吾吾，前面写的内容全部变成负分，还不如不写。两类典型露馅：一是写「熟悉热更新」「精通 DOTS」「熟练 IL2CPP」，实际只是照教程跑过 Demo，三句就被问穿；二是简历写一套、面试说一套，对不上，整份简历的真实性都会被怀疑。自检方法是给每个技术关键词做「是什么 → 为什么用它 → 踩过什么坑」三连问，接不住就删掉或写淡。比如写了 IL2CPP 与内存管理，至少要能接住 GC 类提问：GC 回收的是托管堆上不再被引用的对象，在 Unity 里要小心它，是因为它会带来主线程停顿（STW，Stop-The-World），表现为卡顿尖刺和掉帧——Mono 下增量 GC 能把一部分回收工作分摊到多帧，IL2CPP 用的 Boehm GC 目前仍是完整停顿，尖刺更明显；对应的手段是少做装箱、避免高频 new、字符串拼接优先 StringBuilder、留意协程里每帧产生的托管分配，定位靠 Profiler 的 GC Alloc。写了 AssetBundle，就要能说出「AB 被卸载时它依赖的资源不会自动释放，容易泄漏」「LoadFromMemory 比 LoadFromFile 多一次内存拷贝、内存占用更高，优先 LoadFromFile」「Destroy 掉 GameObject 不等于卸载 AB 里的资源，实例和资源要分开管理」「Unload(true) 与 Unload(false) 的差异」「怎么拆包让加载峰值和内存可控」这类坑，而不是只会背 API。一句话：简历不是「我懂什么」的清单，而是「我能被验证什么」的清单。

6. 把思考过程说出来，而不是只给答案：面试更像一次模拟真实协作。听到问题就埋头想、想出来才说答案、想不出来就沉默，这是答题心态；而面试官真正想看的是你遇到问题会怎么拆、怎么查、怎么定位——毕竟上班后大部分问题本来就没有标准答案。所以遇到难题别闷头想，把脑子里的过程讲出来：「这个问题我之前没直接碰过，但我会先查 XX，怀疑是 YY 这块的问题，然后这样去定位和验证……」即使最后没给出答案，一条清晰的排查路径本身就是加分项。原帖举的典型反例是协程题：答「协程能异步执行、不卡主线程」是错的，反而暴露误解——协程本质是在主线程上按帧切分执行，不是真正的异步，适合「等一帧、等一秒、等资源加载完成」这类跨帧等待；真正耗时的计算（大量寻路、解压）放进协程照样卡主线程，得用 Job System、别的线程或分帧拆开；另外 yield return null 本身不产生托管分配，但频繁 new 自定义迭代器、用闭包迭代器会产生分配。同样的拆法适用于 UGUI 优化题：先拆成「重建」和「合批」两个问题——UI 元素变化会被标脏，触发 Layout、Graphic 重建，而同一个 Canvas 下只要有一个元素变了，就可能执行一次完整的 Canvas.BuildBatch 全量遍历合批，开销很大，所以核心是动静分离，把高频变化的动态 UI 拆到独立 Canvas 以缩小影响范围，并避免 Text 无意义的高频刷新；合批则要求材质、图集一致且渲染层级连续，Mask/RectMask2D 会强制打断合批要谨慎使用，再配合 Sprite 图集和合理的 Canvas 数量规划，定位靠 Profiler 看 Canvas.BuildBatch 耗时、Frame Debugger 看合批在哪里断开。会「说思路」的人，比会「背答案」的人值钱得多。

7. 面试最后的反问，决定你的天花板：几乎每场面试最后面试官都会问一句「你还有什么想问的吗」。这不是客套，而是给你的最后一次表现机会，也是最容易被浪费的一次——答「没有了」最亏，既放弃了了解对方的机会，也主动关掉了反客为主的窗口。要问有信息量的，而不是百度得到的：团队现在规模多大、主要做哪些项目；这个岗位招进来最想解决什么问题；项目现在处于立项、研发中还是准备上线；团队的技术栈和工具链是怎么样的。别问「薪资多少」「加班多吗」这类——要么面试官不方便说，要么问了显得你只关心待遇。数量上 1~3 个就够，问得好比问得多更重要；最后这一问问的是你的上限，不是面试官的下限。

这 7 条里没有一条直接考「C# 写得多溜」，但它们恰恰是 100 多场面试里区分「能过」和「不能过」最明显的分水岭：技术决定下限，这 7 件事决定你能不能把上限展示出来。串起来就是——简历上只写技术且每一行都扛得住追问，节奏上按周期并行推进，临场上不会就直说不会、会就把思路讲出来，加分靠数据说话，最后用一到三个反问把团队和岗位问清楚。