1. 什么是热更新？

热更新（Hot Update）是一种在不重新发布完整客户端的情况下，对游戏进行内容或逻辑更新的方法。热更新可以分为 资源热更新 和 代码热更新 两种：

• 资源热更新：用于更新游戏中的美术、音效、地图、模型等静态资源。
• 代码热更新：用于更新游戏逻辑，如脚本、功能、Bug 修复等，避免重新提交新版本。

2. 资源热更新的三种方式

资源热更新可以分为 整包更新、补丁更新、增量更新 三种方式。

2.1 整包更新（Full Package Update）

特点

• 将所有资源重新打包成一个完整的新版本，上传到服务器，客户端下载后替换旧资源。
• 适用于资源变动较大的更新，如版本大更新。

优缺点

✅ 简单易维护，不需要维护多个资源版本。

✅ 不会产生版本碎片化，所有玩家资源一致。

❌ 更新流量大，即使只修改了少量资源，也需要下载整个包。

❌ 下载时间长，可能影响玩家体验。

适用场景

• 游戏初期或大版本更新（如新赛季、新资料片）。
• 资源变更较大，不适合增量更新的情况。

操作流程

1. 重新打包所有游戏资源。
2. 将新资源包上传至 CDN 服务器。
3. 客户端检测版本变化，下载并替换旧资源。
4. 启动游戏，加载新资源。

2.2 补丁更新（Patch Update）

特点

• 版本级别更新：客户端需要按照 Patch 版本升级，不能跳版本（除非提供合成 Patch）。
• 维护多个版本的补丁：服务器需要存储多个补丁包，如 V1 → V2，V2 → V3。
• 支持回滚：如果某个版本更新后有问题，可以回退到上一个版本。

优缺点

✅ 版本一致性强，所有玩家的游戏版本完全相同，避免兼容性问题。如电竞、竞技类游戏，对版本一致性要求高。
✅ 支持回滚，如果最新版本有 bug，可以快速回退到上一个稳定版本。

❌ 客户端需要依次更新多个 Patch，更新步骤可能较复杂。

❌ 服务器存储压力大，需要维护多个版本的补丁。

适用场景

• 适用于端游、主机游戏、电竞游戏，保证版本稳定性。
• 适用于对平衡性要求高的游戏，如 FPS、MOBA 竞技游戏（如《英雄联盟》《CS:GO》）。
• 适用于需要支持历史版本的游戏，如单机游戏 DLC 需要支持老玩家升级到新版本。

操作流程

1. 计算旧版本与新版本的资源差异，生成 Patch 文件。
2. 服务器存储多个版本的 Patch（如 V1→V2、V2→V3）。
3. 客户端根据当前版本逐步下载并应用 Patch。
4. 版本更新完成，进入游戏。

典型案例

• 《英雄联盟》：使用 版本 Patch 更新，每次新赛季推出时，必须更新完整 Patch，保证所有玩家版本一致。
• 《魔兽世界》：暴雪战网提供补丁更新机制，玩家必须下载完整 Patch 进行版本更新。

2.3 增量更新（Incremental Update）

特点

• 文件级别更新：只更新变化的资源，不关心版本。

• 实时检查资源差异：客户端比对本地资源的 Hash，与服务器上的最新资源进行对比，决定是否下载新的资源。

  资源可单独下载和替换：无需整体替换或补丁合成。

优缺点

✅ 下载量最小，只获取必要的资源。

✅ 更新速度快，无需多次下载 Patch。

✅ 维护成本低，服务器端只存最新的资源文件。

❌ 无法回滚，如果出现问题，通常需要完整重新下载资源或回退整个客户端。

❌ 版本管理复杂，不同客户端可能有不同资源版本，需要服务器维护资源版本列表。

❌ 可能产生资源碎片，需要定期清理无用资源。

适用场景

• 适用于更新频繁、但资源变更较少的游戏（如每周更新少量新地图或角色皮肤）。
• 适用于CDN 分发的游戏，可以按需加载不同资源，减少初始安装包大小。
• 手游（如《原神》《王者荣耀》），减少下载量。
• 开放世界、MMORPG，如《GTA Online》长期运营的多人在线游戏，支持动态扩展内容。

典型案例

• 《原神》：使用 远程资源 + AssetBundle 实现增量更新，玩家只下载新增或修改的场景、角色等数据。
• 《王者荣耀》：使用增量更新 + 资源校验，每个版本仅下载新增或修改的皮肤、英雄数据。

