当前位置：首页 > news >正文

网易游戏客户端笔试核心考点：C++、算法与网络同步解析

news 2026/8/29 21:55:21

1. 先说结论：这份卷子到底在筛什么人

做游戏客户端方向的人，几乎都绕不开网易的笔试。2018 年这套客户端开发工程师（BJ）笔试卷，我到现在还记得几个印象很深的点：它不跟你玩虚的，第一页就是 C++ 概念题和代码阅读题，紧接着是算法手写，最后再来两道游戏场景相关的简答。很多人以为游戏客户端笔试会考引擎 API、Shader 写法、Unity 操作流程，拿到卷子才发现完全不是这么回事。

这套卷子的核心逻辑可以概括成三句话：

算法题是保底分，拿来拉差距的不是难题本身，而是边界条件和复杂度推导；
C++ 是硬门槛，概念正确只是及格线，能读代码、能纠错才是加分项；
游戏数学和网络同步是区分度所在，没有游戏开发经验的人，在这里基本藏不住。

如果你是准备校招或者社招转行游戏客户端，我建议把这份卷子当成一面镜子，先照一照自己的知识结构有没有偏。下面我从几个主要板块展开讲，每个板块都会列出典型的题型、解题思路、以及我实际遇到过或听说过的翻车点。

2. C++ 与内存管理：最容易暴露真实水平的地方

2.1 虚函数、虚析构和多态：一道题能问出三层理解

网易这套卷子里，C++ 部分是除了算法之外占比最重的。它很少直接问“虚函数是什么”这种背诵题，而是给你一段有继承关系的代码，让你写出输出结果，再判断有没有内存泄漏。

考察点通常包括：

基类指针指向派生类对象时，析构函数不声明为 virtual 会导致什么后果；
构造函数和析构函数内部能不能调用虚函数，调用了会走哪一层；
纯虚函数、抽象类、接口类在实际引擎代码里怎么体现。

我记得当时有一道题大概是：定义一个 Base 类和一个 Derived : public Base 类，Base 的析构函数非虚，main 函数里Base* p = new Derived(); delete p;问会怎样。答案是“派生类析构函数不会被调用，可能造成资源泄漏”。这题本身不难，但它后面跟着一个小追问：如果 Derived 里有一个std::vector<int>指针成员，泄漏会发生在哪一步？这就把“虚析构”从概念题变成了内存分析题。

这里分享一下我的作答技巧：遇到这类题，不要只写结果，要把推导过程也写出来。比如“Base 的析构函数非虚，delete 基类指针时按静态类型调用析构，Derived 的析构函数不会执行，内部成员的内存不会释放”。阅卷人一眼就能看出你是背过答案还是真的理解。

另外，我见过很多人在这道题上栽跟头：构造函数里调用虚函数。你可能知道“构造函数里调用虚函数不会发生多态”，但原因是什么？因为构造派生类对象时，先执行基类构造函数，此时派生类部分还没有初始化，虚函数表指针还指向基类的虚表，所以虚调用会落到基类版本。这个机制在引擎代码里也有实际映射：不要在组件基类的构造函数里调用一个期望被子类重写的 Init 方法，很多 bug 就是这样埋下的。

2.2 内存对齐：一字节一字节算给你看

内存对齐几乎是网易笔试的保留项目。它考察的是你对结构体内存布局的理解，不是单纯背“对齐规则”就完事。

我记得一个很典型的题目：

struct A { char a; int b; short c; };

问这个结构体在 64 位默认对齐下的大小。很多人脱口而出 8 字节（1+4+2=7 凑整），实际答案是 12 字节。原因很简单：

a占 1 字节，然后为了对齐int（4 字节），编译器会在a后面填充 3 字节；
b占偏移量 4 到 7；
c占偏移量 8 到 9；
整个结构体的对齐值是 4，但结构体总大小必须是最大成员对齐值的整数倍，10 不是 4 的倍数，所以再填充 2 字节，得到 12。

如果把成员顺序改成int b; char a; short c;，那大小又会不同：b 偏移 0-3，a 偏移 4，c 偏移 6-7，总大小 8。这就引出一个工程结论：声明结构体成员时，按占用空间从大到小排列，能有效减少填充字节浪费。游戏客户端里大量使用结构体做网络协议序列化，这个细节直接关系到内存占用和带宽，笔试考它不是没道理的。

我当时看到这道题，第一反应就是想起自己写过的网络消息结构体，那次不小心把一个 uint8 放在两个 uint32 中间，内存多了一倍。笔试里把它当成算术题来做，工作里它就是实打实的性能优化点。

2.3 智能指针与手动内存管理：ownership 是游戏客户端的心病

网易这套卷子对智能指针的考察，不是问你 shared_ptr 和 unique_ptr 的区别，而是给你一段代码：

