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

最近两个月，我陆陆续续面了 100 多个同学，主要是初级和中级的 Unity 开发岗位。面得越多，越发现一个问题：大部分人不是技术不行，是「面试」这件事本身没做好。

技术差不多的两个人，一个可能 30 分钟就敲定，一个聊完 5 分钟就知道没戏。差距往往不在代码能力，而在下面这 7 件事上。

1. 面试有周期，别拖也别等

这条很多人完全没意识到，但它直接决定你能不能「赶上趟」。

公司面试是有周期的，一轮面试到下一轮，大概一周到两周。这意味着什么？意味着：

• 别拖拖拉拉。 你这边磨磨蹭蹭准备个两周才投简历，那边的 HC（名额）可能已经被人填了。

• 别干等一个结果。 最坑的操作是「面了一家特别心仪的，然后把手头其他面试全推了，专心等它」。结果那家两周后才回你「没通过」，你这两周就白白浪费了。

该怎么做：

• 自己也按两周一个周期来安排面试节奏，手里始终同时推进 2-3 家。

• 面完一家，别停，继续投、继续面，这一轮周期结束后，再决定下一步，是选择还是继续下一个周期。

2. 有数据支撑，才叫真正干过

这条是加分项，也是拉开差距的关键。

面试里，两个人说同一件事，效果天差地别：

• A：「我做过性能优化，让游戏变流畅了。」

• B：「我做过性能优化，把主城场景的 Draw Call 从 1200 降到 300，帧率从 28 提到 55。」

哪个更像「真干过」？显然是 B。

因为你光说结论，别人没法判断你是真做了，还是只是看过教程、听人讲过。 有了数据，就证明你真正动手测过、调过、验证过，这叫「有理有据」。

该怎么做：

• 项目经历、项目描述，尽量带上可量化的数字：优化前后对比、包体减少多少、帧率提升多少、内存降了多少。

• 哪怕记不清精确数字，给个量级也比没有强（「从一千多降到三百左右」）。

• 平时做项目就养成记录数据的习惯，不然面试时想补都补不出来。

3. 不会就是不会，别硬想 5 分钟

这是我最想强调的一条，因为它在真实面试里出现的频率实在太高了。

很多同学遇到一个没思路的问题，第一反应是「我不能直接说不会，那样显得我很菜」，于是开始硬想。然后沉默了 5 分钟，最后还是憋出一句「这个……我不太了解」。

这 5 分钟，对双方都是纯损耗——你紧张，面试官干等，时间过去了，结论还是「不会」。更糟的是，这 5 分钟的沉默会让面试官产生一个负面印象：「这人遇到问题不果断，不会止损。」

该怎么做：

• 如果一点思路都没有，直白点，直接说：「这块我之前没接触过，不太了解。」

• 如果有点思路但不完整，就说出你有思路的那部分，再诚实补一句「细节我需要查一下」。

• 面试官看重的不是「你什么都会」，而是「你能不能快速判断、诚实表达」。

记住：「不知道」不是减分项，「不知道还装知道、还硬撑 5 分钟」才是。

4. 简历只写技术，不写「作文大赛」

这条是最容易踩、又最不该踩的坑。

简历最忌讳的是贪多。很多人觉得「奖项越多显得我越厉害」，于是把初中作文大赛一等奖、大学辩论赛最佳辩手、运动会 4×100 米铜牌全往上堆。

但你要清楚一件事：面试官看一份简历的平均时间，可能不到 30 秒。 这 30 秒里，他只想搞清楚一件事——「这人到底能不能干活」。你塞一堆跟 Unity 无关的内容，只会稀释真正有用的信息，还显得你「没啥正经项目可写，才拿这些凑数」。

该怎么做：

• 只写三块：技术栈、项目经历、作品/成果。

• 项目经历按这个格式写：做了什么 → 用到什么技术 → 达到什么结果（最好带数字）。

• 删掉一切跟「写代码、做游戏」无关的奖项和经历。无效内容不如不写，空着都比乱写强。

反面教材：「2019 年校级作文大赛一等奖」。 面试官内心：这跟我招的 Unity 岗位有什么关系？

5. 简历要可验证，每一行都要能扛住追问

这一条和第 4 条是配套的，但坑更深。

第 4 条说的是「别写没用的」，这一条说的是「写上去的，都必须是真的、能说清的」。

面试官最怕的不是你简历写得简单，而是写得天花乱坠、一问细节就露馅。你写「独立完成了 XXX 游戏」，面试官就一定会顺着追问：你具体负责哪部分？遇到过最难的问题是什么？怎么解决的？如果支支吾吾答不上来，前面写的全是负分——还不如不写。

更典型的还有两种「露馅写法」：

• 写「熟悉热更新」「精通 DOTS」「熟练 IL2CPP」，结果一问就是「看教程跑过 Demo」的水平，三句就被问穿。

• 简历写一套，面试说一套，对不上，面试官立刻怀疑整份简历的真实性。

该怎么做：

• 简历上每一个技术关键词，都要能经得起「是什么 → 为什么用它 → 踩过什么坑」三连问。

• 写你会的东西，别写你「听过的」东西。不会的不写，不丢人；写了被问死，才尴尬。

• 投出去之前，自己对着简历逐行问一遍：这行要是被追问，我能接住吗？接不住就删掉或改淡。

一句话总结：简历不是「我懂什么」的清单，是「我能被验证什么」的清单。

6. 主动暴露你的思考过程，而不是只给答案

面试不是考试，是一场「模拟真实协作」。

很多同学把面试当成刷题：听到问题就埋头想，想出来就说答案，想不出来就沉默（然后就踩了第 3 条的坑）。

但面试官真正想看的，不是你答没答对，而是「你这人遇到问题会怎么拆、怎么查、怎么定位」。因为上班以后，大部分问题本来就没有标准答案，看的就是你的思路。

该怎么做：

• 遇到难题，别闷头想，把你脑子里的思考过程说出来：「这个问题我之前没直接碰过，但我会先查 XX，怀疑是 YY 这块的问题，然后这样定位……」

• 哪怕没想出来最终答案，一套清晰的排查思路本身就是加分项。

• 面试官要的是「跟这个人一起干活是什么体验」，不是「他背了多少标准答案」。

一句话总结：会「说思路」的人，比会「背答案」的人，值钱得多。

7. 面试结束要问问题，这决定了你的天花板

几乎每场面试最后，面试官都会问一句：「你还有什么想问的吗？」

这句话不是客套，是给你的最后一次表现机会，也是最容易被浪费掉的机会。

很多人答「没有了」——这是最亏的。因为你不但放弃了了解对方的机会，还主动关掉了「反客为主」的可能性。反过来，问得好，能瞬间拉开你和别人的差距。

该怎么做：

• 问点「有信息量」的，而不是「能百度到的」：

• 「咱们团队现在规模多大？主要做哪些项目？」

• 「这个岗位招进来，最想解决什么问题？」

• 「项目现在处于哪个阶段？立项、研发中，还是准备上线？」

• 「团队的技术栈和工具链是怎么样的？」

• 别问「薪资多少」「加班多吗」这种——要么面试官不方便说，要么问了也显得你只关心待遇。

• 问 1-3 个就够，问得好，比问得多更重要。

一句话总结：最后这一问，问的是「你的上限」，不是「面试官的下限」。

附：面试官视角 Q&A（几个高频题的「好回答 vs 差回答」）

前面说的都是「怎么面试」，这里补几个具体的技术题。以下都是初级/中级 Unity 岗最常被问到的，我给你对比一下「差回答」和「好回答」，你能直观感受到差距在哪。

Q1：说说什么是 GC？为什么 Unity 里要小心它？

• 差回答：「GC 就是垃圾回收，会自动清理内存。没了。」——答了等于没答。

• 好回答：「GC 是托管堆上回收不再被引用的对象。Unity 里要小心它，是因为 GC 会造成主线程停顿（STW，Stop-The-World），产生卡顿尖刺、引发掉帧。Mono 下支持增量 GC，能把一部分回收工作分摊到多帧；而 IL2CPP 用的是 Boehm GC，目前是完整的 STW 停顿，尖刺更明显。所以我平时会注意：少用会装箱的操作（老版本 foreach、把值类型塞进 object）、避免频繁 new、字符串拼接优先 StringBuilder、高频协程留意每帧 new 产生分配。定位用 Profiler 的 GC Alloc 那一栏，看每帧托管内存分配了多少。」

关键点：不止背定义，还要落到「为什么在 Unity 里是问题（STW 停顿）」+「Mono 增量 vs IL2CPP 完整停顿」+「你怎么处理」。

Q2：Draw Call 是什么？怎么减少它？

• 差回答：「Draw Call 就是 CPU 提交给 GPU 的绘制命令，越少越好。」——只背了半句。

