Android 增量更新 （二）更新流程
2017-06-19 本文已影响203人
kuwork
接上一节的内容，通过使用 Bsdiff 可以成功实现拆分和合并了。这个时候就要想一下如何完成整个更新的过程。
必须想清楚的问题
这个时候要注意不再是增量拆分，而是如何平滑得实现应用的更新。
- 优先级问题
当检查更新时，存在最新版本的补丁时，优先使用增量更新；如若没有，采用完整更新。 - 拆分次数问题
随着版本不断迭代，由于 Bsdiff 的拆分效能低，不能也没必要做到每个新版本提供以前所有版本的补丁。
试想一下，一个版本越久远越是可能与新版本存在较大差异，补丁包大小逐渐接近完整包大小，再者，App随着apk的Size也随之增加，拆分所需的时间、空间也随之增大，发布新版本的处理时间越来越长，增量更新的优势不复存在了，这是不能接受的。
在更新版本的时候给予设置向前比较次数，我以3个月为期，对于每月更新的APP可以设为3次。 - 唯一性问题
通常情况下，APP 的版本标识是 包名或者是 application id ，版本号，版本号，我则增加一个类型属性，可以理解为渠道名，这是为了解决一些现实的问题，同一APP给不同客户群体使用，例如测试人员和正式用户，测试人员可以收到内部快速迭代的更新包，而不会影响到正式用户，这样可以给特定用户群开放不同的版本功能，并且能够实现阶段性切换产品线。 - 完整性检验
通过SHA1校验码确认合并前后文件都是一致的，保障合并的成功率 - 级联删除
可以单独删除补丁包数据，相应版本只支持完整更新了；删除完整包数据，就要附带删除所有相关的补丁包数据，避免导致更新系统混乱。
界面设计
目前在用的系统也是由这个雏形发展而来，而我现在并不在负责这个部分的编码，这里公布部分界面以及逻辑原理。
- 产品管理
这里的产品管理是以移动产品为标准划分。
产品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的更新过程的，细想一下，这些年我换了几种网络框架，大致的逻辑也没什么变化，唯有网络框架变化导致代码重构。除非有迫切的原因，这个部分暂时不会写了。
