Android热更新之微信Tinker的集成与使用 Android热更新之微信Tinker的集成

通常情况下，我们APP上线后出现了bug需要进行修复都是修改好再打包重新发布新的版本让用户进行下载更新，这样会导致整个跨度时间会拉长很多，会影响客户的体验，因此，我们可以采用热更新的方式让用户无感知修复。通过本篇文章的学习，你将学会：
1.什么是热更新
2.热更新技术框架的分类以及原理和特点
3.微信Tinker热更新框架的使用
4.各框架对比
一.什么是热更新
热更新是用于修复我们已发布app中的资源文件，代码和so库文件来解决我们需要应急出现的bug或其他内容，可以让用户在无感知的情况下进行修复出现的bug，相比正常流程重新发布新的版本修复，代价小，更加便捷，成功率高，降低损失。
正常流程：

文章图片
正常流程
热更新流程：

文章图片
热更新流程二.热更新框架的分类
【Android热更新之微信Tinker的集成与使用】根据热更新实现的方式我们可以把它分为三种：
1.ClassLoader 加载方案：QQ 空间超级补丁方案，微信Tinker
2.Native层替换方案：阿里Dexposed，阿里AndFix，HotFix以及Sophix
3.Instant Run热插拔原理：美团Robust和Aceso
QQ 空间超级补丁方案
根据ClassLoader类加载我们知道：在加载类时首先判断这个类是否之前被加载过，如果有则直接返回，如果没有则首先尝试让parent ClassLoader进行加载,加载不成功才在自己的findClass中进行加载，这和java虚拟机中常见的双亲委派模型一致的。在DexClassLoader的findClass 方法中通过一个DexPathList对象findClass()方法来获取class，对之前构造好dexElements数组集合进行遍历，一旦找到类名与name相同的类时，就直接返回这个class，找不到则返回null。也就是我们如果在集合的前面已经找到了name，则会直接返回，即使后面有一样的也不会再进行加载。
假设现在代码中的某一个类或者是某几个类有bug，那么我们可以在修复完bug之后，将这些个类打包成一个补丁文件，然后通过这个补丁文件封装出一个Element对象，并且将这个Element对象插到原有dexElements数组的最前端，这样当DexClassLoader去加载类时，优先会从我们插入的这个Element中找到相应的类，虽然那个有bug的类还存在于数组中后面的Element中，但由于双亲加载机制的特点，这个有bug的类已经没有机会被加载了，这样一个bug就在没有重新安装应用的情况下修复了。

文章图片
image.png
缺点：需要冷启动才会生效
微信Tinker
修复好的new.dex 和原有的old.dex比较差生差量包补丁文件patch.dex，在手机上这个patch.dex又会和原有的old.dex 合并生成新的文件new.dex，用这个新的new.dex 整体替换原有的dexPathList的中的内容就实现了热更新。

文章图片
微信Tinker
缺点：需要冷启动修复方式。dex合并内存比较大，容易发生oom而导致dex合并失败。
阿里AndFix
AndFix不同于QQ空间超级补丁技术和微信Tinker通过增加或替换整个DEX的方案，提供了一种运行时在Native修改Filed指针的方式，实现方法的替换，达到即时生效无需重启，对应用无性能消耗的目的。通过新旧apk，找出被修改的类，为每个被修改的类生成一个补丁类，新类中只有被修改的方法，通过方法注解指向原有方法。app加载补丁后遍历所有补丁类中所有方法，将原始类方法的方法体指向补丁类的方法体。

文章图片
阿里AndFix
缺点：任何虚拟机在native层都会有对应的结构体来描述方法，而在不同的虚拟机上，描述方法的结构体都是不一样的，面临稳定性与兼容性问题。不支持新增方法，新增类，新增field等。
Sophix
AndFix及时修复方案也存在很大的限制，之前提到了任何虚拟机在native层都会有对应的结构体来描述方法，而在不同的虚拟机上，描述方法的结构体都是不一样的，所以需要针对不同的Android虚拟机版本去做不同的适配来匹配不同的结构体，这样一来兼容性的操作就会非常多。Sophix方案中提出了一个思想就是不需要去关心方法的结构体内部具体是什么样的，只需要进行一次整体的替换就可以了。原来需要一个成员一个成员地进行遍历替换，现在是整体替换，但是本质是没有区别的。同一个类的方法会被紧密地排列在一起，我们可以拿到两个方法的地址起始值，而这两者之间的差值就是第一个方法结构体的大小。从而进行方法体整体的替换。全量合成dex技术重新编排了dex的顺序，把补丁dex作为主dex，以前apk的所有dex依次改为classes2.dex、classes3.dex，重新组织了所有的dex文件。

