那年4月，我投了畅游的游戏开发补招，收到笔试链接后一口气做了三个小时。整套题不像统招题那样偏基础，它把C++、数据结构、Unity引擎、图形学、性能优化全揉在一起，考的全是“能不能直接进项目干活”的底子。后来我自己也参与过游戏开发岗位的招聘，才发现这类题筛选的从来不是背过多少知识点，而是排查问题和动手调试的思维习惯。如果你正在准备游戏开发岗，无论是应届生还是半路转行，这套题都值得认真复盘一遍。
1. 补招试题的整体设计与考点地图
1.1 为什么补招题比统招更“硬核”
2017届补招和秋招最大的区别是时间点。秋招还有充足时间搞培养，补招基本是项目组缺人，招进来最好一周内能跑通开发流程。所以我印象里畅游这套题没有太多概念填空，选择题也是以代码判断和运行结果预判为主，后面跟着大题的场景题和设计题。整套题给的时间是180分钟，但实际做下来，大多数人都会觉得不够用。
这种考题设计的底层逻辑很简单：筛掉“只背概念、没写过项目”的人。比如它不会直接问“什么是对象池”，而是给你一段频繁实例化和销毁的游戏任务列表，让你解释为什么帧率会抖动，再写出一个优化方案。这类题没有标准答案，但能不能踩到“内存碎片、GC压力、T载入耗时”这些点，基本一眼就能看出水平。
1.2 考点地图：基础、引擎、算法、工程化
复盘那套考题，我把考点大致分成四个模块，每个模块对应一种核心能力：
| 模块 | 典型考察点 | 筛选目标 | 放到现在的扩展方向 |
|---|---|---|---|
| C++与数据结构 | 指针、内存、vector扩容、链表反转 | 看语言功底是否扎实 | C++17/20新特性、Rust内存安全思路 |
| Unity引擎 | 生命周期、协程、U GUI、物理 | 看能否直接入手项目 | Unity DOTS、Godot场景树、微信小游戏适配 |
| 图形学与渲染 | MVP矩阵、渲染管线、批处理 | 看技术天花板和优化意识 | GPU Skinning、移动端TBDR架构 |
| 算法与逻辑 | A*、四叉树、状态机 | 看玩法逻辑实现能力 | 行为树、ECS系统、大世界寻路 |
我当年最吃亏的是把精力全压在算法题上，结果引擎相关的简答题答得不够系统。后来跟出题人聊过，他们说补招笔试里引擎与优化的分值占比通常比统招更高，因为补招时间紧，项目组要的是“今天聊完，明天能改UI”的人。
2. C++与数据结构经典题：不刷题真的会凉
2.1 指针、内存与容器底层
那套题里C++部分几乎必考vector扩容。题目通常长这样：往一个vector里不断push_back 100万个int，问发生了什么，如何优化。很多人能说出“capacity翻倍”，但再追问“具体翻多少倍”“内存怎么迁移”“析构和拷贝发生在哪个环节”就卡住了。
vector扩容并不是简单的2倍。不同标准库实现策略不同，VS里通常是1.5倍，GCC里是2倍。扩容的过程是：分配新内存、把旧元素拷贝或移动到新位置、析构旧元素、释放旧内存。元素是自定义类型时，这个开销会被放大。正确做法是预估容量后用reserve预分配，避免多次扩容。放在游戏场景里，比如存档槽位列表、任务列表这种明确知道上限的数据，就应该提前做好容量规划。
另一个高频考点是智能指针。题目会问你shared_ptr和weak_ptr的区别，以及为什么游戏物体引用容易出现循环引用。举个例子：一个管理器持有关卡对象，关卡对象又持有管理器的回调，两边都是shared_ptr时引用计数永远不为0，内存泄漏就是必然。换成weak_ptr只观察不持有，就能打破环。这和Unity里委托事件不注销导致的“僵尸对象”本质上是同一类问题。
2.2 手写算法：A*、环形缓冲区与空间分割
算法题一般会出2道，一道纯逻辑，一道偏游戏场景。纯逻辑题常考链表反转、二叉树遍历、堆排序，这部分练熟LeetCode中等题基本够用。真正拉分的是游戏场景题，我遇到的是“在2D网格地图上实现A*寻路”，要求写出思路和伪代码，并说明Open/Closed列表怎么维护。
A*的核心不是公式，而是对游戏地图特征的利用。比如大多数格子地图上，单位移动是四方向或八方向，估价函数用曼哈顿距离还是欧几里得距离，直接影响路径的“绕路感”和搜索节点数。更关键的是Open列表的实现——如果用数组，每帧寻路几百个单位就会出现明显卡顿，用二叉堆能显著压掉排序开销。当时我不懂这个，只写了“维护列表”，面试官追问“如果一次寻路有几千个请求怎么优化”，我直接答不上来。
还有一个值得记住的容器是环形缓冲区。任务系统、战斗消息队列、网络同步包里都适用。题目会给你一个固定大小的数组，要求实现高效的入队出队，并处理“队满覆盖”策略。这题表面考数据结构，实际考你对“固定内存上限”的理解，游戏客户端里最忌讳无边界增长的逻辑链表。
3. Unity引擎题：从API问到项目优化
3.1 生命周期、协程与场景管理
Unity部分是整套题的大头，第一道必是生命周期顺序问题。题目会问：一个脚本从加载到销毁，Awake、OnEnable、Start、FixedUpdate、Update、LateUpdate、OnDisable、OnDestroy的执行顺序是什么，哪些一定在下一帧前执行，哪些可能跨帧。
这里容易踩坑的是很多人以为Awake和Start在同帧，其实对象被实例化时Awake立刻执行，OnEnable也紧接着执行，但Start要到第一次Update前才执行。如果A脚本在Awake里找B脚本的组件，而B脚本的Start里初始化数据，那么A的Start顺序并不能保证B的数据已就绪。想要严格的初始化顺序，要么用事件总线，要么在Manager里显式Init。这也是补招题常见的追问点。
协程是另一个重灾区。题目会给你一段代码，让你判断输出顺序：
void Start() { StartCoroutine(Test()); Debug.Log("A"); } IEnumerator Test() { Debug.Log("B"); yield return null; Debug.Log("C"); }正确输出是B、A、C。原因在于StartCoroutine调用时，协程会立即执行到第一个yield，所以B先打印，然后Start里的A打印，下一帧才恢复执行C。很多人以为协程是异步开的、会晚一帧才启动，这个误解在补招面试里被反复追问。协程本质上是通过迭代器状态机模拟“分帧执行”，它不是多线程，依然运行在主线程上。凡是涉及耗时任务，比如加载资源、逐帧过渡动画，用协程没问题；但要做网络请求、复杂计算，协程并不能让主线程解脱。
3.2 物理、UI、内存与常见的项目优化题
引擎优化题通常围绕DrawCall和内存。题目可能直接问“UGUI界面上几百个Image为什么卡，如何优化”。我当时的回答是把相邻图片打包进图集（图集/Atlas），减少材质切换，随后又补了“不用TextMeshPro时字体图集过大”的坑。实际上UI优化的核心是减少Canvas重建，一个像素的位移也可能触发整个Canvas的脏矩形重建，元素太多时CPU开销飙升。现在做微信小游戏更是如此，UI节点越多，性能衰减越明显。
物理相关题也常见：为什么FixedUpdate里做物理运动，而Update里做普通逻辑；CharacterController和Rigidbody的选择；碰撞检测用触发器还是碰撞器。很多题目看起来在问API，实际在问“你是否理解物理引擎是按固定步长模拟的”。在移动端，物理步长固定0.02秒，如果渲染帧率掉到40帧，物理模拟次数并不会变少，反而更容易出现两帧之间物体穿透。优化方法是检测连续碰撞或提升物理步长精度，但代价是CPU更高。
关于内存，我踩过的坑是AssetBundle卸载时机。笔试里有一道判断题：“AB包加载后，场景切换前必须全部卸载，否则内存泄漏。”这是典型的误导题。AB包有引用计数机制，若某个资源还在被场景里的物体引用，直接卸载会导致贴图丢失。正确做法是“暂时不用的资源先释放，场景切换后统一Unload(true)”，并且用Profiler追踪资源生命周期。现在Unity的Addressable Assets虽然封装了这套逻辑，但原理还是引用计数加依赖管理，这个底子没打好，换什么工具都会踩坑。
4. 图形学与性能优化：拉开差距的加分项
4.1 渲染管线与Shader入门的考察
补招题里图形学不会考得太深，但至少会有一道MVP矩阵和一道光照模型。原因是客户端开发一旦涉及特效、Shader、UI特效，就必须理解顶点是怎么从模型空间一步步到屏幕空间的。模型空间、世界空间、视图空间、投影空间，每一层变换对应一个矩阵；考题常见错误是混淆“模型矩阵”和“视图矩阵”的乘法顺序。
我当时被问到一个问题：“在Unity里，没有光照的物体为什么看起来是平的？”这其实是在考Lambert和Blinn-Phong模型。Lambert用N·L计算漫反射，色块之间没有高光；Blinn-Phong则是把半角向量H加入镜面反射计算。如果你能顺手写出半角向量公式：H = normalize(L + V)，再解释一下pow高光系数对高光范围的影响，面试官基本就满意了。
PBR（基于物理渲染）是另一个常被问的趋势性话题。2017年还好，现在再面中高级岗位几乎必问。你不必手写PBR代码，但要能说清Base Color、Metallic、Roughness、AO贴图的作用，知道微表面模型里法线分布函数决定高光形状。如果还知道移动端PBR要压缩贴图、降低采样，那就是加分项。
4.2 用Profiler和FrameDebugger定位真实瓶颈
纯理论题的陷阱是“背得越多越飘”，因为纸上写的优化方案到真机上一跑可能完全反效果。我建议你把考题当成排查问题来练。比如笔试题问“场景中一个角色模型带动画，帧率从60掉到30，怎么定位”，不要一上来就说换LOD。正确步骤是打开Profiler看是CPU还是GPU瓶颈；CPU里再看是Update脚本逻辑贵，还是物理模拟贵，还是动画计算贵；GPU里再看是DrawCall多，还是OverDraw高，还是后处理开销大。
FrameDebugger是Unity自带的逐DrawCall查看工具，能清楚看到每一帧按什么顺序提交渲染命令，哪个网格导致状态切换。当年考完试，我回家对着FrameDebugger调了一周，把没合批的UI拆分整理，DrawCall直接从300降到60多。这种实操经验笔试不会考，但面试追问时你说“我实际用FrameDebugger优化过”比回答任何八股文都有效。
Overdraw也是移动端的关键指标。透明特效叠加、UI界面重复绘制、全屏后处理都会放大填率压力。检验方法很简单：在Game视图打开Overdraw开关，颜色越红越浪费。如果笔试题考到“卡通描边为什么在低端机卡顿”，通常就是因为后处理采样次数过高，而不是描边算法本身复杂。
5. 实操复盘：从答题到面试追问
5.1 180分钟怎么分配才不吃亏
我的建议是：选择题和填空题控制在30分钟，这部分靠平时积累，犹豫越久越容易错；基础编程题50分钟，优先保证编译通过和边界正确；引擎与优化简答40分钟，答题时先列结论再补推导；最后一道设计题留20到30分钟，先画框架再填细节，千万不要一上来就写代码。
编程题里即使时间不够，也要把数据结构选型和思路写清楚。阅卷人最怕看到空白的答题框，只要你写了“这个场景适合用优先队列”并说明原因，至少能拿一半分。另一个技巧是手写代码时把常用头文件写全，比如#include <vector>、#include <queue>，这代表你对语言环境是熟悉的，而不是依赖IDE自动导入。
5.2 面试追问怎么展示项目经验
笔试通过后，面试环节通常是从笔试题里挑两道继续深挖。我印象最深的是追问对象池。题目本身只是让优化子弹频繁生成销毁的问题，但面试官会连续追问：对象池容量怎么定？对象回收后如何重置状态？池满了怎么办？多线程下是否安全？
我当时总结了一套回答模板：容量按峰值并发量的1.2到1.5倍预分配，避免扩容；回收时调用Reset接口，禁掉未使用物体上的组件；池满时优先复用最早闲置对象，并记录独立的上层缓存；Unity主线程操作对象池不需要加锁，但如果逻辑线程也要访问，就要用ConcurrentQueue或锁保护。这套回答并不深奥，但它展现了你不仅知道“用对象池”，还知道“边界条件和风险点”。
我还在面试里被追问过一个当年答错的题：yield return null到底等多久。我说是“等到下一帧Update前”，面试官纠正说实际上是“当前协程挂起，等下一次Update开始时恢复”，但如果你在LateUpdate里启动协程，就要注意执行时机。这种细节不是靠死记硬背，而是要靠自己写Demo打印日志验证。回去之后我做了一个试验脚本，把Awake、Start、Update、LateUpdate、协程恢复的打印顺序全部打印出来，才真正记住。
6. 把2017年的题放到今天：工具演化与学习路线
6.1 Unity、Godot与微信小游戏的技能变化
现在回看这套题，核心考点没有变，但技术栈已经在分化。Unity依然占据商业项目的半壁江山，C#语言和UGUI、Addressable、DOTS都值得投入。与此同时，Godot在独立游戏圈快速崛起，它的GDScript上手成本极低，场景树的设计比Unity的组件模式更直观，很适合个人练手做原型。补招题如果放到现在，可能会增加“用Godot的Node与Scene组织游戏结构”这种开放题，因为很多独立团队已经用Godot做出上线产品了。
微信小程序游戏是另一个值得关注的方向。它本质上是把游戏跑在WebGL和微信容器里，包体限制、兼容性、加载性能都是新考验。如果2017年那套题是在iOS和Android平台上UI优化，如今可能要换成“如何在微信小游戏环境控制首包体积、处理动态加载资源”。但底层仍是渲染、内存和逻辑帧三大块，底子好的开发者换引擎只是换API。热词里“手把手带你godot游戏开发”“unity3d游戏开发”“微信小程序游戏开发”看起来是三条路，实际是同一个技能树的分叉。
6.2 一条可复用的游戏开发学习路线
结合补招题复盘，我建议新手走这条路线：
- 语言基础：选C++还是C#都行，重点是把指针/引用、内存生命周期、容器底层弄清楚。想做商业项目先学C#配合Unity，想做独立游戏或喜欢开源选Godot配GDScript，但C++依然值得学一遍，方便看引擎源码。
- 数学基础：向量、矩阵乘法、四元数、点乘叉乘。不用一口气学完整本图形学，遇到问题再查也行，但MVP矩阵和坐标变换必须能自己推导。
- 小项目闭环：用Unity或Godot做一个小Demo，比如俯视角射击，把对象池、状态机、A*寻路、UI血条、粒子特效全加进去。做完上传到itch.io或微信小游戏平台，这比在简历里写“熟悉Unity”更有说服力。
- 性能优化进阶：打开Profiler跑自己的项目，找出CPU最高和GPU最高的模块，挨个优化。学会看DrawCall、SetPassCall、GC Alloc、Overdraw，能截图对比优化前后就是面试素材。
- 发布上线体验：无论团队多小，走一遍安卓包或微信小游戏的审核流程，你会遇到很多编辑器里发现不了的问题，比如加载慢、内存峰值、低端机闪退。
6.3 把自己当成“考生兼考官”
补招题最值钱的地方不是答案，而是它的提问方式。问题之间的逻辑链非常紧密，比如从协程问到状态机，再从状态机问到完整任务系统设计。这说明游戏开发岗位要的不是单个知识点，而是把知识点串成系统的能力。
我自己带新人时，也会用当年这套题的变体来摸底。让我比较意外的是，有些人基础概念熟练，但从不看引擎源码；有些人会写Shader，却说不清自己的项目为什么卡顿。这两类人其实都能成长，但成长速度差别很大。真正走得快的人，都有一个共同点：愿意为了一个“为什么”反复查资料、跑Demo、翻源码，而不是背一个结论就满意。
最后再分享一个小技巧吧。准备一个“错题本”，不一定要纸质的，用笔记软件就行。把笔试、面试里没答上来的点按语言、引擎、图形学、优化四类记录，每条写清问题、当时的错误回答、正确的理解、验证方法。三个月后回头翻，你会发现自己看问题的速度完全不一样。这套方法让我后来面试别人时，一眼就能看出谁是真正刷过题、谁是真正理解过自己写的每一行代码。
