Android更新平台架构方案

这篇文章是去年写的，我们的两款app一直这使用umeng的更新服务，但是16年umeng开始放弃更新服务，考虑到切换到其他更新平台也会面临这样的问题，我开始着手自己搭建一个更新平台。整体方案包含前后端，客户端代码封装成jar包并上次maven平台，方便每个app直接使用；服务端代码用nodejs来快捷实现。

1、系统结构

（1）整体结构

整体结构

服务端的各个模块描述如下：

- WebConsole：提供上传更新包、配置更新策略的网站操作界面。

- FS：文件系统，存储文件及提供下载服务。

- DB：用于更新策略及更新信息，例如版本号，更新描述，文件的md5等。

- Server：接收客户端请求，返回更新信息。

（2）WebConsole结构

WebConsole结构

WebConsole的各个模块描述如下：

- 应用管理：创建应用、管理应用基本信息、管理应用的版本列表（包括versionCode、versionName、发版日期等）。

- 更新应用：选择应用上传更新包，配置更新信息及策略。

- 任务管理：管理更新任务、定时任务。一个app有且只有一个运行中的更新任务，可以有多个定时任务。

- 测试机管理：查看管理测试机列表，用于<策略-测试阶段>。测试机的标识是以deviceId及MAC地址为判断依据。

- 用户管理：管理用户权限。

- 操作日志：查看管理操作日志。

2、服务端流程

（1）在WebConsole配置更新信息和策略及上传更新包。将更新信息及策略保存至DB，将更新包保存至FS。

更新信息：版本（versionName，versionCode）、大小、包名、MD5、签名SHA1、更新日志等。其中版本、大小、包名、MD5、签名SHA1信息可通过对上传文件解析自动得到，并且通过对比包名和签名SHA1（忽略大小写）判断上传文件是否合法。

更新策略：

1）低版本强制更新：设定一个版本（versionCode），在这个版本及之前版本的app必须进行更新。

2）定时更新：设定一个时间，到时自定启动更新任务。注意在后台有且只有一个运行中的更新任务，当启动新任务则之前的任务自动取消。但是创建一个定时任务，在到时之前上一个运行中的更新任务依然有效。

3）测试阶段：默认开启，用于正式更新前进行更新测试，可在任务管理进行切换。当开启测试阶段，只有在测试机列表中的才会进行更新。

（2）客户端请求Server，传入客户端的包名、版本等信息。Server与DB存储的信息比较，如果需要更新则返回更新包的url及更新信息，否则返回不更新。

Server流程

验证请求：主要验证客户端的请求参数。首先验证参数齐全切不为空，否则为无效请求；然后通过包名和签名SHA1（忽略大小写）判断是否为官方应用，非官方应用不允许更新，返回非官方错误码。

对比版本：判断客户端是否为最新版本，是则无需升级。

测试阶段：判断更新任务是否是测试阶段。如果是测试阶段则判断客户端是否为测试机，是则升级，否则不升级。

强制更新：判断客户端版本是否不高强制更新的版本，是则进行强制更新，否则非强制更新。

3、交互协议

Request：

{

"pkgName": "com.xxx.xxx",

"versionCode": 1,

"versionName": "1.0.0",

"signedSHA1": "xx:xx:xx:xx:xx",

"deviceKey": "xxxxxxx"

}

其中signedSHA1的校验注意忽略大小写；deviceKey用于判断测试机，由deviceId和MAC地址组合而成的唯一校验码

Response:

{

"update": true,

"msgCode": 1,

"msg": "已是最新",

"data": {

"pkgName": "com.xxx.xxx",

"versionCode": 2,

"versionName": "1.0.2",

"updateInfo": "优化xxxx",

"signedSHA1": "xx:xx:xx:xx:xx",

"forceVersion": 1,

"forceUpdate": false,

"apkSize": 123143,

"md5": "xxxxxxx",

"apkUrl": "http://www.xxx.xxx/xx.apk"

}

}

