在日常的运营维护中，服务器和客户的更新都是必须的，如何对服务端和客户端进行合适和必要的更新选择是一门学问。很多小伙伴，在日常的使用app中常见的更新方式如：热更（bug修复），迭代更新，整包更新，停服更新等。以上内容均是更新机制中的手段，那什么时候会用到对应手段又是根据什么来判断的呢？接下来我们就进入正题，以游戏更新为例！
游戏更新场景：
- 新增内容：新增玩法和对应资源。前端需要增加内容入口以及美术资源，后端需要处理相应新增功能逻辑。
- 迭代更新：玩法迭代，数值，投放调整以及UI迭代。
- 服务变更：客户端SDK升级（新增服务，bug修复），服务器服务升级（扩容，数据库升级，服务架构变更）等
- bug 修复：线上bug包含客户端，文案，玩法逻辑等
- 紧急情况：突发情况，严重漏洞导致玩家数据错误或经济系统崩溃（刷物品类bug）等问题。需要修复bug的同事，还需要对异常数据进行处理恢复。
服务端：
- 版本管理与存储：服务端需要维护版本记录表，存储各版本的版本号，更新内容，下载地址等信息。如：通过数据库或者配置中心（Nacos和Apollo）管理版本信息。文件传输使用HTTP服务器（如Nginx，Apache）托管更新包，并通过缓存策略优化传输效率。
- 更新方式：
- 推模式：服务器通过广播的方式主动推送更新（websocket连接），主要用于配置变更，实时性更好。
- 拉模式：客户端定期向服务端轮询，检查服务端更新，返回服务端版本差异项信息。
- 更新体量：
- 增量更新：仅下载差异文件，减少网络流量。如王者采用增量更新机制。
- 全量更新：当差异项多（即换赛季），直接下载新包。
- 安全性保证：使用HTTPS加密传输，防止数据篡改，且需要通过哈希校验文件的完整性，确保客户端下载的更新包未被篡改。
示例：策划配置更新（无感知）
原始策划表→转表工具进行转换→程序可调用数据→新游戏数据推动客户端
示例：服务器补丁不停服热更（无感知）
patch 可以用来修复策划数值、服务器游戏逻辑错误。使用新的逻辑替换错误逻辑，精准修复线上bug。
示例：停服更新，当数据库内的表结构需要升级，数据库需要合并或回滚时就需要停服更新。（强制踢下线，暂时无法访问服务器）
验证修复后版本正确→将新的服务器代码打包到服务器运行文件→将当前服务器停掉→将新服务器代码文件部署到服务器→启动新的服务器文件
客户端：
- 版本对比：客户端启动时或登录后向服务端发送当前版本号，服务端返回最新版本信息。客户端版本与服务端数据库的版本记录表进行比对，判断是否需要更新。
- 下载安装：支持断线续传和多线程下载，优化用户体验，安装是根据平台安装逻辑。如Android 需动态请求安装权限，iOS 通过App store 自动更新。
- 更新限制：
- 强制更新：不更新将无法使用
- 非强制更新：玩家可以自主选择更新，此类更新具有这样的特点：客户端存在至少两个版本，即更新前和更新后。服务器此时为最新版本，但是依然支持更新前的逻辑。如：和平精英出新玩法或道具在更新前后是玩家会被分流，不同版本的玩家不能匹配到一起。
- 兼容回滚：更新前需要新旧版本兼容性，避免功能冲突。提供回滚功能，若更新失败可恢复至原来的版本（C#客户端通过保留旧版本文件实现快速回退）。
示例：客户端补丁获取，在测试过程中，我们可以通过开发工具，通过数据依赖分析打包对应patch文件，并放入客户端pak目录下，实现补丁效果。
客户端： 服务端：
1、新增客户端patch文件到patch目录下
2、客户端连接服务器，检查是否有新的patch文件
3、 推送最新的patch到客户端
4、 patch文件下载
5、patch文件生效
示例：客户端更新包——版本对比升级
登录后，客户端版本与服务器的版本记录表对比，判断是否需要更新。如果需要更新，会继续判断是否可以通过热更方式进行更新，不能通过热更则需要到app商店下载更新。如可以通过热更，则对比当前资源与最新资源差异项进行下载更新。
特点，不需要下载冗余文件一步到位更新
示例：客户端更新包——版本逐级升级
登录后，客户端版本与服务器的版本记录表对比，判断是否需要更新。如果需要更新，会继续判断是否可以通过热更方式进行更新，不能通过热更则需要到app商店下载更新。如可以通过热更，则根据固定更新迭代路径进行下载更新。
特点，依次升级，路径稳定，不会有跳版本的情况。存在下载内容无用较多，下载时间长导致客户端崩溃。
示例：整包更新
如赛季结束，玩法迭代，逻辑处理，资源变化等需要更新的内容很多，采用换包更新。直接去app store 下载安装。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
