增量资源热更以及版控方案_增量版本-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_37776196/article/details/120034936

版本号：1_0_0
版本号分为3段，每一段数字上线99，最大值99_99_99。
之所以分为3段，没啥特别原因，只是保留字段数量for扩展性。
代码里会拆分每一段数字，组装成整数类型for字典查询性能目的。

版本资源文件夹命名：1_0_0_202108301450_base
版本号：1_0_0
唯一路径：202108301450
在产出路径和配置的时候的时间点，精度：年月日分时
唯一路径是为了资源服务器上的路径唯一，避免出现CDN缓存问题。

简述一下CDN
需要下载的资源，一般会传到一些厂商的CDN服务上。
例如中国地区，厂商会在很多城市设有CDN站点。
当我们传资源到源站点上之后，CDN会向各个分站点同步源站点的资源。
这样玩家下载资源时候，会去最近的一个站点下载，达到了加速的效果。

CDN缓存问题
是在源站点向分站点同步的过程中，玩家请求下载了这个正在同步的资源。因为下载的url是不变的。最近的站点收到了下载请求，并且存在这个资源，就给玩家下载了。但这个时候同步还没有完成，玩家下载到的是一个旧资源。并不是我们上传的新资源。

常规的解法，是路径唯一，当玩家请求的站点不存在资源，那就会从源站点抓取。所以在增量版控的设计里，每一个版本的路径都是唯一的，旧版本的资源不需要动，新版本是新路径，就能保证玩家下载的资源一定没有问题。

base：标记是base版本（基础版本，全资源版本）
实际上是不是base版本，在主控版本文件里最后一行。
特别标记出base版本的原因：
1.是方便人工查看。
2.在增量版本中不存在资源的情况下，就去base版本里拿。可以屏蔽一些增量中漏资源导致的异常。至少客户端可以正常执行。

主控版本文件命名： versionlist.v
可多行，一行一条信息。单行中用逗号分隔信息。内容格式：
版本号，版本路径前缀，版本文件列表尺寸（filelist.v的尺寸）
1_0_0,1_0_0_202108301450_base,2000

单个增量版本文件列表命名： filelist.v
内容格式：

v>1_0_1			:版本号
	d>ui			:文件夹开始
			yyy.u	:位于ui文件夹内的yyy文件
			d>common		:文件夹开始
				xxx.u	:位于ui/common 文件夹内的xxx文件
			<>			:文件夹结束
		<>				:ui文件夹结束
	->yyy.u			:过期作废的条目,在Save后整理删除;

v>版本号标记
-> 删除行的标记
d>文件夹标记
<>文件夹标记

标记以右尖括号结尾,为了和普通文件名做区分，资源名不会使用尖括号这种特殊字符。

使用xml的思路，缩减key的长度，<左尖括号标记返回上一层目录的意思。
解析的时候，按照xml的思路，逐行解析，startWith关键字做出对应处理。无关键字作为一条文件记录处理。

版本库目录结构： -d文件夹 -f文件

-d: history			所有已经制作的版本记录
	-d:版本资源文件夹1
		filelist.v
		具体资源内容
	-d: ...
	-d: 版本资源文件夹n
		filelist.v
		具体资源内容
-d: near_version		保留最近一次的编译结果，这是一个最新的完整版本	
	完整资源内容
-d: new				目前最新的一次编译输出路径
	新增资源内容
-d: server				需要同步到服务器上的内容
	versionlist.v		主控文件
	-d: 版本资源文件夹1
		filelist.v
		具体资源内容
	-d: ...
	-d: 版本资源文件夹n
		filelist.v
		具体资源内容

插入读写
大量散文件下载过程会出现各种情况导致下载失败，或者连接断开。所以无法保证一次性可以正确的把所有内容都下载完。
那么下载完一个资源，保存一条记录是最好的方法。但是按照这个方法，对于本地文件的IO操作会是巨量的。例如，需要下载5000个文件，那么下载第4998，4999个文件的时候，按照常规的WriteAll保存方法，重复写入之前4000多条记录。浪费IO带宽。所以需要更高效的解决方案。

实际表现，解析，和推导过程：
原文：

v>1_0_0
d>ui
atlas_common.u,853257dc409601da5b95f6a375ab1e20
<>
d>trackline
trackline_1.u,c1eab33a7cdeaad7d06028fdb152d9f8
d>ui_bg
beautify_top_001.u,9bd5f9e0404d7eb096e5d7cb9538dc03
<>
<>

解析：（按照XML方式扩展）

v>1_0_0
	d>ui
		atlas_common.u,853257dc409601da5b95f6a375ab1e20
	<>
	d>trackline
		trackline_1.u,c1eab33a7cdeaad7d06028fdb152d9f8
		d>ui_bg
			beautify_top_001.u,9bd5f9e0404d7eb096e5d7cb9538dc03
	<>
<>

标记中的第二个字符是统一的 >，为了和普通行内容区分。没有文件名里面会带有 > 这种符号。有的话…把那个人吊起来打一顿。
所以实际上是

v = 版本
- = 删除
d = 文件夹
< = 指针往回一层

基础设计是参考xml，可以清楚的标记出层级结构，但是xml的key字段过于冗余，不适合网络传输，于是压缩xml，用 “有序、括号关系、换行” 重写读写逻辑：
文件一行为一条信息。
d 对应 < 作为一个xml括号使用。
d 行内容是文件夹名字。
不带任何标记的行，作为具体文件信息处理。

1 代码解析时候，按照xml的解析逻辑，指针指向头位置，逐行向下，出现<向上返回一层文件夹。
2 因为d作为文件夹开头，所以包含的子文件夹，和文件需要强顺序关系。文件夹下必须是文件列表优先列出，然后是子文件夹。
3 下载成功后保存单条记录会在文本末尾追加完整版本路径文件

v>
	d>
		xxx.u
	<>

所以这边会出现一个问题，在更新时候，散资源一直下载。会出现多段完整路径。出现大量路径信息导致的冗余。原因是seek方式定位到文本光标位置，无法做文本插入，只能覆盖写入。这样会损坏原有记录。在全部更新完成后，会有整理版本文件的API进行整理后，对文件进行WriteAll。可以解决这个冗余。
所以可以理解为，用文本冗余导致的加载本地记录IO带宽增加，和解析本地记录的耗时，来兑换运行时的写入效率。

4 删除：