集成bugly热更新心得

前言

因项目需求，研究热更新。调查各种开源框架，最终选择腾讯平台bugly热更新，踏上了踩坑之旅。

遇到的问题

1.兼容性问题
2.配制gradle
3.打基线包与补丁包
4.依赖库版本问题

测试流程

1.配置基准包的grald,修改两个地方（1.基准包生成路径 baseApkDir，2.tinkerId 保证为一性）
2.运行gradle打出基准包安装并上报联网
3.修复基准包的bug（可以是Java代码，可以是资源文件，可以是so库文件）
4.修改基准包路径、修改补丁包tinkerId、mapping文件路径（如果开启了混淆需要配置）、resId文件路径
5.执行buildTinkerPatchRelease打Release版本补丁包
6.选择app/build/outputs/patch目录下的补丁包并上传（坑1：一定要基准包上报联网，不然上传补丁包会报错）
7.编辑下发补丁规则，点击立即下发
8.重启APP，看打印log，是否成功下发补丁（坑2:如果版本不一样，下发成功之后，补丁包也不会激活）
9.查看问题是否被修复

第一步：添加插件依赖

在工程根目录project:xxx下“build.gradle”文件中添加：

第一步.png

classpath "com.tencent.bugly:tinker-support:latest.release"
上面latest.release代表匹配插件最新版本

第二步：集成SDK，配制gradle

1.在app module的“build.gradle”文件中添加（示例配置）：

image.png

multidex:1.0.1:支持多dex配置
crashreport_upgrade:bugly依赖仓库
nativecrashreport:指的是支持ndk配置，如果不需要可以去掉

a.compile "com.android.support:multidex:1.0.1"
b.compile "com.tencent.bugly:crashreport_upgrade:1.3.4"
c.compile 'com.tencent.bugly:nativecrashreport:latest.release'

2.依赖插件的脚本

a.首先创建名为tinker-support.gradle

image.png

b.在build.gradle当中引用

image.png

c.配置tinker-support.gradle，这些配置官方文档都有直接copy过来

image.png

这里有几个重要的参数：
1.baseApkDir，在这里它指的是我们要打出的补丁包的所对应的基准包路径名，不能随便写。
2.tinkerId：在这里他代表基准包的唯一性（注意：基准包不能和补丁包tinkerId一样）.
3.enableProxyApplication:这里指的是：如果是true代表自己写appllicion，如果是false需要继承tinker自带的，默认是为 false。（官方给得解释是：如果是true,需要通过反射获取我们的appliction,兼容性不太好，false继承tinker自带的，但扩展性不高，需根据项目来做判断）。

第三步：初始化sdk

1.初始化appliction

在这里分两种情况：一种是enableProxyApplication = true,自己写appliction

image.png

注意：appId，一定要修改为平台申请appId,不然补丁会修复失败，如果是测试那么isDebug改为true,正式版本的时候改为false。

第二种情况enableProxyApplication = false, 继承TinkerApplication

image.png

注意：delegateClassName:一定修改为自己项目当中的SampleApplicationLike包名，这里容易忽略掉。

2.自定义的SampleApplicationLike

image.png

注意：appId同上修改为平台申请的appId,调试时改为true,上线时改为false.

第四步：AndroidManifest.xml配置

1.配置权限

image.png

2.活动配置，如果您想兼容Android N或者以上的设备，必须在AndroidManifest.xml文件中配置FileProvider来访问共享路径的文件。

image.png

第五步：混淆配置

1.为了避免混淆SDK，在Proguard的混淆文件中增加以下配置：
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.*{;}

2.如果你使用了支持-V4包，你还需要配置以下混淆规则：
-keep class android.support.*{;}

image.png

到这里基本工作完成，细心点，不会出什么问题。接下来准备打基准包和补丁包了。

第六步：基准包

1.编译基准包

需要修改一个地方：

image.png

修改tinkerId,保证它的唯一性，这里最好和 自己app版本保持一致，方便维护

2.执行assembleRelease编译生成基准包：

image.png

会在app/build/bakApk生成一个这样的文件

image.png

这里面有的app-release.apk就是我们需要上线的基线版本，请注意保存线上发布版本的基准apk包、mapping文件、R.txt文件，如果线上版本有bug，就可以借助我们tinker-support插件进行补丁包的生成。

验证是否成功，双击app-release.apk

image.png

查看tinkerId，是否和设置的一样。（注意，sdk 自动在tinkerId加一个前缀）这就是基准包啦，是不是很简单？

第六步：生成补丁包

1.修改baseApkDir路径为基准包路径

image.png

2.修改tinkerId,(注意这里的tinkerId,不能和基准包的tinkerId一样)

image.png

3.第三步，修复bug
这里会报空

image.png

修改后

image.png

4.执行构建补丁包的task

image.png

如果你要生成不同编译环境的补丁包，只需要执行TinkerSupport插件生成的task，比如buildTinkerPatchRelease就能生成release编译环境的补丁包。

生成的补丁包在build/outputs/patch目录下，其中7zip.apk就是我们需要使用的补丁包：

image.png

这个就是补丁包了，查看是否成功

打开补丁包可以看到里面会有一个YAPATCH.MF，这里面包含了我们是从base版本到patch版本：以及app的version信息

image.png

这里的from代表基准包tinkerId,to为补丁包的

第七步上传补丁包到平台

image.png

发布patch版本，选择补丁文件之后会自动从补丁包的YAPATCH.MF去寻找base版本以及app版本，注意这里的base版本必须联网上报（必须在联网的情况下启动app），才可以上传补丁成功。如果没有上报联网会提示你无法找到相应的版本
上传了补丁包可以选择下发的范围：

开发设备：仅仅针对设置了开发设备。

利用代码：Bugly.setIsDevelopmentDevice(this, true);设置为开发者设备。

全量设备：针对所有的用户。

自定义：可以设置下发范围:随机下发设置的版本数量，还可以设置android版本范围，仅仅在这个范围内才会下发并且生效。

下发补丁之后：

image.png

第八步测试是否成功

这里就不再进行演示了
需要注意两个地方
1.APP需要重新启动，等一小会就成功 了
2.查看控制台打印的log日志，如果成功会打印上传补丁包的备注信息
3如果以上操作都正确，还是没有成功，请查看设置是否激活，如果没有激活，看下依赖库版本是否一致，如果不一致，会在控制台打印
tinker patch exception com.tencent.tinker.loader.TinkerRuntimeException: Tinker Exception:can't recognize dex mode:xxxxx,jar
把版本改成一到处就OK了。

好了，就写到这里了，谢谢你能看到最后，有没有注意到的地方请多多包涵。