循迹研究室

在文章基于 ZSTD 字典的 Shader 压缩方案中，我介绍了一种利用ZSTD字典压缩UE的ShaderCode的方法，可以极大地提升ShaderLibrary的压缩比。但训练字典和使用字典进行压缩的流程仍然比较复杂，并不是一个高效的工程实现：

1. 需关闭引擎默认的Shader压缩
2. Cook一遍项目才能Dump每个Unique Shader的ShaderCode
3. 基于Dump出的ShaderCode文件，使用ZSTD程序训练字典
4. 再次执行完整的Cook过程，使用字典进行压缩，生成最终的shaderbytecode

根据上述的流程，需要变动引擎才能实现Dump ShaderCode；其次是流程的割裂，Dump ShaderCode之后需要拉起zstd程序执行训练才能得到字典；最后，仍需要再Cook一遍工程，使用训练出的字典压缩Shader。并且在关掉Shader的压缩后会导致使用LZ4压缩的DDC Cache Miss，重复Cook执行的时间开销巨大，在海量Shader的项目中耗时无法接受。

基于这种痛点，我研究并实现了一种高效的字典训练方法，无需修改引擎，并且十分快速地训练字典和基于字典压缩。能够直接从ushaderbytecode中训练字典，并生成使用ZSTD+字典压缩的ushaderbytecode，极大地提升了处理效率，完全Plugin-Only的实现，接入成本几乎为零，后续将作为HotPatcher的扩展模块发布。

Pak是UE中的UFS中的一环（Unreal File System），是在应用层构造的一种虚拟文件系统。用于把游戏相关的资源、文件打包至一个Pak文件中，避免在运行时对游戏资源的访问创建出大量的文件句柄，并且可以做读缓存（PakCache），提升加载效率。

并且，在UFS中，可以控制每个Pak的优先级，可以用来控制文件系统中文件的优先级。在通过UFS加载文件时，优先级高的Pak中的文件会被首先命中，就可以替换掉低优先级的文件，这也是UE实现热更新的关键，详见之前的热更新系列文章。

但默认情况下，Pak的打包都是在UE端进行的，PakUtilities和UnrealPak都是开发端的功能，运行时不存在，这意味着不能在运行时创建出Pak文件。但Pak本身是Archive的文件形式，理论上是可以进行运行时重组的。

本篇文章就从Pak的创建、文件格式、UFS分析、运行时重组可行性等方面着手，探讨运行时重组Pak的实现细节以及应用方向。

随着项目规模的日益增大，UE里Shader的变体数量逐渐累增，往往能够达到数百万的Shader变体，虽然UE为了避免Shader的重复存储提供了Share Material Shader Code功能，可以把Shader序列化到一个独立的ushaderbytecode文件中，但也会占用几百M的包体大小。而UE默认情况下，把这些NotUAsset文件默认进Chunk0，即必须进基础包，对于移动端的基础包影响很大，几百M的空间，可以放很多资源了。

为了解决这个问题，只能从三个方面入手：

1. 降低项目中的变体数量，Dump出项目中的Shader信息，分析哪些是不必要的；
2. 拆分shaderbytecode，基础包中只包含必要的Shader，其余按需下载。但UE默认没有提供这样的机制，可以使用我开发的HotPatcher拆分基础包，生成多个shader lib，使用热更流程动态下载资源和所需的shaderbytecode。
3. 使用压缩率更高的算法来对ShaderCode进行压缩，引擎中默认使用LZ4；

第一种方式需要TA和美术协同实现，想要有显著的提升较为困难。第二种方案详见之前的热更新系列文章（Unreal Engine#热更新）。本篇文章从第三种方式入手，为Shader实现了一种特殊的压缩方式，可以有效地降低shaderbytecode的大小，大幅度提升Shader的压缩比，并且可以与方案2结合使用，在拆分shaderbytecode的同时，大幅度提高压缩率。

在使用UE开发的过程中，指定命令行参数（Command Line）是一个经常会用到的功能，可以方便地控制部分流程、开关等。UE也是大量地使用了Comandline来控制引擎的行为，官方文档：Command-Line Arguments，不同的模块都可以从Commandline中读取或检查参数，实现自定义的命令行参数功能。

