Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

请问二进制补丁方案和 Pak 的运行时重组方案,有没有在正式项目中应用呢? #76

Open
GotGimhong opened this issue Feb 7, 2023 · 0 comments

Comments

@GotGimhong
Copy link

您好,我们有幸通过您的两篇文章 UE 热更新:资源的二进制补丁方案虚幻引擎中 Pak 的运行时重组方案 了解到这两个方案。我们对这两个方案很感兴趣,目前也在自行做一些探索,但是我们在做运行时 Patch 时遇到了问题。

首先是二进制补丁方案,我们最初的做法是下载到包含二进制补丁的 Pak 后,先将它解压缩,把里面的二进制补丁还原成资源文件后,重新打包成 Pak。这种做法会有安全问题,因为在还原过程中,资源文件会裸露在本地。后来我们改为将整个 Pak 加载到内存,再把内存中还原好的资源文件打包成 Pak,这样就不需要做 Pak 的解压缩和压缩了。但是这样会有另一个问题,就是 Pak 通常会比较大,特别是作为基础包资源的 Pak,导致内存占用过高。

然后是 Pak 运行时重组方案,我们对此感兴趣是因为想了解增量更新 Pak 的可能性,例如我们想更新一个 Pak 中的某几个文件,我们只需要重组这几个文件的 PakEntry,PakEntryContent 和 PakIndex 即可,而不需要重新构建整个 Pak。不过根据您的文章,增量更新 Pak 应该很难实现,因为修改 Pak 中的文件涉及到所有数据块的偏移,索引的修改等,这个过程就相当于是重新构建整个 Pak 了。

考虑到目前无法实现增量更新 Pak,我们打算改用您提供的思路,即修改引擎的 PakFile 模块,在加载资源文件时还原二进制补丁。不过这个思路可能会有这样的问题,由于每次还原后的资源文件并没有写出到本地,如果某个资源文件经历了多次修改,那么它就需要进行多次还原——例如资源文件 A 在1.1,1.2,1.3 版本中都有修改,那么在加载资源文件 A,至少是在首次加载时,就需要从 1.0 开始连续做三次还原,从而降低了资源加载的效率,而且这种影响是随着版本迭代而不断增加的。

因此,我们想了解这两个方案有没有用到正式的项目中,如果有,我们想请教运行时 Patch 问题的解决方法,以及 Pak 增量更新的可能性。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant