Android 增量更新 （二）更新流程

接上一节的内容，通过使用 Bsdiff 可以成功实现拆分和合并了。这个时候就要想一下如何完成整个更新的过程。

必须想清楚的问题

这个时候要注意不再是增量拆分，而是如何平滑得实现应用的更新。

• 优先级问题
  当检查更新时，存在最新版本的补丁时，优先使用增量更新；如若没有，采用完整更新。
• 拆分次数问题
  随着版本不断迭代，由于 Bsdiff 的拆分效能低，不能也没必要做到每个新版本提供以前所有版本的补丁。
  试想一下，一个版本越久远越是可能与新版本存在较大差异，补丁包大小逐渐接近完整包大小，再者，App随着apk的Size也随之增加，拆分所需的时间、空间也随之增大，发布新版本的处理时间越来越长，增量更新的优势不复存在了，这是不能接受的。
  在更新版本的时候给予设置向前比较次数，我以3个月为期，对于每月更新的APP可以设为3次。
• 唯一性问题
  通常情况下，APP 的版本标识是 包名或者是 application id ，版本号，版本号，我则增加一个类型属性，可以理解为渠道名，这是为了解决一些现实的问题，同一APP给不同客户群体使用，例如测试人员和正式用户，测试人员可以收到内部快速迭代的更新包，而不会影响到正式用户，这样可以给特定用户群开放不同的版本功能，并且能够实现阶段性切换产品线。
• 完整性检验
  通过SHA1校验码确认合并前后文件都是一致的，保障合并的成功率
• 级联删除
  可以单独删除补丁包数据，相应版本只支持完整更新了；删除完整包数据，就要附带删除所有相关的补丁包数据，避免导致更新系统混乱。

界面设计

目前在用的系统也是由这个雏形发展而来，而我现在并不在负责这个部分的编码，这里公布部分界面以及逻辑原理。

• 1. 产品管理
     这里的产品管理是以移动产品为标准划分。
     产品ID：自动UUID，在各个系统模块中通用，这里仅用于更新模块，也可用于广告投放模块。
     产品名称： 必填
     产品说明：一个公司里面可能存在很多类似的产品，用于区分细节。
     包名：如果上传的是APK包，则和应用市场类似，可以不填，自动获取第一次上传的application id ，以后通过新增版本页面上传是会对比这个参数，不符合就会上传失败，避免脑抽了，出现严重的问题。
     云端下载：自身系统的带宽有限，通过把包放到阿里云或者七牛等地方，减低带宽压力。
• 2）版本管理
  如图所示。这里会在完整包信息之间插入补丁包信息。补丁包信息必须先于版本信息入库，避免出现查询异常。
  产品名称：必选
  版本类型：必选
  包名：自动获取，产品存在包名，将会进行对比，否则记入产品信息中。
  版本名：给普通用户查看的版本信息（字符串）。
  版本号：int类型，用于升级的版本信息，新上传的版本号必须大于上一版本。
  备注：填入升级信息。
  向前对比版本数量：月更新产品，建议设为3次，意思是向上对比不多于3个版本号；周更新产品自己酌情处理。
  SHA1：当前文件的SHA1校验码。
  旧版本SHA1：之前版本的完整包校验码，用于更新查询接口。

提交新版本过程

版本提交流程

接口设计

检查更新接口拥有4个请求参数，如下

参数名	参数描述
productId	产品ID
versionCode	当前版本号
type	版本类型
oldsha1code	当前版本的校验码

返回参数：

参数名	参数描述
name	产品ID
updateType	更新类型有三种，inc(增量)、full(完整)、noupdate（无更新）
versionCode	最新版本号
versionName	最新版本名
size	long类型，更新包大小
sizeOriginal	在增量更新有效时，表示最新包大小
newSHA	最新包的SHA1校验码
increaseSHA	补丁包的SHA1校验码
url	下载链接
updateList	更新信息

