Version number: 1_0_0
The version number is divided into 3 segments, each segment has a number up to 99, and the maximum value is 99_99_99.
There is no special reason why it is divided into three sections, it is just to retain the number of fields for scalability.
The code will split each number and assemble it into an integer type for dictionary query performance purposes.
Version resource folder naming: 1_0_0_202108301450_base
Version number: 1_0_0
Unique path: 202108301450
The time point at the time of output path and configuration, precision: year, month, day and time-sharing The
unique path is to make the path on the resource server unique and avoid CDN caching problems .
Let’s briefly describe
the resources that CDN needs to download, which will generally be transferred to some manufacturers’ CDN services.
For example, in China, manufacturers will have CDN sites in many cities.
When we transfer resources to the source site, the CDN will synchronize the resources of the source site to each branch site.
In this way, when players download resources, they will go to the nearest site to download, achieving an acceleration effect.
The CDN caching problem
is that during the synchronization process of the source site to the branch site, the player requests to download the resource being synchronized. Because the download url remains unchanged. The nearest site receives the download request, and if the resource exists, it is downloaded to the player. But the synchronization has not been completed at this time, and the player downloaded an old resource. It is not a new resource we uploaded.
The conventional solution is that the path is unique. When the resource requested by the player does not exist on the site, it will be crawled from the source site. Therefore, in the design of incremental version control, the path of each version is unique. The resources of the old version do not need to be moved. The new version has a new path, which ensures that there will be no problems with the resources downloaded by players.
base: The mark is whether the base version (basic version, full resource version)
is actually the base version, which is the last line in the master version file.
The reasons for specifically marking the base version:
1. It is convenient for manual viewing.
2. If the resource does not exist in the incremental version, go to the base version to get it. Can shield some exceptions caused by missing resources in increments. At least the client can execute normally.
Master version file naming: versionlist.v
can have multiple lines, one message per line. Separate information with commas on a single line. Content format:
version number, version path prefix, version file list size (size of filelist.v)
1_0_0,1_0_0_202108301450_base,2000
Single incremental version file list naming: filelist.v
content format:
v>1_0_1 :版本号
d>ui :文件夹开始
yyy.u :位于ui文件夹内的yyy文件
d>common :文件夹开始
xxx.u :位于ui/common 文件夹内的xxx文件
<> :文件夹结束
<> :ui文件夹结束
->yyy.u :过期作废的条目,在Save后整理删除;
v>version number mark-
>delete line mark
d>folder mark
<>folder mark
The tag ends with a right angle bracket. In order to distinguish it from ordinary file names, resource names do not use special characters such as angle brackets.
Use the XML idea to reduce the length of the key, and the <left angle bracket mark returns the meaning of the previous directory.
When parsing, follow the idea of xml, parse line by line, and startWith keyword to handle accordingly. No keywords are processed as a file record.
Repository directory structure: -d folder -f file
-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
具体资源内容
Insert read and write.
Various situations may occur during the downloading of a large number of bulk files, causing the download to fail or the connection to be disconnected. Therefore, there is no guarantee that all content can be downloaded correctly at one time.
Then after downloading a resource, saving a record is the best way. But according to this method, the IO operations on local files will be huge. For example, if you need to download 5000 files, then when downloading the 4998th and 4999th files, follow the conventional WriteAll saving method and repeatedly write the previous 4000 records. Waste of IO bandwidth. So a more efficient solution is needed.
Actual performance, analysis, and derivation process:
Original text:
v>1_0_0
d>ui
atlas_common.u,853257dc409601da5b95f6a375ab1e20
<>
d>trackline
trackline_1.u,c1eab33a7cdeaad7d06028fdb152d9f8
d>ui_bg
beautify_top_001.u,9bd5f9e0404d7eb096e5d7cb9538dc03
<>
<>
Parsing: (expanded in XML mode)
v>1_0_0
d>ui
atlas_common.u,853257dc409601da5b95f6a375ab1e20
<>
d>trackline
trackline_1.u,c1eab33a7cdeaad7d06028fdb152d9f8
d>ui_bg
beautify_top_001.u,9bd5f9e0404d7eb096e5d7cb9538dc03
<>
<>
The second character in the tag is a uniform >, to distinguish it from ordinary line content. There is no file name with the > symbol in it. If so...hang that man up and beat him up.
So actually
v = 版本
- = 删除
d = 文件夹
< = 指针往回一层
The basic design is based on xml, which can clearly mark the hierarchical structure. However, the key field of xml is too redundant and is not suitable for network transmission, so the xml is compressed and uses "ordering, bracket relationship, and newline" to rewrite the reading and writing logic: File
1 Behavior a message.
d corresponds to < used as an xml bracket.
The content of line d is the folder name.
Lines without any markers are treated as specific file information.
1 When parsing the code, according to the parsing logic of xml, the pointer points to the head position and goes down line by line. When < appears, return to the first layer of folders.
2 Because d starts with the folder, the included subfolders and files need to have a strong sequential relationship. The file list must be listed first under the folder, then the subfolders.
3 After the download is successful, saving a single record will append the full version path file at the end of the text.
v>
d>
xxx.u
<>
So there will be a problem here. During the update, scattered resources keep downloading. Multiple segments of the complete path will appear. Redundancy caused by a large amount of path information occurs. The reason is that the seek method locates the text cursor position and cannot insert text, but can only overwrite and write. This will damage the original records. After all updates are completed, there will be an API to organize the version files, and then WriteAll will be performed on the files. This redundancy can be resolved.
Therefore, it can be understood that the increase in IO bandwidth for loading local records caused by text redundancy and the time taken to parse local records are used to exchange for runtime writing efficiency.
4 Delete:
v>
d>
xxx.u
<>
Use seek to mark the minus sign in the text - it will become:
v>
d>
->x.u
<>
The minus sign destroys the original line information. But in logic, deletion must be a new version download with the same content.
So this minus sign damage is normal. And when parsing, the minus sign line is ignored and not parsed.
Programming is endless.
Everyone is welcome to communicate. If there is anything unclear or wrong, you can also chat with me privately.
My QQ 334524067 God-like Didi