一、作用
1、server端管理资源,包括上传、回退等;
2、接受client的更新请求。
二、模块划分
1、资源管理
1)、资源关系结构
a、根据平台、渠道区分资源,区分之后才划分版本,因为生产环境中会出现一个情况:同一平台的不同渠道会使用相同的资源。所以,server端必须将同一平台下面的资源按组分类,如果有几个不同渠道使用相同的资源,就必须将这几个渠道归属到同一个小组中。比如:
android-->国内微信组-->baidu渠道、360渠道、qq渠道。
b、这种结构由DB保存,目前用的是sqlite3,实际只需要3个table即可,如下:
t_platform(platform_id int, platform_name varchar(30))
t_group(group_id int, group_name varchar(30), platform_id int)
t_channel(channel_id int, channel_name varchar(30), group_id int)
c、id、name及所属上级均在后台由admin管理。
2)、资源存储结构
目录结构如下:
android(也可以是平台id,比如 1)
|
---- 国内通用组(也可以是组id,比如: 101)
|
----------- Resource文件夹
----------- version.json
----------- 1_0_1.txt
----------- 1_0_2.txt
---- 国内微信组(也可以是组id,比如: 102)
|
----------- Resource文件夹
----------- version.json
----------- 1_0_1.txt
----------- 1_0_3.txt
ios(也可以是平台id,比如 2)
|
---- ......
---- ......
---- ......
3)、补充说明
a、Resource文件夹存放了当前最新的资源文件,admin每次更新版本均会覆盖该文件夹;
b、version.json存放了当前组的资源的最新版本号;
c、1_0_1.txt等文件保存了版本V1_0_1对应的所有资源文件的名称及md5值,格式如下:
newLogo.png 47bce5c74f589f4867dbd57e9ca9f808
npcSkin.xxx 9df62e693988eb4e1e1444ece0578579
...
...
注意:该文件是由上传资源包之前mannual生成的,并被压缩在资源包内,上传之后从包里拷贝到当前位置并修改为最新版本的名称。
2、资源更新
流程大致如下:
1)、client发送更新请求到server,并附带platform、channel、version等数据,如:1/101001/V1_0_1;
2)、server根据1)的数据,查询DB,得到对应的平台、小组信息;
3)、根据2)的信息组装成资源存储路径,比如:./media/android/101/;
4)、从资源存储路径中读取version.json,获得当前最新版本号,假设为V1_0_5;
5)、比对1_0_1.txt和1_0_5.txt,得到client需要更新的资源文件列表;
6)、发送5)获得的资源文件列表+更新网址头+当前最新版本号给client。