一、作用
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。