gradle接入
gradle是推荐的接入方式,在gradle插件tinker-patch-gradle-plugin
中我们帮你完成proguard、multiDex以及Manifest处理等工作。
添加gradle依赖
在项目的build.gradle中,添加tinker-patch-gradle-plugin
的依赖
- buildscript {
- dependencies {
- classpath ('com.tencent.tinker:tinker-patch-gradle-plugin:1.9.1')
- }
- }
然后在app的gradle文件app/build.gradle,我们需要添加tinker的库依赖以及apply tinker的gradle插件.
- dependencies {
- //可选,用于生成application类
- provided('com.tencent.tinker:tinker-android-anno:1.9.1')
- //tinker的核心库
- compile('com.tencent.tinker:tinker-android-lib:1.9.1')
- }
- ...
- ...
- //apply tinker插件
- apply plugin: 'com.tencent.tinker.patch'
gradle参数详解
我们将原apk包称为基准apk包,tinkerPatch直接使用基准apk包与新编译出来的apk包做差异,得到最终的补丁包。gradle配置的参数详细解释如下:
参数 | 默认值 | 描述 |
---|---|---|
tinkerPatch | 全局信息相关的配置项 | |
tinkerEnable | true | 是否打开tinker的功能。 |
oldApk | null | 基准apk包的路径,必须输入,否则会报错。 |
newApk | null | 选填,用于编译补丁apk路径。如果路径合法,即不再编译新的安装包,使用oldApk与newApk直接编译。 |
outputFolder null | 选填,设置编译输出路径。默认在build/outputs/tinkerPatch 中 | |
ignoreWarning | false | 如果出现以下的情况,并且ignoreWarning为false,我们将中断编译。因为这些情况可能会导致编译出来的patch包带来风险: 1. minSdkVersion小于14,但是dexMode 的值为"raw"; 2. 新编译的安装包出现新增的四大组件(Activity, BroadcastReceiver…); 3. 定义在dex.loader用于加载补丁的类不在main dex中; 4. 定义在dex.loader用于加载补丁的类出现修改; 5. resources.arsc改变,但没有使用applyResourceMapping编译。 |
useSign | true | 在运行过程中,我们需要验证基准apk包与补丁包的签名是否一致,我们是否需要为你签名。 |
buildConfig | 编译相关的配置项 | |
applyMapping | null | 可选参数;在编译新的apk时候,我们希望通过保持旧apk的proguard混淆方式,从而减少补丁包的大小。这个只是推荐设置,不设置applyMapping也不会影响任何的assemble编译 。 |
applyResourceMapping | null | 可选参数;在编译新的apk时候,我们希望通过旧apk的R.txt 文件保持ResId的分配,这样不仅可以减少补丁包的大小 ,同时也避免由于ResId改变导致remote view异常 。 |
tinkerId | null | 在运行过程中,我们需要验证基准apk包的tinkerId是否等于补丁包的tinkerId。这个是决定补丁包能运行在哪些基准包上面,一般来说我们可以使用git版本号、versionName等等。 |
keepDexApply | false | 如果我们有多个dex,编译补丁时可能会由于类的移动导致变更增多。若打开keepDexApply 模式,补丁包将根据基准包的类分布来编译。 |
isProtectedApp | false | 是否使用加固模式,仅仅将变更的类合成补丁。注意,这种模式仅仅可以用于加固应用中。 |
supportHotplugComponent(added 1.9.0) | false | 是否支持新增非export的Activity |
dex | dex相关的配置项 | |
dexMode | jar | 只能是'raw'或者'jar'。 对于'raw'模式,我们将会保持输入dex的格式。对于'jar'模式,我们将会把输入dex重新压缩封装到jar。如果你的minSdkVersion小于14,你必须选择‘jar’模式,而且它更省存储空间,但是验证md5时比'raw'模式耗时。默认我们并不会去校验md5,一般情况下选择jar模式即可。 |
pattern | [] | 需要处理dex路径,支持、?通配符,必须使用'/'分割。路径是相对安装包的,例如assets/… |
loader | [] | 这一项非常重要,它定义了哪些类在加载补丁包的时候会用到。这些类是通过Tinker无法修改的类,也是一定要放在main dex的类。这里需要定义的类有: 1. 你自己定义的Application类; 2. Tinker库中用于加载补丁包的部分类,即com.tencent.tinker.loader.; 3. 如果你自定义了TinkerLoader,需要将它以及它引用的所有类也加入loader中; 4. 其他一些你不希望被更改的类,例如Sample中的BaseBuildInfo类。这里需要注意的是,这些类的直接引用类也需要加入到loader中。或者你需要将这个类变成非preverify。5. 使用1.7.6版本之后的gradle版本,参数1、2会自动填写。若使用newApk或者命令行版本编译,1、2依然需要手动填写 |
lib | lib相关的配置项 | |
pattern | [] | 需要处理lib路径,支持、?通配符,必须使用'/'分割。与dex.pattern一致, 路径是相对安装包的,例如assets/… |
res | res相关的配置项 | |
pattern | [] | 需要处理res路径,支持、?通配符,必须使用'/'分割。与dex.pattern一致, 路径是相对安装包的,例如assets/…,务必注意的是,只有满足pattern的资源才会放到合成后的资源包。 |
ignoreChange | [] | 支持、?通配符,必须使用'/'分割。若满足ignoreChange的pattern,在编译时会忽略该文件的新增、删除与修改。 *最极端的情况,ignoreChange与上面的pattern一致,即会完全忽略所有资源的修改。 |
largeModSize | 100 | 对于修改的资源,如果大于largeModSize,我们将使用bsdiff算法。这可以降低补丁包的大小,但是会增加合成时的复杂度。默认大小为100kb |
packageConfig | 用于生成补丁包中的'package_meta.txt'文件 | |
configField | TINKER_ID, NEW_TINKER_ID | configField("key", "value"), 默认我们自动从基准安装包与新安装包的Manifest中读取tinkerId,并自动写入configField。在这里,你可以定义其他的信息,在运行时可以通过TinkerLoadResult.getPackageConfigByName得到相应的数值。但是建议直接通过修改代码来实现,例如BuildConfig。 |
sevenZip | 7zip路径配置项,执行前提是useSign为true | |
zipArtifact | null | 例如"com.tencent.mm:SevenZip:1.1.10",将自动根据机器属性获得对应的7za运行文件,推荐使用。 |
path | 7za | 系统中的7za路径,例如"/usr/local/bin/7za"。path设置会覆盖zipArtifact,若都不设置,将直接使用7za去尝试。 |
具体的参数设置事例可参考sample中的app/build.gradle。
tinkerPatch task详解
直接使用task:tinkerPatchVariantName
(例如tinkerPatchDebug、tinkerPatchRelease)即可自动根据Variant选择相应的编译类型,同时它还贴心的为我们完成以下几个操作:
将TINKER_ID自动插入AndroidManifest的meta项,输出路径为build/intermediates/tinker_intermediates/AndroidManifest.xml;
如果minifyEnabled为true,将自动将Tinker的proguard规则添加到proguardFiles中,输出路径为build/intermediates/tinker_intermediates/tinker_proguard.pro,
这里你不需要将它们拷贝到自己的proguard配置文件中
;如果multiDexEnabled为true,将自动生成Tinker需要放在主dex的keep规则。在tinker 1.7.6版本之前,你
需要手动将生成规则拷贝到自己的multiDexKeepProguard文件中
。例如Sample中的multiDexKeepProguard file("keep_in_main_dex.txt")
。在1.7.6版本之后,这里会通过脚本自动处理,无须手动填写。把dexOptions的jumboMode打开。
输出路径为:build/intermediates/tinker_intermediates/tinker_multidexkeep.pro。后你可以在build/outputs/tinkerPatch
中找到输出的文件。
多Flavor打包
有的时候我们希望通过flavor方式打包,在sample中提供了简单的用法事例:
1.通过flavor编译,这个时候我们可以看到bakApk路径是一个按照flavor名称区分的目录;
2.将编译目录路径填写到sample中tinkerBuildFlavorDirectory
,其他的几个字段不需要填写,这里会自动根据路径拼接;
- ext {
- tinkerBuildFlavorDirectory = "${bakPath}/app-1014-13-35-12"
- }
3.运行tinkerPatchAllFlavorDebug
或者tinkerPatchAllFlavorRelease
即可得到所有flavor的补丁包。