std::shared_ptr<Monster> m = std::make_shared<Monster>(); std::weak_ptr<Monster> w = m; m.reset(); if (auto sp = w.lock()) { // 这里能不能进？ }

考的是 weak_ptr.expired 和 lock 的语义，以及 shared_ptr 循环引用问题。我当时答题时特别强调了一个场景：场景里的 GameObject 和 Component 互相持有 shared_ptr，导致节点永远不会释放，这就是循环引用。

游戏客户端的对象生命周期管理，跟普通后台服务不一样。普通服务可以接受对象“晚一点释放”，但游戏里战斗单位每秒销毁几百个，如果一个怪打完后还赖在内存里，帧率就会越来越低。笔试里虽然只考智能指针，实际上是在筛你做不做得了资源生命周期管理。我的回答里一般会带一句“shared_ptr 适合跨模块共享，适合做 UI 事件回调持有者，但场景对象树里更推荐用裸指针 + 统一容器管理，或者使用 handle 下标索引”。这个补充往往能让面试官觉得你有实际项目经验。

3. 数据结构和算法：不要背题，要会推导复杂度

3.1 TopK 问题：一道题能看出你会不会取舍

算法题在这套卷子里占了不少篇幅，但网易考得很有游戏特色。比如“海量玩家按战斗力取前 100 名”这种题，就比纯粹给一个数组求 TopK 更难一点，因为它多了一个隐含条件：数据是动态变化的，玩家战斗力会实时更新。

TopK 的经典解法我记得很清楚：

线程和分布式思想（MapReduce）；
std::priority_queue维护一个大小为 K 的最小堆，堆顶是当前第 K 大的元素，新元素比堆顶大就替换，最后堆里就是 TopK；
快速选择算法（QuickSelect），平均时间复杂度 O(n)，但工程上要小心最坏情况；
如果数据量超内存，还可以用分桶思路，把数据按区间拆分到多个文件分别排序。

笔试里，你光写“用堆”是不够的，要明确说明复杂度：建堆 O(K)，每个元素和堆顶比较 O(log K)，总时间复杂度 O(n log K)。如果数据规模是 1000 万，K = 100，这比全排序 O(n log n) 快得多。

这道题背后有个游戏开发场景：排行榜服务。玩家战力随时更新，客户端要展示全服 Top100。你不能每次都全量排序，所以常用做法是“定期重算 + 增量更新”，在客户端本地可能就直接维护一个平衡树或跳表。笔试卷想看到的，其实是你有没有这种“数据结构服务于业务约束”的意识。

3.2 链表类题目：递归和迭代哪个更稳

网易对链表挺偏爱，可能因为链表节点操作最能考察指针基本功。常见的有：反转链表、判断链表有没有环、找两个链表的交点、合并两个有序链表。

反转链表递归版本写起来很简洁：

ListNode* reverseList(ListNode* head) { if (!head || !head->next) return head; ListNode* newHead = reverseList(head->next); head->next->next = head; head->next = nullptr; return newHead; }

但我建议你在笔试里写迭代版本，因为递归版本虽然短，面试官可能会追问“递归栈深度是多少”。如果链表长度是几十万，递归直接栈溢出。迭代版本三指针翻转，空间复杂度 O(1)，这才是工程上可落地的写法。

我当时在卷子上还额外写了一句“如果链表节点数不确定，优先使用迭代，避免调用栈溢出”。这种细节不会扣分，反而会让阅卷人觉得你不是只会默写答案。

3.3 哈希表的工程变形：支持随机返回一个元素

网易这套卷子里有一道我印象很深的算法设计题：设计一个数据结构，支持插入、删除、随机获取一个元素，要求三个操作的时间复杂度都是 O(1)。

这题的坑在于，普通哈希表能做到插入和删除 O(1)，但“随机获取一个元素”没法做到，因为哈希表没有索引顺序。解法是哈希表 + 动态数组组合：

动态数组vector<T>存元素，保证随机访问 O(1)；
哈希表unordered_map<T, int>存元素到数组下标的映射；
插入：把元素 push 到数组末尾，同时记录下标；
删除：把要删的元素和数组末尾元素交换，然后 pop_back，再更新哈希表里被交换元素的下标；
随机获取：随机生成一个数组下标，返回对应元素。

这里最容易翻车的是删除操作。如果你直接把元素从数组中间删掉，后面的下标全部失效。所以我在卷子上特意用三步写清楚：交换、删除、更新映射。这道题考的是组合数据结构的思路，也是游戏开发里很常见的一种能力——用一个结构解决不了，就组合两个结构。

4. 游戏数学与渲染基础：从向量点积到坐标空间

4.1 点积与叉积：不只是公式，是游戏逻辑的基石

网易这套卷子对游戏数学的考察，比我想象中更注重应用。它不会让你背点积公式就完事，而是放在一个具体的玩法场景里问你。

比如一道题：玩家朝正前方发起攻击，怪物在某个位置，如何判断怪物是否在攻击范围内。这其实是一个扇形判定问题：先判断怪物与玩家的距离是否小于攻击半径，再用点积判断方向是否在扇形角度内。

点积公式是a · b = |a||b|cosθ，判断方向的思路是：取玩家朝向向量forward和玩家指向怪物的向量dir，计算forward · dir，如果值为正且大于cos(半角)，就说明怪物在攻击扇形内。这就是很多近战游戏“背后攻击有加成”的实现基础。

叉积的应用也差不多：计算一个平面法向量、判断向量的左右关系。比如第三人称相机绕角色旋转时，右移和旋转方向的判断就会用到叉积。笔试里你不需要现场推导全部公式，但一定要能写出点积、叉积的几何意义，并能举一个游戏里用它的例子。

4.2 坐标空间变换：模型空间到裁剪空间，为什么这么多坐标系

游戏客户端渲染基础这道题，网易很喜欢问坐标空间变换。由模型空间到世界空间再到视图空间，最后到裁剪空间，每个阶段的矩阵叫什么、为什么需要它，这个必须答清楚。

我答题时习惯用一句口诀串起来：

模型空间：美术在建模软件里做出来的坐标，原点在模型自身；
世界空间：把所有模型摆进同一个游戏世界里，每个模型有一个世界矩阵；
视图空间：以相机为原点的空间，摄像机朝哪看，决定了物体在“观察者眼里”的位置；
裁剪空间：通过透视投影矩阵，把视锥体变换成一个标准立方体，方便引擎做裁剪和 z 测试；
屏幕空间：最后把裁剪空间里的坐标映射到屏幕上。

为什么不能只用一个坐标系统？因为不同的计算阶段关心的信息不一样。比如光照计算需要世界空间法线，阴影计算经常在视图空间做，UI 又要直接操作屏幕坐标。一个游戏客户端开发如果搞不清这些坐标系的切换，遇到“模型旋转后位置不对”的问题基本只能靠瞎调数字。

4.3 AABB 碰撞检测：简单但必须会优化

碰撞检测是游戏客户端笔试的经典题，AABB（轴对齐包围盒）是其中最基础的一种。题目一般会让你判断两个 AABB 是否相交。

二维 AABB 相交的条件很简单：两个矩形在 x 轴上的投影区间和 y 轴上的投影区间都重合。代码可以写成：

bool Intersect(const AABB& a, const AABB& b) { return a.minX <= b.maxX && a.maxX >= b.minX && a.minY <= b.maxY && a.maxY >= b.minY; }

但网易一般会加一个小追问：如果场景里有 10000 个物体，每帧都要做碰撞检测，怎么做性能优化。这个会引到广义相和狭义相：

先做广义相（broad phase），用空间网格、四叉树、BVH 等快速排除明显不相交的物体；
再做狭义相（narrow phase），对少数候选对做精确的 AABB 或三角形级检测。

我当时答题时也写了一个小优化技巧：把 AABB 判定拆成两个轴分别判断，x 轴不相交就直接 return false，避免多余的 CPU 运算。这种细节在笔试里很讨巧，因为面试官知道你真的用 CPU 性能换过帧率。

5. 网络同步与客户端架构：简答题里的工程含量

5.1 状态同步 vs 帧同步：选择题背后是玩法设计

网易这套卷子大概率会出网络同步相关的简答题，因为这是 MMO 和竞技类游戏绕不开的核心问题。

状态同步的经典流量形态是：服务器计算完状态后，把位置、血量、状态等信息广播给客户端，客户端负责展示。帧同步则是服务器只转发操作指令，所有客户端在同一帧执行同一套输入，跑出相同的结果。

这道题的答题框架可以分成四步：

列出两种同步模式的核心思想；
对比优缺点；
给出适用场景；
结合一款你知道的游戏说明为什么这样选。

比如 MOBA 游戏，尤其是《王者荣耀》这种，早期用帧同步做战斗，因为它能把服务器压力降到最低，而且 replay 文件很小，只需要记录操作。但帧同步有个致命问题：不同客户端浮点计算精度不一致会导致状态分叉，所以需要确定性浮点库。如果让我站队，我会说“没有绝对好坏，只有合不合适”。MMO 的开放大世界更适合状态同步，因为物体数量多、玩家不在同一场景，状态同步便于服务器权威管理；而 1v1 或者 5v5 的竞技场，玩家少、重操作一致性，帧同步更合适。

我印象很深的是这道题还有一个隐藏的坑：同步频率不是越高越好。把发送频率从 10Hz 提到 20Hz，带宽成本会翻倍，但玩家体感可能没什么变化。答题时如果能提到“根据玩法和操作灵敏度选择合适的同步频率”这一层，会显得你确实做过网络优化。