UE4 版本迭代、资源热更、pak更新方案

本文链接：https://blog.csdn.net/BDalasja/article/details/95622429

UE4 版本迭代、资源热更、pak更新方案

注意：以下讨论的内容是客户端热更，打包的时候勾选使用pak文件。

前置知识

---

详细可参考之前的文章 , 这里再简单回顾一下。

1. 客户端进行打包之后，所有的资源及蓝图文件都在paks文件夹中的pak文件中。

2. paks文件夹中所有的pak文件，会全部自动挂载。

3. 所谓挂载，就是读取pak中的文件列表信息，并不加载实际的资源文件。实际加载文件的时候会遍历所有挂载的pak去找文件。

4. 挂载的顺序并不是查找的顺序，每当有新文件挂载的时候，内部的pak列表会根据ReadOrder来排序。Order大的排在前面，优先被查找。

5. ReadOrder规则：

   • Paks文件夹中，并已游戏名开头的文件起始Order为4；Content目录Order为 3 。如果paks文件夹中pak的文件名不是以游戏名为开头，则会满足Content这个条件。

   • Engine目录下的pak文件Order为2，游戏的用户存储目录则为1，其他为0 。

   • 在前两条规则的基础上，文件名以_P.pak 为结尾的，享有额外Order。额外Order最低100。如果结尾形如_n_P.pak 其中n是数字，则会再额外得到 n乘以100的Order值。 例如 _2_P.pak 则额外Order为 300 。

   • 手动mount文件时，可以指定优先级。

6. 使用UE的ProjectLauncher工具可以打包特定版本，并可以根据前面的特定版本打包出差异补丁包。

方案思路

---

通过前置知识6我们知道：

使用UE的ProjectLauncher工具可以打包特定版本，并可以根据前面的特定版本打包出差异补丁包。

那么我们在发布版本1.0之后，后续的版本更新，则可以根据1.0版本的内容来产生补丁包。客户端下载该补丁包到本地的paks文件夹中，即可以完成版本的更新。下载的Pak中有最新的资源文件，现在需要解决优先加载补丁包中资源的问题。

根据前置知识 2，3，4，5，我们将patch包按一定的规则命名，例如都加上版本号_versioncode_P.pak，放入paks文件夹，可以实现特定顺序加载，优先使用新的patch中的文件。

随着版本的推进，修改的内容越来越多，可以预料到会出现的问题是：相对1.0版本生成的Patch包会越来越大。所以为了减小每次更新的大小，减少重复无用更新，在每一个、或者多个小版本之间生成patch，而不是始终相对1.0版本生成patch。多个Patch依旧使用前面的命名规则，versioncode不用，可以保证他们的优先级正确。

接下来需要自己管理一下各个版本之间的patch包的产生与下载，即可实现客户端的热更。

具体实施步骤

---

下面以一个实际的例子来阐述具体的热更实施流程。

首先假设前提：客户端安装包为1.0版本，后续我们陆续发布了1.1、1.2、1.3 版本的内容。

1. 1.0版本。

使用ProjectLauncher生成1.0完整包，并发布。

2. 客户端下载安装1.0版本

客户端安装1.0版本，此时项目的Paks目录下只有一个Pak及Sig文件。

3. 发布1.1版本

相对1.0版本完整包，生成1.1patch包。打包1.1的完整包，作为下次更新的参考包。

维护一个patch信息文件，比如叫 patch_list.txt，格式如下

{
	"suportVersion": ["1.0", "1.1"], 
    "url":"download-url",
	"1.1" : 
	{
		"patch_10100_p.pak" : "hashcode",
		"patch_10100_p.sig" : "hashcode"
	}
}

suportVersion是所有支持的客户端版本列表。如果客户端版本不在此列表中，表示客户端需要重新下载完整客户端，重新安装，适合重大或C++更新版本。

url则是文件的下载地址前缀，完整的下载地址为url与文件名的拼接，如：download-url + patch_10100_p.pak

客户端检测支持的版本号，所有大于自身版本的节点中列出的文件，都需要下载到本地paks文件夹中。并更新本地已下载pak文件信息，比如叫 local_patch_info.txt 。本地已下载pak文件的信息格式如下：

{
    "patch_10100_p.pak" : "hashcode",
    "patch_10100_p.sig" : "hashcode"
}

该文件只保留已下载的pak文件及hasecode，并不需要保存版本号。客户端根据获取的patch_list.txt 和本地已下载的内容对比，形成一个下载列表。下载内容并更新本地文件。

更新结束后，客户端可以认为已经更新到版本1.1 。（只是内容更新到1.1，安装版本号还是1.0）

4. 发布版本 1.2 。 (每个小版本发布包含以下三个小步骤)

   1. 打包1.2完整包；
   2. 相对1.1的完整包生成1.2的patch文件；
   3. 更新patch_list.txt:

{
 	"suportVersion": ["1.0", "1.1", "1.2"], 
    "url":"download-url",
 	"1.1" : 
 	{
 		"patch_10100_p.pak" : "hashcode",
 		"patch_10100_p.sig" : "hashcode"
 	},
    "1.2" : 
 	{
 		"patch_10200_p.pak" : "hashcode",
 		"patch_10200_p.sig" : "hashcode"
 	},
 }