操作流程

1. 服务器提供资源版本索引（Hash 校验）。
2. 客户端检查本地资源，计算需要更新的资源。
3. 仅下载有变化的资源文件，并替换旧文件。
4. 资源更新完成，进入游戏。

2.4 资源热更总结

什么时候选整包更新？

• 游戏初期或大版本更新（如新赛季、新资料片），所有玩家需要统一的完整资源。
• 资源大规模变更（如 UI 重制、游戏引擎升级、角色模型大改动）。
• 开发阶段的重大调整，如更换核心美术资源或大规模优化性能。
• 玩家网络条件允许时，例如主机/PC 端游，整包更新不会对玩家体验造成过大影响。

什么时候选增量更新？

• 游戏资源变化小，但更新频繁（如手游、开放世界游戏）。
• 需要降低下载流量，避免大版本更新（如王者荣耀、原神）。
• 采用CDN 分发资源，支持按需加载。

什么时候选补丁更新？

• 需要保证版本一致性，防止玩家因资源不同导致问题（如电竞游戏）。
• 需要支持回滚，方便修复问题（如 PC 端游）。
• 适用于大型游戏，特别是 PC/主机平台。

有时游戏需要兼顾三种方案

一些游戏会结合增量更新、补丁更新、整包更新三种方案：

• 手游（王者荣耀、原神）：主要使用增量更新，但关键版本更新时结合补丁更新，在重大更新时采用整包更新。
• 端游（魔兽世界、英雄联盟）：通常使用补丁更新，但小型资源（如皮肤、DLC）可能使用增量更新，在引擎大改或资料片更新时使用整包更新。
• 大型主机/开放世界游戏（如《赛博朋克 2077》《荒野大镖客2》）：大版本时采用整包更新，定期小更新采用补丁更新，DLC 资源可能使用增量更新。

选择合适的组合方案，可以平衡更新效率、资源管理和玩家体验！

三种资源热更新对比总结表

对比项	增量更新（Incremental Update）	补丁更新（Patch Update）	整包更新（Full Package Update）
更新方式	直接更新变更的单个资源（文件级别）	生成新旧版本之间的差异补丁	生成完整资源包，覆盖原有资源
更新策略	仅下载最新的有变更资源，不关心版本	客户端必须按版本顺序或跳跃合成进行更新	客户端下载完整资源包，直接覆盖
文件组织方式	资源文件通常按独立文件 形式存放（如 AssetBundles、Pak、单个文件等）	资源文件被封装成 Patch 包，客户端按版本升级	所有资源整合到一个大文件或多个大资源包
资源管理	需要维护资源文件列表（通常带有版本号、Hash 校验）	需要维护多个版本的 Patch（从 V1 → V2、V2 → V3）	只需维护最新的完整资源包，不关注历史版本
服务器存储	仅存储最新的资源，无需保留旧版本	需要存储多个补丁文件，以支持不同版本的升级路径	只存储最新完整包，空间占用较大
客户端存储	只保留最新资源，不会留下旧文件	可能需要保留部分旧资源，以便逐步升级	只保留最新完整资源包，存储空间占用大
网络流量	只下载变化的资源，流量消耗低	需要下载完整的 Patch，可能包含部分冗余资源	下载完整资源包，流量消耗最大
更新速度	更快（下载少量文件，通常是资源级别）	较慢（如果需要多次下载 Patch，累计下载量可能较大）	最慢（需要下载完整资源包）
回滚机制	较难实现（需要重新下载旧版本资源）	更容易（可以下载旧版本 Patch 进行回退）	无回滚（需要重新下载旧版本完整包）
维护难度	低，服务器端存储较少，只需提供最新资源	高，需要维护多个 Patch 版本，并确保客户端能够正确应用	低，只需维护最新完整资源包
适用场景	开放世界游戏（如《原神》）- 多人在线游戏（MMORPG）- 长期运营游戏（如手游）- 内容扩展频繁的游戏（如 DLC）	大型端游/主机游戏（如 Steam 游戏）- 有版本依赖的游戏（如 FPS、RPG）- 对版本一致性要求高的游戏（如电竞游戏）	游戏初期或大版本更新（如赛季更新、资料片）- 资源大改动（如 UI、建模重制）
典型案例	Unity 的 AssetBundle，Unreal Engine 的 Pak System	Steam、战网的 Patching System，PC 端游更新系统	传统 PC 端游、手游大版本更新

3. 代码热更新