补丁包体文件大小优化方案
背景目前项目根据研发计划稳步推进中，而制作过程也在不断新增内容，不过在打包时发现耗费在烘焙内容和打包内容上的时间正慢慢增加。
联想到之前做端游测试期间，项目发布后如果有内容或配置上的修改，可以通过补丁方式更新获取，于是问题来了：VR项目的补丁怎么整？补丁包体大小是否有限制？
方案1
第一个问题在topic5702中已经得以解决，关键点在于“创建一个该游戏的发布版本以进行发布”、“要创建的新版本的名称”和“这个基于的发行版本”，如图所示：
https://testerhome.com/photo/2016/6dafe114f45650911fb6d914db33036e.jpg
发布时记得填写新版本名称（即发布版本号），补丁制作基于发布版本号！如图所示：
https://testerhome.com/photo/2016/68968419ae7c558d3c5fc9033d0c79c2.jpg
补丁已经打出来了，问题也跟着来了：补丁生成的.pak文件大小几乎等于整包发布时生成的.pak文件大小（大概2.23G）！！！！那么补丁的存在就没什么意义了。修改内容后直接更新出个整包文件得了~~
方案2
方案1显示满足不了补丁存在的意义，后来通过尝试修改部分蓝图或配置文件，在改动较小的前提下打出一个补丁，加以验证补丁包体中到底包含哪些内容。
在同等配置的条件下，补丁大小和内容经过整包与散包对比，发现修改内容较少时打出的包体345M，包含Assets、BaseMaterials、Blueprints等11个文件内容，如图：
https://testerhome.com/photo/2016/18654d03749dccd3cacef315b165f5f8.jpg
虽然补丁包体大小从2G左右降到300M左右，但是这么一个小小改动居然产出300+M的补丁文件，不能忍！（这还不是最优方案，就不贴图了）
方案3
通过散包文件发现打进补丁中的有11个文件，而实际上我只对其中一个文件夹中的某个文件做了修改，为什么会把其他不相关的内容也打进补丁中呢？似乎、好像、貌似找到点切入点了：补丁中包含一些无用文件！！而且有的文件占用空间比较大（比如maps）。。
前面废话了那么多，现在终于轮到“主角”登场了：Directories to never cook，如图所示：
https://testerhome.com/photo/2016/c1d88d0fdd8cb2d48749a573b834a3d0.jpg
打包设置项中这块是对整包\补丁制作过程中，不相关文件夹剔除设定。那么实际在打包过程中只将改动的内容打进补丁中了！通过一个小补丁试了一下，补丁包体大小的确降到200K以内，如图所示：
https://testerhome.com/photo/2016/b96e63b5d60b54f9456fc649452fe1a7.jpg
注：不过在修改内容较大的地方如修改maps文件时，补丁包体偏大是正常的（因为地图文件本身就是个大文件）
结束语
或许我尝试出的方案并不是最优方法，不过也解决了目前工作过程出现的问题。也希望更多的人加入VR游戏测试研究中，进一步完善现有的流程与方式~~
不过我也在想既然可以剔除不相关的文件内容，那么为什么不能只打进修改的内容呢？
Additional Asset Directories to cook，我尝试过只是解决了打包过程C++引用的文件而蓝图中未引用，导致包体内容缺失的问题。
可能我的方向不对，没有找到正确的方法，希望大牛能够解决这个问题..
这个和我们差不多，不过200k还是大了。 今天想了下这种方法可行度太低了....自测过程可以修改某个文件夹中某个配置或资源容易更新补丁，但实际游戏项目每天改动量还是蛮大的，如果每个文件夹中都修改一个文件，那导致最终的结果就是不能剔除任一文件夹...
高级设置项中“迭代cook：仅cook上次cook后改变的内容”，引擎中提供了这一项，为什么勾选后却打包失败就搞不懂了。
上述方法仅供参考，仅供参考。。。 我们一般是修改方法级别，然后推个补丁，利用java动态加载替换掉原来坏的方法。和游戏可能不一样。
页:
[1]