• 好回答：「Draw Call 是 CPU 通知 GPU 绘制一批几何体的命令，它本身不是问题，多了才会加重 CPU 提交开销；其中材质切换带来的 SetPass Call 上涨往往比 DrawCall 本身更影响性能，很多人会混淆这两个。减少手段我常用几个：静态物件开启静态合批；大量重复物件用 GPU Instancing；URP 管线善用 SRP Batcher 降低 CPU 提交开销；UI 依靠 Canvas 合批；图集打包减少纹理切换打断合批；减少材质种类；UI 别把 Canvas 拆得过于零碎。优化前后我用 Frame Debugger 重点看 SetPass Call，或 Profiler 里的 DrawCall 数量做对比。」

关键点：能说出「不是 DrawCall 本身坏、是 CPU 瓶颈」，再分清 DrawCall 和 SetPassCall，比单纯背定义强一个档次。

Q3：协程和线程/异步有什么区别？什么时候用哪个？

• 差回答：「协程能异步执行，不卡主线程。」——这是错的，反而暴露了误解。

• 好回答：「协程本质是在主线程上、按帧切分执行的，它不是真正的异步，也不会自动跑到别的线程。适合『跨帧等待』的场景，比如等一秒、等一帧、等一个资源加载完成。真正的耗时计算（比如大量寻路、解压）放协程里照样卡主线程，那种要么用 Job System / 别的线程，要么想办法分帧拆开。另外注意：普通的 yield return null 不会产生 GC 分配，但频繁 new 自定义 IEnumerator 迭代器、或用闭包迭代器时会产生托管分配，高频创建协程要留意。」

关键点：这道题最能区分「真懂」和「背过」。说协程『不卡主线程』的直接扣分；能把 yield 的分配场景说准，是加分项。

Q4：UGUI 怎么减少重建和合批？

• 差回答：「用 Canvas，别用太多 Image。」——太模糊。

• 好回答：「可以分成重建（Rebuild）和合批（Batch）两个问题。重建：UI 元素发生变化会被标记为 Dirty，触发 Layout、Graphic 重建；即便只有一个元素变了，同一 Canvas 也会执行一次完整的 Canvas.BuildBatch 全量遍历合批，开销很大。所以核心做法是动静分离——把静态 UI 和高频变化的动态 UI 放到不同 Canvas，缩小 BuildBatch 的影响范围；另外避免 Text 无意义高频刷新。合批：只有材质、图集相同、且渲染层级连续才能合批；Mask/RectMask2D 会强制打断合批，需要谨慎使用。我会把 UI 资源打成 Sprite 图集减少材质切换，合理规划 Canvas 数量。定位问题用 Profiler 看 Canvas.BuildBatch 耗时，或 Frame Debugger 看哪里发生了合批断开。」

关键点：「分 Canvas 缩小 BuildBatch 范围 + 打图集 + 知道 Mask 断批」这几句一出来，就知道你是真优化过 UI 的。

Q5：AssetBundle 打包有什么要注意的？

• 差回答：「就是打包资源，加载用 AssetBundle.LoadFromFile。」——只会 API。

• 好回答：「我主要关注几个点：一是依赖关系，同一个资源被多个 AB 引用时要注意重复打包，通常抽公共依赖包或靠打包工具自动处理；而且 AB 被卸载时，它依赖的资源不会自动释放，容易造成内存泄漏。二是加载方式，优先 LoadFromFile，尽量避免 LoadFromMemory——它除了内存占用高，还会产生额外内存拷贝。三是卸载时机，要分清实例对象和 AB 资源本身，理解 Unload(true) 和 Unload(false) 的差异；Destroy 掉 GameObject 不等于卸载 AssetBundle 资源，资源卸载要单独管理。四是版本热更与拆包粒度。实际项目里我更在意『怎么拆包让加载峰值和内存可控』，而不是只会调 API。」

关键点：API 谁都会背，能说出「依赖不自动释放、LoadFromMemory 拷贝、Destroy≠卸载资源」这些坑，才是真项目经验。

最后

这 7 条，没有一条跟「你 C# 写得多溜」直接相关，但它们恰恰是 100 多个面试里，区分「能过」和「不能过」最明显的分水岭。

技术决定你的下限，这 7 件事决定你能不能把自己的上限展示出来。

简单再串一遍： 简历上——只写技术（第 4 条），写的都要能扛追问（第 5 条）； 节奏上——按周期推进，别拖别等（第 1 条）； 临场上——不会就说不会（第 3 条），会就暴露思路（第 6 条）； 加分上——用数据说话（第 2 条），最后问出你的上限（第 7 条）。