文章图片
image.png
美团Robust
Robust插件对每个产品代码的每个函数都在编译打包阶段自动的插入了一段代码，插入过程对业务开发是完全透明。编译打包阶段自动为每个class都增加了一个类型为ChangeQuickRedirect的静态成员，而在每个方法前都插入了使用changeQuickRedirect相关的逻辑，当 changeQuickRedirect不为null时，可能会执行到accessDispatch从而替换掉之前老的逻辑，达到fix的目的。

文章图片
image.png
缺点：代码是侵入式的，会在原有的类中加入相关代码。增大apk的体积。
注意：冷启动：指app被后台杀死后，在这个状态打开app，这种启动方式叫做冷启动。
热启动：指app没有被后台杀死，仍然在后台运行，通常我们再次去打开这个app，这种启动方式叫热启动。
三.微信Tinker接入和使用
在这里着重介绍一下微信的热更新框架Tinker的使用。我们可以找到Tinker接入文档Bugly Android热更新使用指南，根据它的步骤使用即可。
微信Tinker接入：
1.在工程根目录下的“build.gradle”文件添加插件依赖：

dependencies { classpath 'com.android.tools.build:gradle:2.2.1'// NOTE: Do not place your application dependencies here; they belong // in the individual module build.gradle files // tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明确版本号，例如1.0.4 classpath "com.tencent.bugly:tinker-support:1.1.5" }

2.在app moudle目录下的"build.gradle"文件添加依赖和插件脚本：

dependencies { compile "com.android.support:multidex:1.0.1" // 多dex配置 compile 'com.tencent.bugly:crashreport_upgrade:1.3.6'//bugly // 指定tinker依赖版本（注：应用升级1.3.5版本起，不再内置tinker） compile 'com.tencent.tinker:tinker-android-lib:1.9.9' }

// 依赖tinker插件脚本 apply from: 'tinker-support.gradle'

3.添加tinker-support的配置文件：和app moudle目录下的"build.gradle"同级目录下创建tinker-support.gradle配置文件：

apply plugin: 'com.tencent.bugly.tinker-support'def bakPath = file("${buildDir}/bakApk/")/** * 此处填写每次构建生成的基准包目录 */ def baseApkDir = "app-0506-11-25-17"/** * 对于插件各参数的详细解析请参考 */ tinkerSupport {// 开启tinker-support插件，默认值true enable = true// 指定归档目录，默认值当前module的子目录tinker autoBackupApkDir = "${bakPath}"// 是否启用覆盖tinkerPatch配置功能，默认值false // 开启后tinkerPatch配置不生效，即无需添加tinkerPatch overrideTinkerPatchConfiguration = true// 编译补丁包时，必需指定基线版本的apk，默认值为空 // 如果为空，则表示不是进行补丁包的编译 // @{link tinkerPatch.oldApk } baseApk = "${bakPath}/${baseApkDir}/app-release.apk"// 对应tinker插件applyMapping baseApkProguardMapping = "${bakPath}/${baseApkDir}/app-release-mapping.txt"// 对应tinker插件applyResourceMapping baseApkResourceMapping = "${bakPath}/${baseApkDir}/app-release-R.txt"// 构建基准包和补丁包都要指定不同的tinkerId，并且必须保证唯一性 tinkerId = "base-1.2"// 构建多渠道补丁时使用 // buildAllFlavorsDir = "${bakPath}/${baseApkDir}"// 是否启用加固模式，默认为false.(tinker-spport 1.0.7起支持） // isProtectedApp = true// 是否开启反射Application模式 enableProxyApplication = false// 是否支持新增非export的Activity（注意：设置为true才能修改AndroidManifest文件） supportHotplugComponent = true}/** * 一般来说,我们无需对下面的参数做任何的修改 * 对于各参数的详细介绍请参考: * https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97 */ tinkerPatch { //oldApk ="${bakPath}/${appName}/app-release.apk" ignoreWarning = false useSign = true dex { dexMode = "jar" pattern = ["classes*.dex"] loader = [] } lib { pattern = ["lib/*/*.so"] }res { pattern = ["res/*", "r/*", "assets/*", "resources.arsc", "AndroidManifest.xml"] ignoreChange = [] largeModSize = 100 }packageConfig { } sevenZip { zipArtifact = "com.tencent.mm:SevenZip:1.1.10" //path = "/usr/local/bin/7za" } buildConfig { keepDexApply = false //tinkerId = "1.0.1-base" //applyMapping = "${bakPath}/${appName}/app-release-mapping.txt" //可选，设置mapping文件，建议保持旧apk的proguard混淆方式 //applyResourceMapping = "${bakPath}/${appName}/app-release-R.txt" // 可选，设置R.txt文件，通过旧apk文件保持ResId的分配 } }

注意：在tinker-support.gradle配置文件有一个enableProxyApplication = false是否开启反射Application模式，false是Tinker推荐的接入方式，一定程度上会增加接入成本，但具有更好的兼容性。
4.Tinker的初始化：
分两种情况：一种是enableProxyApplication = false，一种是enableProxyApplication = true；
enableProxyApplication = false

自定义SampleApplicationLike：

public class SampleApplicationLike extends DefaultApplicationLike { public static final String TAG = "Tinker.SampleApplicationLike"; public SampleApplicationLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) { super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent); }@Override public void onCreate() { super.onCreate(); // 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId // 调试时，将第三个参数改为true Bugly.init(getApplication(), "cce9234e11", false); }@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH) @Override public void onBaseContextAttached(Context base) { super.onBaseContextAttached(base); // you must install multiDex whatever tinker is installed! MultiDex.install(base); // 安装tinker // TinkerManager.installTinker(this); 替换成下面Bugly提供的方法 Beta.installTinker(this); }@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH) public void registerActivityLifecycleCallback(Application.ActivityLifecycleCallbacks callbacks) { getApplication().registerActivityLifecycleCallbacks(callbacks); } }

在onCreate方法中的Bugly.init(getApplication(), "cce9234e11", false); 填写你在bugly上申请的appId。

自定义Application

public class SampleApplication extends TinkerApplication { public SampleApplication() { super(ShareConstants.TINKER_ENABLE_ALL, "com.tinkertest.tinkertest.SampleApplicationLike", "com.tencent.tinker.loader.TinkerLoader", false); } }

其中的第二个参数为你自定义SampleApplicationLike的路径，并在清单文件上注册application即可。
enableProxyApplication = true

public class MyApplication extends Application {@Override public void onCreate() { super.onCreate(); // 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId // 调试时，将第三个参数改为true Bugly.init(this, "900029763", false); }@Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); // you must install multiDex whatever tinker is installed! MultiDex.install(base); // 安装tinker Beta.installTinker(); }}

自定义application并在清单文件中注册即可。
5.AndroidManifest.xml配置
权限配置

Activity配置

配置FileProvider

@xml/provider_paths文件如下：

以上就实现了微信Tinker的集成配置。
微信Tinker的使用：
假设我们现在有一个按钮点击弹出toast如下：

//Toast.makeText(this, "我是基准包", Toast.LENGTH_SHORT).show(); Toast.makeText(this, "我是来自2019/5/6这一天", Toast.LENGTH_SHORT).show();

经过修复toast弹出的内容变为下方的内容，我们使用微信Tinker进行修复：
1.打基准包：
配置tinker-support.gradle的tinkerId = "base-1.5"，tinkerId的值在基准包和补丁包时候的值都要保证其唯一性。
双击右侧Gradle下方的app/Tasks/build/assembleRelease打出基准包：

文章图片
生成基准包的方式
这时在我们的app/build/bakApk文件夹下方就会有app-0506-11-25-17文件夹和基准包：

文章图片
生成基准包的位置
2.打补丁包：
在打补丁包之前，我们需要将需要修改的地方进行修复好，我们将toast修改为下方的内容。然后，补丁包需要知道对应的基准包是哪一个，所以需要把tinker-support.gradle的baseApkDir修改为基准包中的目录app-0506-11-25-17，即def baseApkDir = "app-0506-11-25-17"，同时，修改tinkerId的值为tinkerId = "patch-1.5"。双击右侧Gradle下方的app/Tasks/tinker-support/buildTinkerPatchRelease打出补丁包：

文章图片
生成补丁包的方式
这是在我们的app/build/outputs文件夹下方就会有patch文件夹和补丁包：

文章图片
生成补丁包的位置
3.到bugly官方网站发布新的补丁并下发：

文章图片
image.png
进入到当前的应用，应用升级--->热更新--->发布新补丁。发布新补丁的时候切记上传app/build/outputs下patch目录下的补丁包，不能上传tinkerPatch目录下的补丁包，不然会出现问题。补丁包是包含7zip.apk的那个文件，选择并选择全量设备下发即可。
4.微信Tinker热更新需要在冷启动方式下才能修复，需要将进程杀死重新启动应用才能看到修复后的效果。
注意：它也不是马上就能修复，往往在下发后需要等待一段时间再重启应用才能生效。
四.热更新各框架对比
不同的热更新框架的特点也不一样：
来自微信Tinker：