友盟自动更新技术解决方案(安卓版)
博客专区 > Skqing 的博客 > 博客详情
友盟自动更新技术解决方案(安卓版)
Skqing 发表于2年前
友盟自动更新技术解决方案(安卓版)
  • 发表于 2年前
  • 阅读 20
  • 收藏 0
  • 点赞 2
  • 评论 0

标题:腾讯云 新注册用户域名抢购1元起>>>   

摘要: 友盟自动更新技术解决方案(安卓版)

系统结构 友盟自动更新系统的示意图如下: 示意图

图中手机代表客户端。服务端的各个模块描述如下:

WebConsole:提供上传更新包的网站操作界面。 FS:文件系统,存储apk文件和增量更新包,增量更新的原理后文会提到。 DB:用于存储文件的属性,例如版本号,更新描述,文件的md5等。 Server: 接收客户端请求,返回文件下载链接。 CDN:提供文件下载服务(友盟用到的是阿里云的CDN服务)。

基本流程 1 用户在WebConsole上传更新包、填写更新版本和更新日志,程序将更新包存储到FS,版本(version-code)、更新日志、文件md5及其他配置信息存储到DB。 2 客户端请求Server,传入客户端的appkey、版本号、md5等信息。Server与DB存储的信息比较,如果需要更新则返回更新包的url,否则返回不更新。 3 客户端收到服务器端的返回结果后判断是否需要更新,如果需要更新,则弹窗提示用户有新版本更新,用户确认后下载安装包,安装新版本。

交互协议(示例) 客户端和Server之间使用https接口通信。使用POST请求方式,交互的信息都在http的content中,格式为json。以下简单示例协议中的关键字段。

Request: [Java] 纯文本查看 复制代码 ? 1 2 3 4 5 { "appkey":"xxxxxxxxxx", "version_code":1, "old_md5":"xxxxxxxxxxxxxxxxx" } 其中version_code是客户端软件的版本号,old_md5是客户端apk文件的md5值。

Response: 如果不需要更新则返回下面的response [Java] 纯文本查看 复制代码 ? 1 2 3 { "update": "No" }

如果需要更新, 则返回下面的reponse: [Java] 纯文本查看 复制代码 ? 01 02 03 04 05 06 07 08 09 10 // 全量更新 { "update":"Yes", "new_version":"xxxxx", "apk_url":"http://cdn.the.url.of.apk/or/patch", // CDN链接下载地址 "update_log":"xxxx", // 更新日志,用于在界面上显示 "delta":false, "new_md5":"xxxxxxxxxxxxxx", "target_size":"601132" }[/p][p=21, null, left] [Java] 纯文本查看 复制代码 ? 01 02 03 04 05 06 07 08 09 10 11 12 // 增量更新 { "update":"Yes", "new_version":"xxxxx", "apk_url":"http://cdn.the.url.of.apk/or/patch", // CDN链接下载地址 "update_log":"xxxx", // 更新日志,用于在界面上显示", "delta":true, "new_md5":"xxxxxxxxxxxxxx", // full-apk的md5 "target_size":"601132", // full-apk的size "patch_md5":"xxxxxxxxxxxxxxxxx", // patch文件的size "size":"337852" // patch文件的md5 }

服务端处理流程 流程图如下: 流程图

  1. 客户端发送请求至服务端,请求内容除了必要的验证信息以外,最重要的信息就是version_code,或者类似的用于比较版本号以判断是否需要升级的字段信息。
  2. 服务端接收到请求后,验证请求的有效性。
  3. 若请求有效,则对比请求中的version_code是否是最新的。
  4. 若不是最新的version_code,则说明需要进行更新,此时需要首先判断是否能够进行增量更新。如果请求中version_code对应的apk文件在服务端存在且md5一致,则可以进行增量更新,否则不能。 5 如果不能增量更新,则直接返回apk文件的CDN下载链接。 6 如果能进行增量更新,首先判断对应的patch文件是否存在,如果不存在则调用bsdiff命令生成patch文件后返回patch文件的CDN链接;如果存在就直接返回patch文件CDN链接。

客户端处理流程 1.客户端首先请求server,获得是否有新版本的更新信息。 2. 如果没有更新,则客户端不进行更新动作。 3. 如果服务端返回的是有更新,客户端会根据全量更新和增量更新两种情况来处理: 如果服务器端返回的是全量更新,则会开启service下载完整版的apk文件; 如果服务器端返回的是增量更新,则会开启service下载patch文件到本地,然后使用JNI进行bspatch,给原apk文件打补丁,生成新版本的apk文件,生成的apk文件要进行MD5校验,如果与后台上传的apk文件的MD5值相等,则认为bspatch成功。 更新对话框如下: 对话框 4. 客户端在下载完成后,会提示安装,若用户忽略,则会在下次检测更新的时候,首先判断本地是否已经存在最新版的apk文件,若已存在,则会提示安装。

一些经验 0. 客户端与服务器端之间的数据传输要进行加密处理,推荐使用https协议。

  1. 建议使用全量更新,目前已知增量更新方案在部分系统厂商上不能正常工作。
  2. 当遇到apk有较大改动时,可能会出现差分包和新apk大小相差不大的情况。这种情况下,建议进行全量升级。因为合并差分包的耗费的时间可能会超过全量升级所花费的时间。
  3. 当apk本身较小时,全量更新更加合适
  4. 若系统内置的apk文件无法获取到,则无法进行增量更新(bspatch是根据系统内置的apk文件与patch文件来合并生成新版本的apk文件)。
  5. 为防止增量更新合成的apk文件有误,需要对合成的apk文件和最新版的apk文件进行MD5校验。

What's more 渠道更新 在本文描述的处理流程基础上,增加很少的扩展就可以实现分渠道更新。具体的做法是: 1 在上传安装文件时分不同渠道存储,相应的DB里面存储的时候也增加channel的字段。 2 客户端请求中增加一个字段channel,用于标识客户端的渠道。 3 服务端根据不同的渠道返回不同的下载链接。

iOS自动更新 参见http://bbs.umeng.com/thread-11135-1-1.html

参考资料 bsdiff & bspatch:http://www.daemonology.net/bsdiff/

共有 人打赏支持
Skqing
粉丝 32
博文 140
码字总数 19724
×
Skqing
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: