本文主要是介绍Android 集成Tinker踩坑记录,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
背景
热修复早已不是什么新鲜技术了,各个大厂基本都有自己的热修复方案。
关于各个热修方案的对比就不赘述了,网上一搜一大堆。直接看Tinker官方文档 就行。
这里说下为什么选择Tinker吧
先说优点
- 开源免费,讲道理,要不是免费肯定用集成起来更简单的Sophix了
- 目前仍处于维护状态
- 腾讯背书,官方说微信也在用,那我们自然没什么好顾虑的了
说完优点再吐槽下缺点
- 文档基本没怎么更新了,项目稍微新一点的集成起来需要踩坑
- demo比较老,agp版本很低
- 集成使用比较麻烦,代码量相较于常规的其它三方sdk多很多
- 处于open状态的issues数量比较多,开源项目遇到奇奇怪怪的问题只能尽量自己解决,肯定不会像商业sdk有技术快速支持的。
- 补丁的版本管理和维护需要自己搭建
集成步骤
这里我说下我自己比较推荐的集成步骤
- 先把源码下载下来,跑通,能够在demo上实现热修的功能
- 新建一个干净的空项目,从0开始集成tinker,同样要实现热修的功能
- 最后再往自己的项目中集成
集成步骤官方文档写的也比较清楚了,只是demo的agp版本比较老,一些配置的增加也没有在文档中更新。因此,在高版本的AGP项目中集成起来还是要踩一些坑的。
这里我把我集成tinker时踩的坑记录一下,有些坑也花了点时间去解决,希望能帮到需要的同学。
先说下我的AGP版本,这个可能会影响到Tinker
- AGP版本是7.0.4
- gradle版本是7.3.3
- tinker用的就是最新的版本(目前是:v1.9.14.25.3)
AGP7.x 配置Tinker
我们都知道AGP7开始,之前的classpath配置有所变更,如果你是AGP7以上的版本,需要在settings.gradle添加tinker的配置
pluginManagement {repositories {google()mavenCentral()gradlePluginPortal()}resolutionStrategy {/*配置tinker*/eachPlugin {if (requested.id.id == "com.tencent.tinker.patch") {useModule("com.tencent.tinker:tinker-patch-gradle-plugin:1.9.14.25.3")}}}
}
随后就正常在App模块里的build.gradle添加tinker所需依赖即可
示例:
plugins {id 'com.android.application'id 'org.jetbrains.kotlin.android'id 'com.tencent.tinker.patch'//tinker插件id 'kotlin-kapt'
}
生成补丁包时提示 Could not resolve all files for configuration ‘:app:sevenZipToolsLocator’.
我是在M1的电脑上生成补丁包,过程中提示找不到7zip。
根据报错的信息 Could not find SevenZip-1.1.10-osx-aarch_64.exe (com.tencent.mm:SevenZip:1.1.10).
中的.exe 也能猜出来是平台相关的问题。
这里我们可以按照以下步骤做解决这个问题
brew install p7zip
本地安装下7zip- 获取本地安装的7zip路径
which 7za
- 更改下配置,把zipArtifact配置注释掉,path更改为本机安装的7za路径
sevenZip {/*** optional,default '7za'* the 7zip artifact path, it will use the right 7za with your platform*/
// zipArtifact = "com.tencent.mm:SevenZip:1.1.10"/*** optional,default '7za'* you can specify the 7za path yourself, it will overwrite the zipArtifact value*//*这里改成本地安装的7za路径*/path = "/opt/homebrew/bin/7za"}
然后再次执行生成补丁任务即可。
这个问题我看其他人也遇到了,也回答了一下,参照这个也可以:https://github.com/Tencent/tinker/issues/1718
Tinker配置
官方文档和demo中的配置不是很全,毕竟文档很久没更新了,而且demo的配置比较复杂,我这里实际上用不到这么复杂的配置,下面是精简后的配置,仅供参考
/*我这里直接就用版本号来作为tinkerid了*/
def versionName = android.defaultConfig.versionName
print("versionName:" + versionName)/*存放要生成补丁的文件夹*/
def tinkerPath = "${projectDir}/tinker/"/*** 生成补丁包的配置* 参考官方文档:https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97*/
tinkerPatch {tinkerEnable = true/*旧包*/
// oldApk = "${buildDir.path}/outputs/apk/xxx.apk"oldApk = "${tinkerPath}/app-release.apk"// 补丁输出路径 选填:默认在app/build/outputs/tinkerPatch下outputFolder = "${tinkerPath}/patch/"ignoreWarning = true // 是否忽略警告allowLoaderInAnyDex = true // 是否支持在任意dex中加载类removeLoaderForAllDex = trueuseSign = true // 在运行过程中需要验证基准apk包与补丁包的签名是否一致,release包肯定是需要签名的,默认值是truebuildConfig {/*指定旧APK的mapping文件 可减少补丁包大小*/applyMapping = "${tinkerPath}/mapping.txt"/*旧APK的resource_mapping文件 可减少补丁包大小*/applyResourceMapping = "${tinkerPath}/R.txt"/*生成tinkerid 补丁包在合并时会验证布丁包的id和基准包的id是否一致 简单点可以用versionName*/tinkerId = versionName/*是否使用加固模式,只在加固包的情况下设置为true*/isProtectedApp = false/*是否支持新增非export的activity 测试设置为true也不知道新增页面,会报错*/supportHotplugComponent = false/*如果keepDexApply为true,则dex所在的类引用旧的apk。打开这个可以减少dex-diff文件的大小。*/keepDexApply = false}// dex相关的配置项dex {/*** 只能是'raw'或者'jar'。 对于'raw'模式,我们将会保持输入dex的格式。对于'jar'模式,我们将会把输入dex重新压缩封装到jar。* 如果你的minSdkVersion小于14,你必须选择‘jar’模式,而且它更省存储空间,但是验证md5时比'raw'模式耗时。默认我们并不会去校验md5,一般情况下选择jar模式即可。*/dexMode = "jar"/*** 需要处理dex路径,支持*、?通配符,必须使用'/'分割。路径是相对安装包的,例如assets/...* */pattern = ["classes*.dex", "assets/secondary-dex-?.jar"]// 需要处理dex路径,支持*、?通配符,必须使用'/'分割。路径是相对安装包的,例如assets/.../*** 这一项非常重要,它定义了哪些类在加载补丁包的时候会用到。这些类是通过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依然需要手动填写* */loader = ["com.yzq.hotfix.App"//这里写你自己的Application类]}// lib相关的配置项lib {/*** 需要处理lib路径,支持*、?通配符,必须使用'/'分割。与dex.pattern一致, 路径是相对安装包的,例如assets/...* 一般来讲我们的so文件都放在下面两个路径下面*/pattern = ["lib/*/*.so", "src/main/jniLibs/*/*.so"]}// res相关的配置项res {/*** 需要处理res路径,支持*、?通配符,必须使用'/'分割。与dex.pattern一致, 路径是相对安装包的,例如assets/...,务必注意的是,只有满足pattern的资源才会放到合成后的资源包。*/pattern = ["res/*", "assets/*", "resources.arsc", "AndroidManifest.xml"]/*** 支持*、?通配符,必须使用'/'分割。若满足ignoreChange的pattern,在编译时会忽略该文件的新增、删除与修改。 最极端的情况,ignoreChange与上面的pattern一致,即会完全忽略所有资源的修改。*/ignoreChange = ["assets/sample_meta.txt"]largeModSize = 100// 对于修改的资源,如果大于largeModSize,我们将使用bsdiff算法。这可以降低补丁包的大小,但是会增加合成时的复杂度。默认大小为100kb}// 7zip路径配置项,执行前提是useSign为truesevenZip {
// zipArtifact = "com.tencent.mm:SevenZip:1.2.17"/*** 系统中的7za路径,例如"/usr/local/bin/7za"。path设置会覆盖zipArtifact,若都不设置,将直接使用7za去尝试。* 这里改成本地安装的7za路径* */path = "/opt/homebrew/bin/7za"
// path = "/Users/yuzhiqiang/.gradle/caches/modules-2/files-2.1/com.tencent.mm/SevenZip/1.2.17"}
}
这里说一下applyMapping和applyResourceMapping的文件从哪里来。
一般我们通过assembleRelease打完包后,可以在build文件夹中找到apk文件和mapping文件
R文件则是在intermediates文件夹内
tinker-patch-cli jar包如何获取
如果你的补丁需要通过命令行来生成,那么你就需要用到tinker-patch-cli的jar包。那这个jar包如何获取呢?
也比较简单,首先,把tinker源码拉下来,找到buildTinkerSdk这个task,执行一下
随后在build目录中就能获取到jar包了。
至于如何使用看遵循官方文档即可。
不想编译的直接下载这个 Tinker Cli Jar文件 就行,已经生成好了。
Tinker加固包的补丁如何生成
加固包的补丁生成步骤如下
- isProtectedApp 配置要设置为true
- 编译出加固前的基准包,保存好,后面生成补丁要用。
- 加固前的基准包进行加固,正常上应用商店,用户使用的是加固后的基准包
- 发现bug,进行修复。编译出加固前的新包
- 使用加固前的基准包和加固前的新包产生补丁
- 测试补丁是否正常,通过测试后发布补丁
也就是说,产生补丁都是加固前的包。使用补丁是在加固后的包上使用。不要搞错了。
补丁管理规则
这里我们需要跟服务端一起制定规则,给个参考如下:
- 版本和补丁之间的关系是通过配置的tinkerId关联的,补丁和App的tinkerid必须一致才能正常加载,否则校验是不通过的。
- App一旦发布就是基准包,此时一定要保存好这个基准包(未加固前的包)以及mapping.txt和R.txt文件,后续改版本补丁的生成都是基于该基准包生成
- App在一个版本内可以包含多个补丁,新补丁必须要包含旧补丁已修复的代码。
- 补丁生效前一定要先通过测试才能下发。
- 服务端给补丁时一定是当前App版本所对应的最新版本的补丁。
看官方文档也能看出来,Tinker的集成以及使用还是比较繁琐的,代码量也不小,具体的代码还需要根据自己的App来做更改。
好了,本篇文章就是这样,希望能帮到你。
如果你觉得本文对你有帮助,麻烦动动手指顶一下,可以帮助到更多的开发者,如果文中有什么错误的地方,还望指正,转载请注明转自喻志强的博客 ,谢谢!
这篇关于Android 集成Tinker踩坑记录的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!