Android-第三方开源框架：Bugly让热修复变得如此简单

---

baseApkDir是基准包（也称基线包）的目录，在生产补丁时需要根据基准包在bakApk下具体文件夹名字修改，如：bakApk/xxxx，到时生成补丁包时要将baseApkDir的值改为xxxx。（xxxx是Tinker自动生成的，根据时间戳来命名）。

3、tinkerId

---

tinkerId是Bugly热修复方案最最重要的一个因素，一般取值为git版本号、versionName等等（我习惯用versionName），它会将补丁包与基准包产生对应关系，假设基准包的tinkerId为 base-1.0，则生成的补丁包中的YAPATCH.MF文件关系如下：

Bugly要求baseApk（基准包）的tinkerId与补丁包的tinkerId要不一样。所以，在生成基准包时，请用如下tinkerId：

def myTinkerId = “base-” + rootProject.ext.android.versionName // 用于生成基准包（不用修改）

当生成补丁包时，请使用如下tinkerId：

def myTinkerId = “patch-” + rootProject.ext.android.versionName + “.0.0” // 用于生成补丁包（每次生成补丁包都要修改一次，最好是 patch-${versionName}.x.x）

对于同一个基准包，我们可能会多次生成补丁包上传到Bugly的热修复管理后台，这时，这些补丁包的tinkerId也要不一样，不然的话，当客户手机上的App在获取补丁时，会错乱（亲测，当同个基准包的补丁包的tinkerId一样时，App每次重启都会获取不同的补丁包，导致tinkerId相同的补丁包轮流下发）。所以，“patch-” + rootProject.ext.android.versionName + “.0.0"中的”.0.0"（称为计数）就是为了区分每次生成的补丁包，如.0.1，.0.2等等，建议versionName更新时计数重置。

因为Tinker的配置放在了tinker-support.gradle文件中，与app的build.gradle不在同一个文件中，所以没办法通过android.defaultConfig.versionName直接获取App的versionName，这里我使用了config.gradle来提取共同的属性，rootProject.ext.android.versionName获取的是config.gradle中的versionName属性，详情请百度。

4、补丁新旧判定

---

def myTinkerId = “patch-” + rootProject.ext.android.versionName + “.0.0” // 用于生成补丁包（每次生成补丁包都要修改一次，最好是 patch-${versionName}.x.x）

对于一个基准包，可以在Bugly上发布多个补丁包（切记tinkerid不同），这里或许会让你误以为计数越大，表明补丁越新，这是错误的，这个计数仅仅只是区分不同的补丁包而已，它没有标记补丁新旧的作用，补丁新旧由Bugly来判定，最后上传的补丁便是最新的补丁，举个例子，我在昨天上传了tinkerid为"patch-1.0.0.9"的补丁1，在今天上传了tinkerid为"patch-1.0.0.1"的补丁2，虽然补丁2的计数比补丁1小，但补丁2比补丁1晚上传，所以补丁2是最新的补丁，即补丁新旧与计数无关。Bugly会下发并应用最新的补丁（即补丁2），但还是建议计数从小到大计算，这里仅仅只是说明Bugly如何判定补丁新旧罢了。

五、初始化SDK

========

Bugly的初始化工作需要在Application中完成，但对原生Tinker来说，默认的Application是无法实现热修复的。看过Tinker官方Wiki的人应该知道，Tinker针对Application无法热修复的问题，给予开发者两个选择，分别是：

• 使用「继承TinkerApplication + DefaultApplicationLike」。

• 使用「DefaultLifeCycle注解 + DefaultApplicationLike」。

这2种选择都需要对自定义的Application进行改造，对于自定义Application代码不多的情况来说还可以接受，但有些情况还是比较"讨厌"这2种选择的，对此，Bugly给出了它的2种解决方法，分别如下：

• 使用原来的自定义Application，Bugly通过反射为App动态生成新的Application。

• 使用「继承TinkerApplication + DefaultApplicationLike」。

DefaultLifeCycle注解在Bugly中被阉割了。

分别对应tinker-support.gradle文件中enableProxyApplication的值：true或false。

1、enableProxyApplication = true

---

Bugly将通过反射的方式针