如何设计游戏登录流程

目标 & 背景

一般来说，游戏的开启，到登陆成功，进入游戏主页，中间的过程是十分复杂的，为了适应各种各样的突发情况、运营需求等，整体登录流程的设计，需要考虑到非常多的情况

我们期望达成的目标可以粗暴的分成下面三个分支，接下来我们一点点对功能进行补充

• 正常线上玩家
• 白名单
• 审核

开始之前

推荐客户端优先使用 HybridCLR¹ 和 YooAsset² 这两个工具来解决，代码热更和资源热更的问题，我司有自研的热更框架，所以 HybridCLR 并没有使用

热更这流程中，有一条非常重要的功能，要支持版本回退，而支持版本回退就需要同时对首包的代码和首包的资源进行修改，至于为什么后面会讲到，HybridCLR 印象中也是支持修改 AOT 代码的（或者后续功能中支持）

流程展示

下图已经做了脱敏处理，这个是我们游戏客户端整体登录的流程走向，总体分成 11 步，每一个步骤都有自己专门的处理过程

当然这个过程并不适合所有游戏，这里仅仅是给出一个参考

为什么要区分白名单

一般来说，开发者都会部署公司内部使用的测试服，但是仅停留在测试服这个概念上，并不能有效的解决真实线上碰到的问题，下面我们一点点展开来说

停服测试

假设现在线上服务器需要停服更新，此时并不希望玩家能够正常进入游戏，只有标记为白名单的人员，才能正常开启游戏，此时就必须要引入白名单的机制，这种场景非常好理解

但是，实际运营中，虽然在测试服中所有功能验收都通过了，开开心心的准备停服更新，发现又出现了新问题的场景数不胜数，此时又需要埋头解决新的问题，很可能预计很短的停服更新，一次又一次的延长，运营同学还要跟着一次次发补偿

不停服测试

这里的不停服我们分成两种

• 仅更新客户端
• 服务端也要更新

第一种情况很好理解，服务器完全不需要更新，正常维持线上的运转即可，我们变的仅是客户端，而客户端的变化，无非是代码发生变化或者资源发生变化，但对于热更来说，统统都是资源发生了变化，通常我们使用资源号来标记客户端的资源变化

我们假设本次更新资源号为 2

此时，客户端会问服务器要一个资源号，而服务端会根据你是否在白名单中，有区别的进行资源号的下发，正常玩家依然使用的是 1 这个资源，而白名单的测试人员使用的是刚刚推送上去的 2 这个资源

这样就完成了不影响正常用户使用，部分测试人员在线上环境下访问刚刚发布可能不稳定的版本，当所有功能验收后，修改正常玩家的资源号为 2，通过长链接通知，或者下次用户重启时，即可完成更新

这样我们就完成了第一种情况的更新流程

为了解决第二种情况，我们最好引入一个新的服务器(或是故障转移功能)，用于根据白名单对真实服务器地址进行转移

假设当前配置如下

通过 gate server，正常玩家依然连接线服，而白名单连接到了另一台已经更新好的服务器上，当测试通过后，再标记 server2.com 为正式服

一般 server 都很多这种解决方案，需要根据实际项目技术选型再做调整，但是基于这种思路，即使没有服务器故障转移的功能，理论上停服时间也是比较好控制的

当然这里的 gate server 也可以根据实际情况做调整，甚至不需要 gate server

为什么要区分审核

在游戏进入线上运营阶段，不论你用什么热更新，最终都可能会碰到问题无法用热更解决的情况，此时就需要重新打包，送去 App Store 审核，而审核的周期跟结果具有非常强的不确定性，这里区分审核就是为了降低这里的不确定性

前面我们说到了，热更一个很重要的功能是更新首包，这个功能就是为了过审用的，下面我们简单举个例子

我们将 1.5.0 标记为审核版本，此时 1.5.0 的客户端连接时，会自动连接我们的审核服务器，而这个审核服务器与曾经过审版本 1.0.0 配套，同时服务端下发的资源号，对应的也是 1.0.0 的资源

因为热更具有首包更新的能力，这个 1.5.0 的包就被强制还原成了 1.0.0 这个曾经过审的内容

客户端和服务端双端版本保持了一致，这样开发者也不需要为了过审做一堆降智的功能开关，提审的运营人员还需要记得把一些自己认为可能敏感导致被苹果拒审的功能关掉

最后

本文希望抛砖引玉，提供一个真实场景的解题思路，具体技术选型仍然需要开发者认真评估

参考