APP 现有的自动升级模式是，根据获取 APK 本地的版本信息与服务器接口返回的版本信息进行对比，如果服务器版本信息比本地的新，APP 会弹出有新版本的提示，用户同意升级后，下载新版本进行安装。 现为了更快的修复 bug，降低升级周期，决定引入微信的 Tinker 热补丁功能。
策略描述
现有的 APK 已经有基本的版本升级模式，这里姑且就叫做基础包升级。现引入微信的 Tinker 热补丁功能，微信的 Tinker 功能很强大，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新 Tinker 官方文档 。在项目中，发布的补丁包是基于 Tinker 的，基于某基础包打的补丁，不可以将该补丁应用于不同基础包版本。例如，补丁包是基于基础包版本为 1.0.0 的，则不可以将补丁运用于基础包版本为 2.0.0。
现与后台约定的升级策略是：
- 后台会确保服务器上保留的是最新的基础版本和最新的补丁版本，不会有旧版本存在；
- 有基础包升级，则升级基础包，没有基础包升级再判断是否有补丁包升级；
- 不可以安装不基于自身基础包的补丁。
升级状态列举
这里列举出具有代表性的几种状态：下载第一个基础包版本（支持热补丁功能）-->发布第一版本的第一个补丁-->发布第一版本的第二个补丁-->发布基础升级包版本二-->发布基于版本二的第一次补丁包，我们将对这几种情况进行分析归纳。
这里为了方便，下文将基础包用缩写 “B” 来代替；补丁包用缩写 “T”来代替。如，基础包版本 1.0.0 表示为 B1.0.0；基于 1.0.0 基础包发布的第一补丁版本 1.0.0.1 表示为 T1.0.0.1 。
一、服务器发布第一个基础包版本为：B1.0.0
服务器上包的状态： 基础包版本：B1.0.0 补丁版本：无
用户行为及手机中包的状态：
某用户下载了第一基础包版本，此时用户手机里安装了第一版本，没有补丁包，用户手机中存有的包状态如下：
| 基础包版本 | 补丁版本 |
|---|---|
| 1.0.0 | 无 |
项目拥有的总用户状态：整个项目的用户状态目前只有一种。
二、服务器发布基础包 B1.0.0 的第一个补丁包： T1.0.0.1
服务器上包的状态： 基础包版本：B1.0.0 补丁版本：T1.0.0.1
用户行为及手机中包状态：
发布基于基本包 B1.0.0 的补丁包 T1.0.0.1 时，用户的升级行为有：新用户下载、现在项目拥有的用户状态为拥有基础包 B1.0.0 升级补丁包 T1.0.0.1两种行为。
图中项目总状态中，用紫色字体标出来的，是这次升级中在原有系统用户状态增加的新用户状态。目前项目最多拥有两种状态的用户。
三、服务器发布基础包 B1.0.0 的第二次补丁包： T1.0.0.2
服务器上包的状态： 基础包版本：B1.0.0 补丁版本：T1.0.0.2
用户行为及手机中包状态：
从上图中看出，用户共有三种升级行为，升级后系统在原来的用户状态上又增加了拥有基础包 B1.0.0 和 补丁包 T1.0.0.2 状态的用户，现在系统中最多有 3 中不同状态的用户。
四、服务器发布基础包 B2.0.0
服务器上包的状态： 基础包版本：B2.0.0 补丁版本：T1.0.0.2
用户行为及手机中包状态：
从上图可以发现，发布基本包更新的时候，不管用户现在拥有的是哪种包状态，用户的更新行为都是下载新版本的基础包。升级后，系统最多又可以增加三种用户，如上图紫色标出的。
五、服务器发布基础包 B2.0.0，发布第一次补丁 T2.0.0.1
服务器上包的状态： 基础包版本：B2.0.0 补丁版本：T2.0.0.1
用户行为及手机中包状态：
从上图可以看出，低于服务器基础包版本的用户，如果想要升级，只能升级新的基础版本，而不能升级补丁。
升级状态分析
随着我们发布的基础版本和补丁版本越来越多，系统拥有的用户状态也越来越多。不过从上面我们列举的用户升级状态图中可以看出，不管系统中用户的状态有多少种，都遵循我们的升级原则。升级状态列举的 5 种，我们这里最终可以总结归纳为两种：相同本基础包打补丁、不同基础版本间的升级。当本基础包版本与服务器基础包版本相同时，此时如果有基于该版本的补丁则下载补丁升级；如果服务器的基础版本比当前手机安装的版本高时，就是不同基础包版本升级，下载最新的基础包安装。最后用一段伪代码表示即：
if(基础版本 < 服务器基础版本){
下载最新基础版本
//……
}else{
if(本地补丁包版本 < 服务器补丁包版本 && 该补丁包是基于本地补丁包版本的){
下载补丁包
//……
}
}
清楚升级过程中会存在哪些用户状态后，有利于我们编写相应的测试用例，对不同的用户状态进行升级补丁策略测试。