4.1 客户端更新流程（version 1）

现在服务器已经升级到1.2版本，客户端则可能在1.0版本，或者更新了内容的1.1版本。下面就完整说明客户端的更新流程。

• 客户端首先获取http服务器上的patch_list.txt，根据安装版本号，计算出所有要下载的pak文件列表A。

  这个例子中，客户端安装版本号一直为1.0，则得到的文件列表为

  "1.1" : 
  {
      "patch_10100_p.pak" : "hashcode",
      "patch_10100_p.sig" : "hashcode"
  },
  "1.2" : 
  {
      "patch_10200_p.pak" : "hashcode",
      "patch_10200_p.sig" : "hashcode"
  }
  

• 客户端检测本地local_patch_info.txt ，与列表A对比， 检查看哪些文件已下载，hasecode是否匹配，以及本地pak文件是否存在。生成最终下载列表B。

• 客户端更新过所有内容，则跳过该步骤

• 客户端更新过1.1的内容 则下载列表B调整为：

  "1.2" : 
    {
    "patch_10200_p.pak" : "hashcode",
    "patch_10200_p.sig" : "hashcode"
    }
  

• 客户端未更新过任何内容，或者本地某pak文件的hashcode不匹配，或者pak文件缺失，则重新将此文件假如到列表B中

• 根据下载列表B，依次下载文件。

• 下载完成后，触发paks的加载（游戏启动之后改动的pak可能要手动触发挂载，或者触发客户端重启？需要后续再确认。） 更新本地localpatch_info.txt

5. 发布版本1.3 。本处假设1.3与1.2的内容改动不大，下列内容用于处理客户端patch的删除合并策略。

1. 打包1.3完整包（该步骤永远需要，后续总有可能需要基于任意版本发布patch包）
2. 相对1.1完整包来生成1.3的patch包，由于相对1.1来生成patch包，则此patch包是包含了1.2的patch包，也就是说客户端更新了此patch包，1.2的patch包就是完全多余的了，可以删除。
3. 更新patch_list.txt

{
 	"suportVersion": ["1.0", "1.1", "1.2", "1.3"], 
    "url":"http://netcraft-cdn.huya.com/hotres/",
 	"1.1" : 
 	{
 		"patch_10100_p.pak" : "hashcode",
 		"patch_10100_p.sig" : "hashcode"
 	},
    "1.3" : 
 	{
 		"patch_10300_p.pak" : "hashcode",
 		"patch_10300_p.sig" : "hashcode"
 	},
 }

5.1 客户端更新流程（最终版）

对比1.2版本时的patch_list.txt，可以发现，文件节点中少1.2版本的节点。当客户端更新时，对比本地已下载的patch文件，如果存在patch_list.txt中没有的文件，则删除掉。于是客户端更新的完整流程变成：

• 客户端首先获取http服务器上的patch_list.txt，根据安装版本号，计算出所有要下载的pak文件列表A。
• 客户端检测本地local_patch_info.txt ，与列表A对比， 检查看哪些文件已下载，hasecode是否匹配，以及本地pak文件是否存在。生成最终下载列表B。
• 如果local_patch_info.txt中存在列表A中不存在的文件，则删除。
• 根据下载列表B，依次下载文件。
• 下载完成后，触发paks的加载（游戏启动之后改动的pak可能要手动触发挂载，或者触发客户端重启？需要后续再确认。） 更新本地localpatch_info.txt

这样，就通过服务器patch_list.txt的配置，实现了对客户端多余patch文件的删除。当一些版本之外的临时更新发布后，在下次版本更新时，则可以通过patch_list修改，删除这些临时的patch文件。

6. 可能的策略

为了防止客户端pak过多（如果一个月一个版本，一年也就12个pak，其实也不多）。可以使用步骤5的方法，没隔一段时间，可以合并多个小版本的patch文件来达到这个目的。

7. 无法热更的情况

当版本发生重大变化，必须要更新C++时，则重新生成完整包，清空patch_list，重复步骤1-6 。所以尽量减少C++的改动，或者有计划的周期性改动。在游戏迭代的初期，功能不完整，可能很难做到这一点。等功能基本都完整了，只是更新一些内容玩法的时候，基本就可以不用再完整更新客户端。

http服务器的工作

---

1. 上传更新patch_list.txt
2. 上传更新个pak文件
3. 本方案中下载服务器没有逻辑需要处理。

其他工作

---

需要提供工具来维护patch_list.txt ，而不是手动编辑。

目前打包和patch都是使用的ProjectLauncher工具，应该是支持指令执行的，需要进一步研究，集成到一个工具中。

该工具包含：

1. 设置版本号
2. 打完整包
3. 相对某版本打patch包
4. 勾选支持的版本号，更新patch_list.txt

参考文档

---

UE4资源热更新 该文章不知道作者是谁，到处都是转载的，原始链接也是错的

UE4补丁与DLC

UE4Pak相关知识总结

UE4官方打包和patch文档

UE4官方发布项目