在系统中，版本37的SHA1 是 bbc3be08...4f72f41，最新版本是39，SHA1是d53eca....46474811f,从37到39的补丁包的SHA1 是56efbfce....8628。
1）情况一 ：可能当前版本和最新版本不存在补丁包，也可能是当前版本的检验码与服务器记录不符，要求完整更新
参数：

productId:b6d9f85e...64ef
versionCode:37
type:official
oldsha1code:1c5cae2551....964fcab

接口结果:

{
    "code": 1000,
    "updateInfo": {
        "name": "b6d9f85e...64ef",
        "updateType": "full",
        "versionCode": 39,
        "versionName": "1.3.3",
        "size": 20185438,
        "newSHA": "d53eca....46474811f",
        "url": "http://xxx.com/files/d53/d53ec/xxxx_1.3.3_39.apk",
        "updateList": [
            {
                "versionCode": 39,
                "versionName": "1.3.3",
                "updateContent": "1.【新增】优化月租续期缴费，新增自然月续期\n2.【优化】优化附近车场列表加载速度\n3.【优化】优化修复车位申请异常信息提示\n我们始终努力改善您的体验，提高稳定性以及性能优化"
            },
            {
                "versionCode": 38,
                "versionName": "1.3.2",
                "updateContent": "1.【新增】预约车位增加车库位置信息和线路导航；\r\n2.【新增】车场列表新增地区选择和条件排序；\r\n3.【优化】优化附近车场信息和显示；\r\n4.【优化】优化月租到期续费；\r\n我们始终努力改善您的体验，提高稳定性以及性能优化。"
            }
        ]
    }
}

2） 情况二：增量更新
请求参数：

productId:b6d9f85e...64ef
versionCode:37
type:official
oldsha1code:bbc3be08...4f72f41

接口结果：

{
    "code": 1000,
    "updateInfo": {
        "name": "b6d9f85e...64ef",
        "updateType": "inc",
        "versionCode": 39,
        "versionName": "1.3.3",
        "size": 4049580,
        "sizeOriginal": 20185438,
        "newSHA": "d53eca....46474811f",
        "increaseSHA": "56efbfce....8628",
        "url": "http://xxx.com/files/d53/d53ec/xxxx_37_39.patch",
        "updateList": [
            {
                "versionCode": 39,
                "versionName": "1.3.3",
                "updateContent": "1.【新增】优化月租续期缴费，新增自然月续期\n2.【优化】优化附近车场列表加载速度\n3.【优化】优化修复车位申请异常信息提示\n我们始终努力改善您的体验，提高稳定性以及性能优化"
            },
            {
                "versionCode": 38,
                "versionName": "1.3.2",
                "updateContent": "1.【新增】预约车位增加车库位置信息和线路导航；\r\n2.【新增】车场列表新增地区选择和条件排序；\r\n3.【优化】优化附近车场信息和显示；\r\n4.【优化】优化月租到期续费；\r\n我们始终努力改善您的体验，提高稳定性以及性能优化。"
            }
        ]
    }
}

3）情况三：无更新,有两种原因触发，一是最新版本检查更新时出现，也可能是测试版本出现版本号比发布系统上的新。
请求参数:

productId:b6d9f85e...64ef
versionCode:39
type:official
oldsha1code:d53eca....46474811f

接口结果：

{
    "code": 1000,
    "updateInfo": {
        "name": "b6d9f85e...64ef",
        "updateType": "noupdate"
    }
}

注意：不要在同一文件夹下存放过多文件，会导致磁盘查找缓慢。可以利用像上面的方式利用SHA1来分散存储。

服务器这边的情况大致就是这样了，这个只要和后台开发说明白了，很快就能完成，这个接口除了黑盒测试之外，需要仔细过一遍白盒测试，如果存在潜在的问题，会在往后的发布过程中暴露出来，导致严重的更新事故。

第三部分本来想写APP的更新过程的，细想一下，这些年我换了几种网络框架，大致的逻辑也没什么变化，唯有网络框架变化导致代码重构。除非有迫切的原因，这个部分暂时不会写了。