其中msgCode和msg是没有更新的原因；forceUpdate是否强制更新；forceVersion表示这个版本及之前版本的app都需要强制更新，只是forceUpdate的一个补充；signedSHA1和md5的校验注意忽略大小写。

msgCode-msg：

0-更新

1-已是最新版本

2-更新请求失败，请重试。

3-非官方应用，请卸载后到官网下载安装。

4-新版本马上到来，请稍后再试。（测试阶段）

4、客户端流程

（1）非官方应用：弹出不可关闭的提示弹窗，提示用户卸载当前应用，去官网下载官方版本。

（2）手动更新：app启动会自动检查更新，另外用户可以在设置中手动检查更新。手动检查更新结果必须反馈给用户，自动检查更新要保证不影响用户操作。

（3）忽略更新：读取本地存储，判断用户是否已经忽略本版本。

（4）强制更新：弹出不可关闭的提示弹窗，提示版本过低，必须更新后使用。

（5）正常更新：提供更新、取消两种操作及忽略选项。选中忽略取消更新则在本地进行存储。

（6）下载校验：校验文件的大小、md5，保证文件的合法性正确性。如果校验失败则删除已下载文件。

Android更新平台架构方案相关推荐

android 更新平台,Android更新平台架构方案
这篇文章是去年写的,我们的两款app一直这使用umeng的更新服务,但是16年umeng开始放弃更新服务,考虑到切换到其他更新平台也会面临这样的问题,我开始着手自己搭建一个更新平台.整体方案包含前后端 ...
工业互联网平台架构方案，构建工业互联网企业数字化、网络化、智能化服务体系
工业互联网平台基于ICT技术打造的开放式平台,聚焦"联接+云",提供智能化的边缘层.泛在网络.可信IaaS.工业PaaS,及汇聚生态伙伴的工业SaaS, 助力制造企业数字化转型.工 ...
java分布式技术平台架构方案
CoolJava技术特点 CoolJava的技术解决方案信息系统的稳定性.技术先进性.可拓展性,并且满足未来继续增长.业务变革.监管加强的潜在需求.追求系统快速开发迭代,CoolJava应用开发框架能 ...
Android之平台架构
android平台及架构简述 android系统的底层是建立在linux系统之上,是由操作系统.中间件.用户界面和应用软件四层组成.该四层确保了层与层之间的低耦合,当下层发生改变时,上层应用程序无需 ...
物联网（车联网）平台架构方案
技术支持QQ:78772895 1.车载终端网关采用mina/netty+spring架构,独立于其他应用,主要负责维护接入终端的tcp链接.上行以及下行消息的解码.编码.流量控制,黑白名单等安全控制 ...
分布式高可用高并发物联网（车联网-JT808协议）平台架构方案
技术支持QQ:78772895 平台基于(<JT/T808-2011道路运输车辆卫星定位系统终端通讯协议及数据格式>以及<JT/T808-2013道路运输车辆卫星定位系统北斗兼容车载 ...
政务大数据云平台架构方案(ppt)
推荐阅读: 世界的真实格局分析,地球人类社会底层运行原理不是你需要中台,而是一名合格的架构师(附各大厂中台建设PPT) 企业IT技术架构规划方案论数字化转型--转什么,如何转? 华为干部与人才发展 ...
808协议 java_基于JT/T808协议的车辆监控平台架构方案
技术支持QQ:78772895 1.车载终端协议网关采用mina/netty+spring架构,独立于其他应用,主要负责维护接入终端的tcp链接.上行以及下行消息的解码.编码.流量控制,黑白名单等安全 ...
大数据服务平台架构方案(ppt)
推荐阅读: 华为15年招聘经验总结:可用之才,必备5个特质超详细280页Docker实战文档!开放下载 GO语言版<算法进阶指南>火了,完整版PDF下载! 企业IT技术架构规划方案论数 ...

Android更新平台架构方案

Android更新平台架构方案相关推荐

最新文章

热门文章