前言
热更新能力是Bugly为解决开发者紧急修复线上bug，而无需重新发版让用户无感知就能把问题修复的一项能力。Bugly目前采用微信Tinker的开源方案，开发者只需要集成我们提供的SDK就可以实现自动下载补丁包、合成、并应用补丁的功能，我们也提供了热更新管理后台让开发者对每个版本补丁进行管理。
Tinker是什么：
Tinker是微信官方的Android热补丁解决方案，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新。当然，你也可以使用Tinker来更新你的插件。
为什么使用Tinker：
当前市面的热补丁方案有很多，其中比较出名的有阿里的AndFix、美团的Robust以及QZone的超级补丁方案。但它们都存在无法解决的问题，Tinker我们不仅可以用做bugfix,甚至可以替代功能的发布。Tinker已运行在微信的数亿Android设备上，那么为什么你不使用Tinker呢？
接入Bugly热更新 接入了热更新就已经接入了异常上报了，所有就不需要在进行异常上报的接入了。
第一步：添加插件依赖
工程根目录下“build.gradle”文件中添加：
buildscript{repositories{
jcenter()
}dependencies{
// tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明确版本号，例如1.0.4
classpath"com.tencent.bugly:tinker-support:latest.release"
}
}
版本对应关系:
tinker-support 1.0.5 对应 tinker 1.7.8（支持部分加固app的热更新）
tinker-support 1.0.4 对应 tinker 1.7.7
tinker-support 1.0.3 对应 tinker 1.7.6
tinker-support 1.0.2 对应 tinker 1.7.5（需配置tinker插件的classpath）
第二步：集成SDK
gradle配置
在app module的“build.gradle”文件中添加（示例配置）：
android {
defaultConfig {
ndk {
//设置支持的SO库架构
abiFilters'armeabi'//, 'x86', 'armeabi-v7a', 'x86_64', 'arm64-v8a'} } }
dependencies{
// 多dex配置//注释掉原有bugly的仓库 必须依赖multidex才可以使用 MultiDex.install(base);
compile"com.android.support:multidex:1.0.1"
//其中latest.release指代最新版本号，也可以指定明确的版本号，例如1.2.0
compile'com.tencent.bugly:crashreport_upgrade:latest.release'
'//其中latest.release指代最新版本号，也可以指定明确的版本号，例如2.2.0
compile'com.tencent.bugly:nativecrashreport:latest.release
}
在app module的“build.gradle”文件中添加：
// 依赖插件脚本
applyfrom:'tinker-support.gradle'
tinker-support.gradle内容如下所示（示例配置）：
注：您需要在同级目录（Moudle目录下）下创建tinker-support.gradle这个文件哦。
applyplugin:'com.tencent.bugly.tinker-support'
defbakPath = file("${buildDir}/bakApk/")
/**
*此处填写每次构建生成的基准包目录 根据下面的基准包生成对应的补丁包
*/
defbaseApkDir ="app-0507-11-13-19"
/**
*对于插件各参数的详细解析请参考
*/
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.0.4" //生成对于的基包版本 只有生成基准包的时候使用
//tinkerId ="patch-1.0.4" //对于生成的补丁包版本 只有生成补丁包的时候使用
//构建多渠道补丁时使用
// buildAllFlavorsDir = "${bakPath}/${baseApkDir}"
//支持加固需要添加的属性 1.7.8以后才可以使用的
isProtectedApp =true
//是否开启反射Application模式 这里有2中情况
enableProxyApplication =true
}
/**
*一般来说,我们无需对下面的参数做任何的修改
*对于各参数的详细介绍请参考:
* https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97
*/
tinkerPatch {
oldApk ="${bakPath}/${baseApkDir}/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的分配
}
}
第三步：初始化SDK
enableProxyApplication = false 的情况
这是Tinker推荐的接入方式，一定程度上会增加接入成本，但具有更好的兼容性。
集成Bugly升级SDK之后，我们需要按照以下方式自定义ApplicationLike来实现Application的代码（以下是示例）：
自定义Application
public class SampleApplication extends TinkerApplication {
/*注意：这个类集成TinkerApplication类，这里面不做任何操作，所有Application的代码都会放到ApplicationLike继承类当中
参数解析
参数1：tinkerFlags表示Tinker支持的类型dex only、library only or all suuport，default: TINKER_ENABLE_ALL
参数2：delegateClassName Application代理类 这里填写你自定义的ApplicationLike
参数3：loaderClassName Tinker的加载器，使用默认即可
参数4：tinkerLoadVerifyFlag加载dex或者lib是否验证md5，默认为false*/
publicSampleApplication() {
super(TINKER_ENABLE_ALL,"com.bugly.smile.buglydemo.SampleApplicationLike","com.tencent.tinker.loader.TinkerLoader", false);
}
}
自定义的ApplicationLike
public class SampleApplicationLike extends DefaultApplicationLike {
public static finalStringTAG="Tinker.SampleApplicationLike";
public SampleApplicationLike (Application application, inttinkerFlags,
booleantinkerLoadVerifyFlag, longapplicationStartElapsedTime,
longapplicationStartMillisTime,Intent tinkerResultIntent) {
super(application,tinkerFlags,tinkerLoadVerifyFlag,applicationStartElapsedTime,applicationStartMillisTime,tinkerResultIntent);
}
@Override
public voidonCreate() {
super.onCreate();
//这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId
//调试时，将第三个参数改为true
Bugly.init(getApplication(),"<申请的APPID>", false);
}
@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
@Override
public voidonBaseContextAttached(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)publicvoidregisterActivityLifecycleCallback(Application.ActivityLifecycleCallbacks callbacks){
getApplication().registerActivityLifecycleCallbacks(callbacks);
}
}
注意：tinker需要你开启MultiDex,你需要在dependencies中进行配置compile "com.android.support:multidex:1.0.1"才可以使用MultiDex.install方法； SampleApplicationLike这个类是Application的代理类，以前所有在Application的实现必须要全部拷贝到这里，在onCreate方法调用SDK的初始化方法，在onBaseContextAttached中调用Beta.installTinker(this);
enableProxyApplication = true 的情况
public class MyApplication extends Application {
@Override
public voidonCreate() {
super.onCreate();
//设置为开发设备 注意这个必须在初始化Bugly之前设置为开发设备
Bugly.setIsDevelopmentDevice(this, true);
//这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId
//调试时，将第三个参数改为true 打印Log的开关
Bugly.init(this,"申请的appId", false);
//异常展示时候，建议设置为手机号码，方便后期Bug的修复
CrashReport.setUserId(this,"你需要作为UseId的参数");
}
@Override
protected voidattachBaseContext(Context base) {
super.attachBaseContext(base);
// you must install multiDex whatever tinker is installed!
MultiDex.install(base);
//安装tinker
Beta.installTinker();
}
}
注：无须你改造Application，主要是为了降低接入成本，我们插件会动态替换AndroidMinifest文件中的Application为我们定义好用于反射真实Application的类
最后只需要在AndroidManifest文件中将Application替换上就可以使用了。
第四步：AndroidManifest.xml配置
1. 权限配置
<uses-permissionandroid:name="android.permission.READ_PHONE_STATE"/>
<uses-permissionandroid:name="android.permission.INTERNET" />
<uses-permissionandroid:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permissionandroid:name="android.permission.ACCESS_WIFI_STATE"/>
<uses-permissionandroid:name="android.permission.READ_LOGS"/>
<uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permissionandroid:name="android.permission.READ_EXTERNAL_STORAGE"/>
第五步：混淆配置
为了避免混淆SDK，在Proguard混淆文件中增加以下配置：
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}
如果你使用了support-v4包，你还需要配置以下混淆规则：
-keep class android.support.**{*;}
到这里为止 Bugly热更新就已经完成了，下面就是如何使用了，我们需要验证热更新的能力：
注意tinker无法使用热更新修复的情况：
由于原理与系统限制，Tinker有以下已知问题：
Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大组件；
由于Google Play的开发者条款限制，不建议在GP渠道动态更新代码；
在Android N上，补丁对应用启动时间有轻微的影响；
不支持部分三星android-21机型，加载补丁时会主动抛出"TinkerRuntimeException:checkDexInstall failed"；
对于资源替换，不支持修改remoteView。例如transition动画，notification icon以及桌面图标。
验证Bugly热更新 必须在联网的情况下才可以使用热更新
普通打包
1、编译基准包
配置基准包的tinkerId （注意这里的base版本必须联网上报 才可以上传补丁包）
设置你的基准版本号 最好是和app version对应
执行assembleRelease编译生成基准包：
在android studio的右边选择gradle找到我们接入热更新的model 进入build中选择生成的基准包类型：这里可以是Release和Debug版本
这个会在build/outputs/bakApk路径下生成每次编译的基准包、混淆配置文件、资源Id文件，如下图所示：
这里面有的app-release.apk就是我们需要上线的基线版本，请注意保存线上发布版本的基准apk包、mapping文件、R.txt文件，如果线上版本有bug，就可以借助我们tinker-support插件进行补丁包的生成。
如果你没有开启混淆是不会有mapping.txt文件的，需要在Moudle的build.g'radle文件中开启混淆
如何生成签名文件这里就不介绍了。
2、对基线版本的bug修复
上面生成了base包了，那就需要去生成patch包了。
基准包的代码：
补丁包（patch）的代码：
3、根据基线版本生成补丁包
这里需要注意的：基准包目录必须是你上次生成的base包，注意这里是按照时间命名的，检查是否正确，tinkerId 需要生成patch包必须使用 tinkerId="patch-base版本号对应"
执行构建补丁包的task
如果你要生成不同编译环境的补丁包，只需要执行TinkerSupport插件生成的task，比如buildTinkerPatchRelease就能生成release编译环境的补丁包。
生成的补丁包在build/outputs/patch目录下，其中7zip.apk就是我们需要使用的补丁包：
打开补丁包可以看到里面会有一个YAPATCH.MF，这里面包含了我们是从base版本到patch版本：以及app的version信息
4、上传补丁包到平台
进入到对应appid的app中，选择应用升级，热更新，发布新补丁。
发布patch版本，选择补丁文件之后会自动从补丁包的YAPATCH.MF去寻找base版本以及app版本，注意这里的base版本必须联网上报（必须在联网的情况下启动app），才可以上传补丁成功。如果没有
上传了补丁包可以选择下发的范围：
开发设备：仅仅针对设置了开发设备。
利用代码：Bugly.setIsDevelopmentDevice(this, true);设置为开发者设备。
全量设备：针对所有的用户。
自定义：可以设置下发范围:随机下发设置的版本数量，还可以设置android版本范围，仅仅在这个范围内才会下发并且生效。
下发补丁之后：
里面包括了激活的用户数量以及下发的数量，在操作过程中我们可能对于上个补丁不太满意，我们需要发布一个新的补丁，bugly提供了2中操作。
停止下发：点击之后将不会在下发bugly补丁，但是之前已经下载并且激活的不会删除掉补丁。
撤回：点击之后将停止下发补丁，并且之前已经下载并且激活的用户将会删除掉补丁包，并且恢复到基准包的版本。
检查patch包是否生效：
基准包执行效果图：
修复之后的效果图：
不能立即生效，需要吧app至于后台一段时间才能生效。
如果你的手机root的话，可以在data/data/app包名目录下有一个tinker目录，里面就有对于的patch补丁包下载在里面。
如果用户以及补丁下载成功以及激活的都会有统计的。
热更新加固：
之前的tinker只有1.7.5之前支持加固，tinker 1.7.8 可以通过 isProtectedApp 开启加固支持，这种模式仅仅可以使用在加固应用中。
isProtectedApp=true
加固厂商 测试
腾讯云·乐固 Tested
爱加密 Tested
梆梆加固 Tested
360加固暂不支持，需要等待新版本发布
其他请自行测试，只要满足下面规则的都可以支持
最后附上自己在github上面的BuglyDemo。
