项目中之前已经接入bugly的异常收集和全量更新SDK,为了应对bug及时修复以及一些改动不太大的需求,准备接入Tinker。而Bugly已经对Tinker做了很好的支持,不用从头到尾接一遍。
Bugly 集成就包含了上报,升级,热修复三合一。
思考
遇到的问题
1、基准包打出来后必须要进行联网上报,意思就是说要在有网络的手机上启动一次,Bugly才能上报TinkerId,基于这个版本生成的补丁包就可以匹配到它
2、两次传入的tinkerId是否一样?
不一样的,编译补丁包时,tinker会自动读取基准包AndroidManifest的tinkerId作为package_meta.txt中的TINKER_ID。将本次编译传入的tinkerId,作为package_meta.txt的NEW_TINKER_ID。
你必须要上传build/outputs/patch目录下的补丁包,
每次发版都要保留基准包、混淆配置文件、资源Id文件?
当然啦,你不保存基准包,我们打补丁怎么知道要基于哪个版本打补丁?所以建议大家每次发版注意保存基准apk包,还有对应编译生成的mapping文件和R.txt文件。
Q:完整的测试流程是怎样的?
打基准包安装并上报联网(注:填写唯一的tinkerId)
对基准包的bug修复(可以是Java代码变更,资源的变更)
修改基准包路径、修改补丁包tinkerId、mapping文件路径(如果开启了混淆需要配置)、resId文件路径
执行buildTinkerPatchRelease打Release版本补丁包
选择app/build/outputs/patch目录下的补丁包并上传(注:不要选择tinkerPatch目录下的补丁包,不然上传会有问题)
编辑下发补丁规则,点击立即下发
杀死进程并重启基准包,请求补丁策略(SDK会自动下载补丁并合成)
再次重启基准包,检验补丁应用结果
查看页面,查看激活数据的变化
为什么我的补丁包上传匹配到的不是我的基准包版本?
原因:你之前测试时使用过和当前基准包版本一样的tinkerid,bugly补丁下发是按照tinkerid下发。 多个基准包使用了同一个tinkerid那说明这几个基准包都能收到你当前上传的补丁。
对Tinker的理解
、首先,你需要了解 TinkerId ,相信很多人看他官方的文档后都知道这个东西,
1、他需要在生成基准包(你要正式往线上发布的版本)的时候设置tinkerID
2、在打补丁的时候还需要再次设置tinkerID,而且这次的tinker和第一步的id不能相同
很多人对此是很不理解的?原来,你在第一步生成基准包的时候,tinker插件会自动将tinkerID和App当前的版本Version对应起来。例如,你当前的app版本是2.3.1.30,tinkerID设置为2.3.1.30-base,那么这个2.3.1.30和2.3.1.30-base就会对应起来,tinker插件会自动在打包的时候插入到Mainfest.xml文件中。
好了,下面你的2.3.1.30版本app发现问题,你需要打一个补丁包进行修复,这时候你需要再次设置tinkerID为2.3.1.30-patch-03。tinker插件会自动把基准包的的tinkerID和本次补丁包的tinkerID保存在插件中。此时,当你将这个补丁上传至bugly平台,
你的补丁id为2.3.1.30-patch-03 —> 基准包id 2.3.1.30-base ---> 你出现问题的App版本2.3.1.30
一、添加插件依赖,在根目录的build.gradle中:
classpath "com.tencent.bugly:tinker-support:1.1.1"
二、集成SDK:
app module的build.gradle中添加多dex配置、 添加bugly dependencies
//Tinker
compile "com.android.support:multidex:1.0.3" // 多dex配置
//注释掉原有bugly的仓库
//compile 'com.tencent.bugly:crashreport:latest.release'//其中latest.release指代最新版本号,也可以指定明确的版本号,例如1.3.4
compile 'com.tencent.bugly:crashreport_upgrade:1.3.6'
// 指定tinker依赖版本(注:应用升级1.3.5版本起,不再内置tinker)
compile 'com.tencent.tinker:tinker-android-lib:1.9.9'
compile 'com.tencent.bugly:nativecrashreport:3.6.0'
//其中latest.release指代最新版本号,也可以指定明确的版本号,例如2.2.0
app module的build.gradle中添加依赖插件脚本:
// 依赖插件脚本
apply from: 'tinker-support.gradle'
三、初始化SDK:
Tinker 初始化分为两种情况 本文采用不用改造Application的情况,
据官方描述,改造Application的初始化方式兼容性会比不改改Application 要好
官方初始化参考
取 enableProxyApplication = true的情况
在自己的Application里面添加如下代码,别忘记在配置文件配置Application
public void onCreate() {
super.onCreate();
if (sInstance == null) {
sInstance = this;
}
// 这里实现SDK初始化,appId替换成你的在Bugly平台申请的appId
// 调试时,将第三个参数改为true
Bugly.init(this, "c45d2fc4ba", true);
}
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// you must install multiDex whatever tinker is installed!
MultiDex.install(base);
// 安装tinker
Beta.installTinker();
}
到此为止 Tinker的接入已经全部完成,接下来看他是如何使用的,
1、编译基准包
配置基准包的tinkerId
tinkerId最好是一个唯一标识,例如git版本号、versionName等等。 如果你要测试热更新,你需要对基线版本进行联网上报。
这里强调一下,基线版本配置一个唯一的tinkerId,而这个基线版本能够应用补丁的前提是集成过热更新SDK,并启动上报过联网,这样我们后台会将这个tinkerId对应到一个目标版本,例如tinkerId = "bugly_1.0.0" 对应了一个目标版本是1.0.0,基于这个版本打的补丁包就能匹配到目标版本。
执行assembleRelease编译生成基准包:
这个会在build/outputs/bakApk路径下生成每次编译的基准包、混淆配置文件、资源Id文件,如下图所示:
实际应用中,请注意保存线上发布版本的基准apk包、mapping文件、R.txt文件,如果线上版本有bug,就可以借助我们tinker-support插件进行补丁包的生成。
启动apk,上报联网数据
我们每次冷启动都会请求补丁策略,会上报当前版本号和tinkerId,这样我们后台就能将这个唯一的tinkerId对应到一个版本,大家测试的时候可以打开logcat查看我们的日志,如下图所示:
打开LogCat 如果看到这两条日志 ,表示联网上报成功了。
如果看不到log,您需要将bugly初始化的第三个参数设置为true才能看到。
2、对基线版本的bug修复
1、首先是要对有bug的代码进行修复
2、修改配置,修改点全是基于开始打基准包出来的结果。要保持一致
填写生成基准线的目录
3、执行构建补丁包的task
大家这里可能会有一个疑问,补丁版本是怎么匹配到目标版本的,可以双击patch包,提供的插件会在tinker生成的patch包基础上插入一个MF文件:
4、上传补丁包到平台
上传补丁包到平台并下发编辑规则
5、测试补丁应用效果
启动app应用patch
如果匹配到目标版本,后台就会下发补丁策略,可以在logcat看到如下日志:
下载成功之后,会立即去合成补丁,可以看到patch合成的日志:
再次重启app查看效果 发现Bug 已经修复(第一次启动时加载合成补丁,再次启动就是使用)
注意上传补丁后 立刻去启动app,有时候没有下载,我猜想可能有延时,具体原因不知。
试着第三次启动看看吧,这时候会显示日志,已经下载
参考文章
githubDemo