但是，对于移动端Android平台，并不能很方便地指定启动参数，需要编辑ue4commandline.txt文件，非常繁琐。

基于这种痛点需求，我利用元旦的假期开发一个UE的Android的插件，可以让Android的程序像PC一样方便启动和指定命令行参数，并且不需要修改引擎，启用插件后打包Apk即可使用，开源在Github上：hxhb/AppCmderUE。

本篇文章分析了UE在Androdid端Commandline的读取规则，并介绍了AppCmderUE插件的实现原理与使用方法。

默认情况下，在UE中打包项目时，会拉起BuildCookRun来执行Compile/Cook/Pak/Stage等一系列流程。在UE中，只有参与Cook的资源才会被打包，但是通常会包含很多预期之外的资源，可能会造成困扰，到底引擎依赖哪些资源？以及该如何管理UE参与打包的资源。

本篇文章从UE打包时分析资源进行Cook的规则入手，研究在打包时究竟会将哪些资源进行Cook，了解这一点对于资源管理很有作用，基于此可以实现自定义的Cook过程，将Cook任务分配至不同的进程乃至机器实现并行化，加速UE的构建过程。

除了uasset这些资源外，打包时还有很多Non-Asset文件，如ini、Shader Library、AssetRegistry、或者项目中添加的脚本文件等等，在之前的文章UE热更新：需求分析与方案设计中有过介绍，UE对于它们的收集并不在Cook阶段（Shader Library和AssetRegistry是在Cook阶段生成），本篇文章暂不作讨论，后续会写一篇专门介绍的文章。

我一直希望做的所有事情都是可以量化、能够被记录的，不然一年又一年循环往复会记不起自己到底做了什么事情，所以会做一个年度总结。

2021年马上结束，回想这一年，发生了许多事，有了很多新的想法，也是对我影响最大的一年。

近期查看了博客Google Analysic的访问数据，通过流量分析发现一些很有意思的点，能够在一定程度上体现出在使用虚幻引擎进行游戏开发方面的用户特征。文章内的数据样本为本站2021.11.14-2021.11.20一周的访问流量，总体数据量有限不一定能体现出真实趋势，仅供参考。

UE5的预览宣传视频里，介绍了一种模块化开发GamePlay的机制，类似于Mod式地开发和管理游戏功能和资源，被称作“Game Feature”，在UE4.27和UE5中已经可以启用了，我觉得这个新的Gameplay Modualr形式很棒，所以做一个技术预研。

本篇文章介绍Game Feature的启用流程和运行机制介绍，文末分享了一个基于Game Feature的展示Demo。并为HotPatcher实现了能够将Feature独立打包的机制，Game Feature不必预先打包进基础包内，可以在运行中按需下载与加载，实现真正意义上的独立地模块化加载。

目前UE5 EA版本中还有不完善的地方，相关的内容也会随着引擎的更新进行补充。

通常在使用UE进行项目开发时，本地会有多个引擎版本，而Epic Game Launcher只支持安装版引擎的启动，不支持源码编译的引擎。
当本地具有多个引擎版本时，切换不方便，并且没有一种便捷地启动引擎工具、项目以及给项目添加启动参数的方式，在执行Commandlet时需要创建很多脚本，管理非常麻烦。基于这些痛点，我开发了一个UE启动器：UELauncher，用来解决这些问题，同时支持UE4和UE5。

对于项目中的资源检查需求，需要能够实现简单且方便地配置、自动化地执行，并且能够及时地定位相关人员。基于这个需求，我开源了一个资源合规扫描工具ResScannerUE，配置文档：UE 资源合规检查工具 ResScannerUE。
本篇文章将介绍如何通过该工具，实现资源扫描的自动化，并提供了与Git结合的方式进行增量检测支持，使用Commandlet在CI平台上实现Content内容变更的自动触发并执行检测规则，并能够定位到出问题资源最近提交人，实现精确定位，实时发送扫描报告至企业微信，提醒通知相关人员进行处理。
另外，我还提供了基于Git的Pre-Commit Hook实现，可以在提交之前检测本次提交是否具有不合规资源，并禁止提交，避免问题资源污染远程仓库。整体方案经过了精心设计和大量体验优化、增强自动化支持，可以非常方便地配置、接入，能够实现各种资源扫描的需求。