一直等着Tinker更新版本，终于在前段时间，Tinker和各大加固厂商协作支持了加固的热修复，因为Tinker热修复需要后台去发布补丁，所以我们就选择了同样是腾讯旗下的Bugly，Bugly还支持异常捕获分析和运营统计等。话不多说直接开始我们今天的正文吧。
1. - 准备工作 Bugly官网
首先我们去注册、登陆，创建应用拿到我们的appId备用。
2. -配置
- 首先新建一个工程TinkerBugly。
- 然后我们添加Bugly需要的依赖：
打开app目录下的build.gradle
在dependencies下添加：
// 多dex配置 compile "com.android.support:multidex:1.0.1" // 远程依赖集成方式（推荐） compile "com.tencent.bugly:crashreport_upgrade:latest.release"
文章图片
添加
// 依赖插件脚本
apply from: 'tinker-support.gradle'
文章图片
可能有朋友就要问了，这个脚本在哪里啊，不着急，我们这就来添加这个脚本文件，Bugly为了让开发者更清晰的搞清楚配置，所以把热修复的配置单独脱离出来建立了一个脚本文件
tinker-support.gradle
现在我们就来建立这个文件，首先我们在app目录下新建file如图所示：
文章图片
命名就是刚刚我们应用的tinker-support.gradle
文章图片
建好文件之后和build.gradle长的一样只是没有内容而已，那么我们就来给他添加内容
apply plugin: 'com.tencent.bugly.tinker-support'def bakPath = file("${buildDir}/bakApk/")/**
* 此处填写每次构建生成的基准包目录
*/
def baseApkDir = "app-0510-13-53-33"/**
* 对于插件各参数的详细解析请参考
*/
tinkerSupport {// 开启tinker-support插件，默认值true
enable = true// tinkerEnable功能开关
tinkerEnable = 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 = "1.0.1-base"// 打多渠道补丁时指定目录
buildAllFlavorsDir = "${bakPath}/${baseApkDir}"//是否开启加固
isProtectedApp = trueenableProxyApplication = true}/**
* overrideTinkerPatchConfiguration开启后tinkerPatch不生效可以直接删除
* 一般来说,我们无需对下面的参数做任何的修改
* 对于各参数的详细介绍请参考:
* https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97
*/
tinkerPatch {
tinkerEnable = true
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 = "base-2.0.1"
}
}
把上面的代码都复制进去，然后Sync Now或则
文章图片
这里我们发现报错了，提示我们没有找到com.tencent.bugly.tinker-support，那么我现在去配置它，现在我们打开工程目录下的build.gradle文件，在dependencies中添加
classpath 'com.tencent.bugly:tinker-support:1.0.7'
文章图片
现在我们点击右上角的Try Again或则之前说的那个Sync按钮，结果妈的报错变了是吧，那是因为我们的配置还没完呢，继续，现在我们去申明权限，打开AndroidManifest文件添加如下权限：
然后在下面的application标签下添加 android：name=”MyApplication”
文章图片
好的 既然指定了application，那么我们就需要去新建一个MyApplication
public class MyApplication extends Application {@Override
public void onCreate() {
super.onCreate();
//腾讯bugly
// 设置是否开启热更新能力，默认为true
Beta.enableHotfix = true;
// 设置是否自动下载补丁
Beta.canAutoDownloadPatch = true;
// 设置是否提示用户重启
Beta.canNotifyUserRestart = true;
// 设置是否自动合成补丁
Beta.canAutoPatch = true;
/**
* 补丁回调接口，可以监听补丁接收、下载、合成的回调
*/
Beta.betaPatchListener = new BetaPatchListener() {
@Override
public void onPatchReceived(String patchFileUrl) {
Toast.makeText(getApplicationContext(), patchFileUrl, Toast.LENGTH_SHORT).show();
}@Override
public void onDownloadReceived(long savedLength, long totalLength) {
Toast.makeText(getApplicationContext(), String.format(Locale.getDefault(),
"%s %d%%",
Beta.strNotificationDownloading,
(int) (totalLength == 0 ? 0 : savedLength * 100 / totalLength)), Toast.LENGTH_SHORT).show();
}@Override
public void onDownloadSuccess(String patchFilePath) {
Toast.makeText(getApplicationContext(), patchFilePath, Toast.LENGTH_SHORT).show();
Beta.applyDownloadedPatch();
}@Override
public void onDownloadFailure(String msg) {
Toast.makeText(getApplicationContext(), msg, Toast.LENGTH_SHORT).show();
}@Override
public void onApplySuccess(String msg) {
Toast.makeText(getApplicationContext(), msg, Toast.LENGTH_SHORT).show();
}@Override
public void onApplyFailure(String msg) {
Toast.makeText(getApplicationContext(), msg, Toast.LENGTH_SHORT).show();
}@Override
public void onPatchRollback() {}
};
long start = System.currentTimeMillis();
// 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId,调试时将第三个参数设置为true
Bugly.init(this, "appId", true);
long end = System.currentTimeMillis();
Log.e("init time--->", end - start + "ms");
}
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// you must install multiDex whatever tinker is installed!
MultiDex.install(base);
// 安装tinker
Beta.installTinker();
}}记得把你们的appId填上去哦！
这个时候我们在按下Sync按钮，发现是不是没有报错了，哈哈，那说明我们的配置完成了，是不是有种很多很长的感觉，其实不多啦，大家主要记住就修改以下几个文件：
- App目录下build.gradle (添加依赖)
- App目录下添加tinker-support.gradle (热修复的一些配置)
- 工程目录下的build.gradle
- 修改AndroidManifest (申明权限、设置Application)
- 新建一个继承Application的MyApplication (app启动时安装Tinker和热修复的检查、下载、合成等)
3. -运用
- 在开始使用热修复的之前我们需要配置一下签名文件
还是在app目录下的build.gradle中android下添加：
// 签名配置
signingConfigs {
signingConfigs {
release {
try {
storeFile file("./keystore/release.keystore")
storePassword "testres"
keyAlias "testres"
keyPassword "testres"
} catch (ex) {
throw new InvalidUserDataException(ex.toString())
}
}debug {
storeFile file("./keystore/debug.keystore")
}
}
}这里需要你自己提供签名文件，如果不清楚请自行百度。
我们在更改一下里面的buildTypes这里我们选择不混淆
buildTypes {
release {
minifyEnabled false//是否混淆
signingConfig signingConfigs.release
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
debuggable false
minifyEnabled false
signingConfig signingConfigs.debug
}
}然后我们在添加多渠道包的配置
productFlavors {
bugly {}xiaomi {}yyb {}
}这里简单指定三个渠道包的名称
到这里我们的所有东西都齐全了，来吧。
2.打基准包
首先我们需要打开app目录下的tinker-support.gradle
如下图：
文章图片
这里注释已经非常清楚，我就简单说一下打基准包需要修改的地方，
我们需要修改tinkerId，这里我来给大家屡清楚这个tinkerId到底怎填，bugly规定我们tinkerId必须保证唯一性，假设我们当前上线应用版本是1.0，那么我们一般就给tinkerId赋值为1.0.1-base，（基线版本用base后缀，补丁用patch）,我们给这个版本发第一次补丁，tinkerId=“1.0.1-patch”,如果这个版本还有bug我们在打一个补丁这时tinkerId=“1.0.2-patch”
文章图片
运行这个命令后，我们可以看到后台在执行各个命令，稍等片刻我们便可以看到在app目录下的build目录中生成了一个bakApk文件夹如下
文章图片
下面那个app-0511-12-08-22就是我们的基线版本了，我们打开来看看
文章图片
里面包括了我们指定的三个渠道包。
到这里我们的基准包就算是完成了，接下来就是修改bug，打补丁了。
3.打补丁包
打补丁包之前我们先去修改bug，由于之前我们并没有任何bug，那么我们就直接打开MainActivity.class做一些修改吧！
我们在onCreate()中加上一句
Toast.makeText(MainActivity.this,"热修复成功",Toast.LENGTH_SHORT).show();
现在我们来修改配置，还是到app目录下的tinker-support.gradle做如下修改：
文章图片
修改完成之后就可以打补丁包了
这里我们因为是多渠道包，而每个渠道包都有唯一的一个补丁包所以，我们选择打出所有渠道包的补丁包
文章图片
后台打好之后，还是在app目录下的build目录下outputs中生成一个patch文件夹，如下：
文章图片
patch_signed_7zip.apk就是我们的补丁包了
我们可以双击它看看，如下
文章图片
我们可以看到bugly提供的tinkerId在这里用到了，有个MF文件，里面存着我们目标版本、基线tinkerId、补丁thinkerId，由于我们选择了多渠道分包，所以在基线和补丁的id前面都带着渠道包名，这就是为了区分，这个文件也就是匹配我们补丁和基线包的。
似乎忘记了什么？哦，加固，在前面配置的时候我们是把加固的打开的，所以我们先把生成的基线包哪去加固，这里说说tinker支持那些加固:
文章图片
基本包含了主流加固厂商，我们这次测试就选择爱加密加固，我先把基准包哪去加固，这里就不具体说怎么加固了，记得正式用的时候每个渠道包中的apk都要加固哦，我随便加固一个测试就行了，加固需要一段时间，给大家闲扯一下，其实在android studio里面通过productFlavors的方式多渠道打包很慢，加固起来也麻烦，但是bugly规定了只能通过这种方式多渠道打包，如果大家不进行多渠道分包可以把productFlavors配置删除，还有把tinker-support.gradle中的
// 打多渠道补丁时指定目录
buildAllFlavorsDir = "${bakPath}/${baseApkDir}" 注释掉，加固就那么一个开关
//是否开启加固
isProtectedApp = true 不需要也可以注释或则false，默认是false，让我想想还有些什么问题，还有混淆，如果大家需要，可以自己去配置，在文章尾部会贴出参考文档。
时间一分一秒的过去。。。。。。。。。
终于好了，加固的apk是没有签名的我们进行重新签名，并安装到手机上，我加固的是bugly名称渠道包的，现在我已经安装上了
文章图片
4.上传补丁包
找到我们的产品，应用升级，热修复，上传补丁，选择补丁包，这里需要提示大家一下，在我们安装基准包的时候，应用会自动上报联网，也就是说bugly后台就知道有这个基线版本，后续上传补丁包，才会去匹配，自动识别匹配的目标版本，所以必须保证安装上报联网，才上传补丁，不然会提示你找不到匹配的版本，这里还有个坑，或许你用搜狗浏览器会扯拐，所以建议使用chrome浏览器。
文章图片
我这里匹配到目标版本了，说明我的应用已经上报联网了，现在我们进行全量下发，虽然只有我一个手机，但是无所谓，我们来看看，有什么反应。
文章图片
这里还没有已下发设备，因为tinker是需要重启的那么我们先重启应用，一定要杀死应用哈，看看有什么反应
文章图片
【Tinker热修复加固】陆续弹出了下载补丁、合成补丁的提示，最后完成了我们只需要杀死应用重启，我们的补丁就生效了
文章图片
这里要说一下，bugly是提供了弹出升级对话框的，这里我没有加入进来，需要的同学自己查看文档。
4. -结尾 还有几句话要说：
这篇文章使用的接入方式是一键接入，意思是这种事bugly通过反射的方法简化了一些构造，在我的另一篇文章中说道过，需要对application进行改造，就是这个地方不一样，如果大家想要兼容更好，可以选择哪种方法，官方提供了demo，官方里面有两个一个一键接入的一个就是我刚刚说的哪种，大家可以看看。
这里贴出一些对你有帮助的链接
https://bugly.qq.com/docs/user-guide/instruction-manual-android-hotfix/?v=20170504092424
——Bugly文档
https://github.com/Tencent/tinker
——tinker GitHub地址
http://v.qq.com/boke/gplay/9f3b4b1232819f453becd2356a3493c4_bme000301803d13_5_p0398b38vwl.html
——Bugly提供的视频教程
https://bugly.qq.com/docs/release-notes/release-android-beta/?v=20170511110143
——sdk包含官方的demo
如果大家觉得还行，就帮忙点个赞咯，谢谢各位。
