Tinker爬坑之路
来源:互联网 发布:tencent qq for linux 编辑:程序博客网 时间:2024/06/06 09:20
目的
热修复去年年底出的时候,变成了今年最火的技术之一。依旧记得去年面试的时候统一的MVP,然而今年却变成了RN,热修复。这不得不导致我们需要随时掌握最新的技术。不然可能随时会被淘汰。记得刚进公司,技术总监就给我们布置了学习RN和热修复的任务。不过因为临时调整去了产品部。学习的时间变少了。最近抽空看了关于热修复。于是,便有了此文。
概述
关于热修复,说白了就是线上修复,这个基本就不用多解释了。因为如果出了紧急bug。天天更新。用户不嫌烦我都嫌烦。而且频繁更新会导致用户的损失。
现在热修复的技术基本上有阿里的AndFix/Hotfix、QZone的方案、美团提出的思想方案以及腾讯的Tinker等。
我记得andfix我花了半天,hotfix花了半小时,tinker花了半个月。总之踩了蛮多的坑,走了蛮多的弯路的。
andfix算是比较简单的把。不过兼容性太差。hotfix用的阿里百川的后台,使用方法也不难。QZone的思路可以去看看。至于美团,应该是兼容性最好的了。据说,已经能兼容99%的手机了。最后,就是tinker了。tinker官方介绍有这么一句话:
Tinker已运行在微信的数亿Android设备上,那么为什么你不使用Tinker呢?
其实我当时感觉hotfix就够用了。不过当我看了这句话,我就准备去看看了。不然到时候被人瞧不起就完了。“什么?你除了tinker其他都不会?现在基本都是只要会个tinker就行了。”不管它,不管他,我们先入坑在说。
入坑Tinker
先放上官方的地址:神坑tinker
tinker的接入方式有2种,一种的命令行接入,一种是gradle接入。
命令行接入
命令行的接入和andfix以及hotfix的使用方法是差不多的。我也没去试~毕竟tinker是推荐用gradle的。好了。我们看看如何使用命令行接入的把。
项目依赖
我们需要在2个build.gradle进行
- moudle的gradle中:
buildscript { dependencies { classpath ('com.tencent.tinker:tinker-patch-gradle-plugin:1.7.11') }}
- app的gradle中:
//apply tinker插件apply plugin: 'com.tencent.tinker.patch'......dependencies { //可选,用于生成application类 provided('com.tencent.tinker:tinker-android-anno:1.7.11') //tinker的核心库 compile('com.tencent.tinker:tinker-android-lib:1.7.11') }
然后我们进行sync now,会有如下一句话:
tinkerId什么鬼?我也不知道。然后发现我们接入了gradle还要对其进行配置。好了。那么,我们接下来进行配置咯~
gradle配置
gradle有一屁股的参数。脑阔疼。我们先看看到底是干啥的:
tinkerPatch
全局信息相关的配置项tinkerEnabletrue是否打开tinker的功能。oldApknull基准apk包的路径,必须输入,否则会报错。newApknull选填,用于编译补丁apk路径。如果路径合法,即不再编译新的安装包,使用oldApk与newApk直接编译。outputFolder null选填,设置编译输出路径。默认在build/outputs/tinkerPatch
中ignoreWarningfalse如果出现以下的情况,并且ignoreWarning为false,我们将中断编译。因为这些情况可能会导致编译出来的patch包带来风险:1. minSdkVersion小于14,但是
dexMode
的值为”raw”;2. 新编译的安装包出现新增的四大组件(Activity, BroadcastReceiver…);
3. 定义在dex.loader用于加载补丁的类不在main dex中;
4. 定义在dex.loader用于加载补丁的类出现修改;
5. resources.arsc改变,但没有使用applyResourceMapping编译。useSigntrue在运行过程中,我们需要验证基准apk包与补丁包的签名是否一致,我们是否需要为你签名。
buildConfig
编译相关的配置项applyMappingnull可选参数;在编译新的apk时候,我们希望通过保持旧apk的proguard混淆方式,从而减少补丁包的大小。这个只是推荐设置,不设置applyMapping也不会影响任何的assemble编译
。applyResourceMappingnull可选参数;在编译新的apk时候,我们希望通过旧apk的R.txt
文件保持ResId的分配,这样不仅可以减少补丁包的大小
,同时也避免由于ResId改变导致remote view异常
。tinkerIdnull在运行过程中,我们需要验证基准apk包的tinkerId是否等于补丁包的tinkerId。这个是决定补丁包能运行在哪些基准包上面,一般来说我们可以使用git版本号、versionName等等。keepDexApplyfalse如果我们有多个dex,编译补丁时可能会由于类的移动导致变更增多。若打开keepDexApply
模式,补丁包将根据基准包的类分布来编译。isProtectedAppfalse是否使用加固模式,仅仅将变更的类合成补丁。注意,这种模式仅仅可以用于加固应用中。dex
dex相关的配置项dexModejar只能是’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版本之后版本,参数1、2会自动填写。
lib
lib相关的配置项pattern[]需要处理lib路径,支持*、?通配符,必须使用’/’分割。与dex.pattern一致, 路径是相对安装包的,例如assets/…res
res相关的配置项pattern[]需要处理res路径,支持*、?通配符,必须使用’/’分割。与dex.pattern一致, 路径是相对安装包的,例如assets/…,务必注意的是,只有满足pattern的资源才会放到合成后的资源包。
ignoreChange[]支持*、?通配符,必须使用’/’分割。若满足ignoreChange的pattern,在编译时会忽略该文件的新增、删除与修改。 最极端的情况,ignoreChange与上面的pattern一致,即会完全忽略所有资源的修改。largeModSize100对于修改的资源,如果大于largeModSize,我们将使用bsdiff算法。这可以降低补丁包的大小,但是会增加合成时的复杂度。默认大小为100kbpackageConfig
用于生成补丁包中的’package_meta.txt’文件configFieldTINKER_ID, NEW_TINKER_IDconfigField(“key”, “value”), 默认我们自动从基准安装包与新安装包的Manifest中读取tinkerId,并自动写入configField。在这里,你可以定义其他的信息,在运行时可以通过TinkerLoadResult.getPackageConfigByName得到相应的数值。但是建议直接通过修改代码来实现,例如BuildConfig。sevenZip
7zip路径配置项,执行前提是useSign为truezipArtifactnull例如”com.tencent.mm:SevenZip:1.1.10”,将自动根据机器属性获得对应的7za运行文件,推荐使用。path7za系统中的7za路径,例如”/usr/local/bin/7za”。path设置会覆盖zipArtifact,若都不设置,将直接使用7za去尝试。好了。胡乱一通介绍完了。然后官方来了句具体参考sample的配置。于是乎,我当时兴冲冲的把他的配置给复制过来了= =然后居然还是刚才的问题。我相信官方的demo他们敢放出来肯定没问题的。那么是我的问题咯?那就想办法改咯。最后问了好多小伙伴,终于。build success了~神器!!!那么为了让更多小伙伴不再入我的坑位,我这边贴出我的build.gradle的配置:
/**Tinker 相关配置----------------开始-----------------------------------*/def gitSha() { try { String gitRev = 'git rev-parse --short HEAD'.execute(null, project.rootDir).text.trim() if (gitRev == null) { throw new GradleException("can't get git rev, you should add git to system path or just input test value, such as 'testTinkerId'") } return gitRev } catch (Exception e) { throw new GradleException("can't get git rev, you should add git to system path or just input test value, such as 'testTinkerId'") }}def javaVersion = JavaVersion.VERSION_1_7def bakPath = file("${buildDir}/bakApk/")/** * 你可以使用组装版本构建你的基础apk * you can use assembleRelease to build you base apk * 使用修补补丁发布 * use tinkerPatchRelease -POLD_APK= -PAPPLY_MAPPING= -PAPPLY_RESOURCE= to build patch * 添加apk到build/bakApk * add apk from the build/bakApk */ext { /** * 出于某种原因,你可能想要忽略修改构建,例如即时运行调试构建 * for some reason, you may want to ignore tinkerBuild, such as instant run debug build? */ tinkerEnabled = true /** 对于正常的构建 * for normal build */ /** * 老的apk去构建补丁的apk * old apk file to build patch apk */ tinkerOldApkPath = "${bakPath}/app-debug-0605-16-34-49.apk" /** * 构建补丁apk的混淆映射文件 * proguard mapping file to build patch apk */ tinkerApplyMappingPath = "${bakPath}/app-debug-0605-16-34-49-mapping.txt" /** * 构建补丁apk时,R.txt必须输入资源文件是否改变 * resource R.txt to build patch apk, must input if there is resource changed */ tinkerApplyResourcePath = "${bakPath}/app-debug-0605-16-34-49-R.txt" /** * 只是用于构建所有的特点,如果不,可以忽略这一领域 * only use for build all flavor, if not, just ignore this field */ tinkerBuildFlavorDirectory = "${bakPath}/app-0605-16-34-49"}def getOldApkPath() { return hasProperty("OLD_APK") ? OLD_APK : ext.tinkerOldApkPath}def getApplyMappingPath() { return hasProperty("APPLY_MAPPING") ? APPLY_MAPPING : ext.tinkerApplyMappingPath}def getApplyResourceMappingPath() { return hasProperty("APPLY_RESOURCE") ? APPLY_RESOURCE : ext.tinkerApplyResourcePath}def getTinkerIdValue() { return hasProperty("TINKER_ID") ? TINKER_ID : gitSha()}def buildWithTinker() { return hasProperty("TINKER_ENABLE") ? TINKER_ENABLE : ext.tinkerEnabled}def getTinkerBuildFlavorDirectory() { return ext.tinkerBuildFlavorDirectory}if (buildWithTinker()) { apply plugin: 'com.tencent.tinker.patch' tinkerPatch { /** * 必要的,默认为null * 旧的apk路径,从build/bakApk中,用不同于新的apk去构建添加apk * necessary,default 'null' * the old apk path, use to diff with the new apk to build * add apk from the build/bakApk */ oldApk = getOldApkPath() /** * 可选的,默认为false * 这边有一些情况,我们或许会得到警告 * 如果它为true,我们会维护补丁的过程 * 情形1:最小sdk小于14,但你用原生的敏捷模式,当加载时,他必定会奔溃 * 情形2:在manifest中新建的android组件,当加载时,他必定会崩溃 * 情形3:在dex.loader不能保证在main dex中加载classes,他必须让tinker无效 * 情形4:在dex.loader加载classes文件改变时,去加载补丁时,改变他们是不会奔溃的,但这些变化不影响,你可以忽视他们 * 情形5:资源文件改变是,我们不能用应用资源去映射 * optional,default 'false' * there are some cases we may get some warnings * if ignoreWarning is true, we would just assert the patch process * case 1: minSdkVersion is below 14, but you are using dexMode with raw. * it must be crash when load. * case 2: newly added Android Component in AndroidManifest.xml, * it must be crash when load. * case 3: loader classes in dex.loader{} are not keep in the main dex, * it must be let tinker not work. * case 4: loader classes in dex.loader{} changes, * loader classes is ues to load patch dex. it is useless to change them. * it won't crash, but these changes can't effect. you may ignore it * case 5: resources.arsc has changed, but we don't use applyResourceMapping to build */ ignoreWarning = true /** * 可选的,默认为true * 是否签署的补丁文件,如果没有,你必须自定义,否则不能成功的加载补丁,在你创建类型时,我们将使用构建签订 * optional,default 'true' * whether sign the patch file * if not, you must do yourself. otherwise it can't check success during the patch loading * we will use the sign config with your build type */ useSign = true /** * 可选的,默认为true * 是否使用tinker创建 * optional,default 'true' * whether use tinker to build */ tinkerEnable = true /** * 警告,应用映射将影响android的构建 * Warning, applyMapping will affect the normal android build! */ buildConfig { /** * 可选的,默认为null * 如果我们用tinker补丁去构建补丁包,如果minifyEnabled启用了,你最好依赖旧的apk映射文件 * 警告: * 你一定要小心,他讲影响正常的构建 * optional,default 'null' * if we use tinkerPatch to build the patch apk, you'd better to apply the old * apk mapping file if minifyEnabled is enable! * Warning: * you must be careful that it will affect the normal assemble build! */ applyMapping = getApplyMappingPath() /** * 可选的,默认为null * 他从R.txt中很好的保存资源id,减少java的变化 * optional,default 'null' * It is nice to keep the resource id from R.txt file to reduce java changes */ applyResourceMapping = getApplyResourceMappingPath() /** * 必要的,默认为null * 因为我们不想在运行时用md5检查基础的apk文件(因为太慢了) * 当尝试应用补丁时,tinkerId来识别独特的基础apk * 我们用gif,svn或者简单的版本控制,我们将在你的清单中自动创建tinkerId * necessary,default 'null' * because we don't want to check the base apk with md5 in the runtime(it is slow) * tinkerId is use to identify the unique base apk when the patch is tried to apply. * we can use git rev, svn rev or simply versionCode. * we will gen the tinkerId in your manifest automatic */ tinkerId = "1.0" /** * 如果它为true,他将参考旧的apk * 打开他可以减少dex文件的大小 * if keepDexApply is true, class in which dex refer to the old apk. * open this can reduce the dex diff file size. */ keepDexApply = false } dex { /** * 可选的,默认为jar * 只能为raw或者jar, * optional,default 'jar',为raw时,我们保持原来的格式 * 为jar时,我们会重新打包dexes和zip * 如果你的support小于14,你必须使用jar * 或者你想检查更快的话,你必须使用raw * only can be 'raw' or 'jar'. for raw, we would keep its original format * for jar, we would repack dexes with zip format. * if you want to support below 14, you must use jar * or you want to save rom or check quicker, you can use raw mode also */ dexMode = "jar" /** * 必要的,默认为[] * dex的apk预计处理或修补补丁么? * necessary,default '[]' * what dexes in apk are expected to deal with tinkerPatch * it support * or ? pattern. */ pattern = ["classes*.dex", "assets/secondary-dex-?.jar"] /** * 必要的,默认为[] * 警告,这是非常非常重要的,加载classes时不能改变补丁,因此,他们讲从补丁dex中移除 * 你必须把这些类放入主的dex * 简单,你应该添加自己的application,自己的tinkerloader和自己使用的classes * necessary,default '[]' * Warning, it is very very important, loader classes can't change with patch. * thus, they will be removed from patch dexes. * you must put the following class into main dex. * Simply, you should add your own application {@code tinker.sample.android.SampleApplication} * own tinkerLoader, and the classes you use in them * */ loader = [ //use sample, let BaseBuildInfo unchangeable with tinker "tinker.sample.android.app.BaseBuildInfo" ] } lib { /** * 可选的,默认[] *apk预处理修复补丁 * 在assets的library中,我们就会在补丁目录中恢复他们 * 你可以在tinker中得到他的结果 * optional,default '[]' * what library in apk are expected to deal with tinkerPatch * it support * or ? pattern. * for library in assets, we would just recover them in the patch directory * you can get them in TinkerLoadResult with Tinker */ pattern = ["lib/*/*.so"] } res { /** * 可选的,默认[] * apk中资源文件预计处理修理补丁 * 在这个apk中,你必须包括你的所有资源,否则,他们不会重新打包到新的apk中 * optional,default '[]' * what resource in apk are expected to deal with tinkerPatch * it support * or ? pattern. * you must include all your resources in apk here, * otherwise, they won't repack in the new apk resources. */ pattern = ["res/*", "assets/*", "resources.arsc", "AndroidManifest.xml"] /** * 可选的,默认[] * 资源文件排除模式,忽视添加,删除或修改的文件 * 警告,我们可以使用没有与资源相对的文件 * optional,default '[]' * the resource file exclude patterns, ignore add, delete or modify resource change * it support * or ? pattern. * Warning, we can only use for files no relative with resources.arsc */ ignoreChange = ["assets/sample_meta.txt"] /** * 默认1000kb * 为了资源修改,如果它比‘largemodsize’大,我们会使用bsdiff算法去减少补丁文件的大小 * default 100kb * for modify resource, if it is larger than 'largeModSize' * we would like to use bsdiff algorithm to reduce patch file size */ largeModSize = 100 } packageConfig { /** * 可选的,默认.......... * 包文件的gen路径是在assets/package_meta.txt 的补丁文件 * 你可以似乎用安全检查。在你的包中检查方法或者在加载结果中获取包的属性 * 我们将会从旧的apk中得到tinkerID,其他配置文件(如补丁消息下面)是不必要的 * optional,default 'TINKER_ID, TINKER_ID_VALUE' 'NEW_TINKER_ID, NEW_TINKER_ID_VALUE' * package meta file gen. path is assets/package_meta.txt in patch file * you can use securityCheck.getPackageProperties() in your ownPackageCheck method * or TinkerLoadResult.getPackageConfigByName * we will get the TINKER_ID from the old apk manifest for you automatic, * other config files (such as patchMessage below)is not necessary */ configField("patchMessage", "tinker is sample to use") /** * 只是一个正常的情况下,你可以用sdk版本,渠道.... * 你可以在样本补丁监听器解析它,然后你就有条件可以使用补丁 * just a sample case, you can use such as sdkVersion, brand, channel... * you can parse it in the SamplePatchListener. * Then you can use patch conditional! */ configField("platform", "all") /** * 通过包配置补丁版本 * patch version via packageConfig */ configField("patchVersion", "1.0") } //or you can add config filed outside, or get meta value from old apk //project.tinkerPatch.packageConfig.configField("test1", project.tinkerPatch.packageConfig.getMetaDataFromOldApk("Test")) //project.tinkerPatch.packageConfig.configField("test2", "sample") /** * 如果你不使用zip,我们只是尝试使用7za * if you don't use zipArtifact or path, we just use 7za to try */ 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 */// path = "/usr/local/bin/7za" } } List<String> flavors = new ArrayList<>(); project.android.productFlavors.each { flavor -> flavors.add(flavor.name) } boolean hasFlavors = flavors.size() > 0 /** * bak apk and mapping */ android.applicationVariants.all { variant -> /** * task type, you want to bak */ def taskName = variant.name def date = new Date().format("MMdd-HH-mm-ss") tasks.all { if ("assemble${taskName.capitalize()}".equalsIgnoreCase(it.name)) { it.doLast { copy { def fileNamePrefix = "${project.name}-${variant.baseName}" def newFileNamePrefix = hasFlavors ? "${fileNamePrefix}" : "${fileNamePrefix}-${date}" def destPath = hasFlavors ? file("${bakPath}/${project.name}-${date}/${variant.flavorName}") : bakPath from variant.outputs.outputFile into destPath rename { String fileName -> fileName.replace("${fileNamePrefix}.apk", "${newFileNamePrefix}.apk") } from "${buildDir}/outputs/mapping/${variant.dirName}/mapping.txt" into destPath rename { String fileName -> fileName.replace("mapping.txt", "${newFileNamePrefix}-mapping.txt") } from "${buildDir}/intermediates/symbols/${variant.dirName}/R.txt" into destPath rename { String fileName -> fileName.replace("R.txt", "${newFileNamePrefix}-R.txt") } } } } } } project.afterEvaluate { //sample use for build all flavor for one time if (hasFlavors) { task(tinkerPatchAllFlavorRelease) { group = 'tinker' def originOldPath = getTinkerBuildFlavorDirectory() for (String flavor : flavors) { def tinkerTask = tasks.getByName("tinkerPatch${flavor.capitalize()}Release") dependsOn tinkerTask def preAssembleTask = tasks.getByName("process${flavor.capitalize()}ReleaseManifest") preAssembleTask.doFirst { String flavorName = preAssembleTask.name.substring(7, 8).toLowerCase() + preAssembleTask.name.substring(8, preAssembleTask.name.length() - 15) project.tinkerPatch.oldApk = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release.apk" project.tinkerPatch.buildConfig.applyMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release-mapping.txt" project.tinkerPatch.buildConfig.applyResourceMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release-R.txt" } } } task(tinkerPatchAllFlavorDebug) { group = 'tinker' def originOldPath = getTinkerBuildFlavorDirectory() for (String flavor : flavors) { def tinkerTask = tasks.getByName("tinkerPatch${flavor.capitalize()}Debug") dependsOn tinkerTask def preAssembleTask = tasks.getByName("process${flavor.capitalize()}DebugManifest") preAssembleTask.doFirst { String flavorName = preAssembleTask.name.substring(7, 8).toLowerCase() + preAssembleTask.name.substring(8, preAssembleTask.name.length() - 13) project.tinkerPatch.oldApk = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug.apk" project.tinkerPatch.buildConfig.applyMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug-mapping.txt" project.tinkerPatch.buildConfig.applyResourceMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug-R.txt" } } } } }}
差不多就这样,原谅我蹩脚的英文,为了让自己搞明白,翻译了一个下午= = 翻译好难。。。一般来说TinkerId是你软件当前的版本号。然后我们进行sync now。build success。binggo搞定了。
这是我们需要进行gradle打包。具体怎么打包,我们后面说,打包完成之后会在你的app/build/outputs/tinkerPatch生成一些文件。
.apk
结尾,防止被运营商挟持。log.txt在编译补丁包过程的控制台日志dex_log.txt在编译补丁包过程关于dex的日志so_log.txt在编译补丁包过程关于lib的日志tinker_result最终在补丁包的内容,包括diff的dex、lib以及assets下面的meta文件resources_out.zip最终在手机上合成的全量资源apk,你可以在这里查看是否有文件遗漏resources_out_7z.zip根据7zip最终在手机上合成的全量资源apktempPatchedDexes在Dalvik与Art平台,最终在手机上合成的完整Dex,我们可以在这里查看dex合成的产物。这些都是官方的介绍。我记得当时我不会gradle打包的时候,运行完成后发现并没有那些路径。最后你拿在app/build/bakApk的old.apk和在app/build/outputs/tinkerPatch的new.apk进行对比。运行如下:
java -jar tinker-patch-cli.jar -old old.apk -new new.apk -config tinker_config.xml -out output_path
关于tinker_config.xml配置看官方介绍:tinker_config.xml
在执行命令前别忘了我们需要在AndroidMainfest.xml进行配置thinkerId:
<meta-data android:name="TINKER_ID" android:value="版本号"/>
最后我们进行加载就行了。加载方式我们下面会说。
Gradle接入
对于gradle的接入,官方还是比较推荐的,不过因为有很多人因为懒所以进行命令行接入。其实如果命令行接入你还不如用hotfix。下面我们继续说下如何进行gradle接入。至于build.gradle的配置和命令行没有什么区别。所以我就不说第二遍 了。下面我们具体来看代码。
我们需要在Application进行初始化:
/** * com.angel.MyApplication才是真正的App,Tinker会自动生成一个 */@DefaultLifeCycle(application = "com.angel.MyApplication", flags = ShareConstants.TINKER_ENABLE_ALL, loadVerifyFlag = false)public class MyApplication extends DefaultApplicationLike { private static final String APATCH_PATH = "/test.apk"; public MyApplication(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) { super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent); } public void onBaseContextAttached(Context context) { super.onBaseContextAttached(context); //you must install multiDex whatever tinker is installed! MultiDex.install(context); TinkerInstaller.install(this); }}
MainActivity很简单,我们来用一个button进行模拟热修复:
public void click(View view) {// textView.setText("一个不小心就被我热修复了。"); String patchFileString = Environment.getExternalStorageDirectory() .getAbsolutePath() + APATCH_PATH; File file = new File(patchFileString); if (file.exists()) { TinkerInstaller.onReceiveUpgradePatch(getApplication(), patchFileString); Log.i("TAG", "补丁包存在>>>>" + patchFileString); } else { Log.i("TAG", "补丁包不存在"); } }
运行完如下:
我们点击按钮之后会发现,嗯哼,补丁包不存在。这就对了。
现在我们需要修改一些配置:
把gradle里的配置成bakApk下的时间。配置完再说。
好了。配置完成。下面是重点了,gradle的打包。跟着我的图,一步两步慢动作,两步一步慢动作重播。
当然至于debug和relase就随便你了哈。
这样我们进行打包完成了。然后我们会在这个路径:app\build\outputs\tinkerPatch\debug生成对应的文件。这个我前面讲过了。然后我们把包扔到你指定的目录中,例如我这边是根目录。就直接扔进去。然后我们来点击按钮。(无需重启点击)。会打印如下内容:
成功了。然后他会直接闪退,官方所说的重启我是没碰到过。进入后我们在次点击按钮。最后效果如下:
这样修复就算完成了。
爬坑Tinker
前面我留了一个坑,不知道已经会的是否发现,我刚才只说把包扔到目录里。但我们的包有3个,到底是哪个。你们一个个的试会发现只有7z包打印的时候会是isSuccess:ture
而其他两个全是false。至于为什么,我也并不了解。我记得官方好像没给答案。当然还有刚才说的他不会重启。这tm是个很尴尬的事啊~我也没搞懂为什么。
说说我之前遇到的几个坑把,怎么说呢,其实并不算坑,只是平时码代码的一些细节。一种情况是第一次没加读取权限,第二次你加了之后是没有用的,因为他要在第一个上进行读取进行修复的。导致返回码是-2。特地去官方看了这是因为补丁包不存在。我当时就蒙蔽了。好吧,自己细节没有注意= =
第二个自然就是gradle的接入了。我记得好像官方说是利用gradle进行打包。其实我并不懂= = 看来还是对gradle不熟悉哈。
总结
Tinker的爬坑之路算是结束了。其实发现只要配置完了,后面很简单,主要还是配置的坑比较多。对比其他的热修复,tinker肯定是首选,如果想简单不改代码的话用hotfix也可以。不过还是建议看下QZone和美团的原理。听说会让你容易理解模块化的~~tinker的使用基本就这样了。欢迎入坑,当然有问题可以一起来爬坑。
- Tinker爬坑之路
- Tinker
- Android热修复之Tinker
- Tinker 初步学习之旅
- Android 热更新之tinker
- 微信热更新Tinker 使用及爬坑(一)
- Tinker接入踩的坑
- 【腾讯Bugly干货分享】微信热补丁Tinker的实践演进之路
- 热修复框架Tinker的从0到集成之路
- 热修复框架Tinker的从0到集成之路
- 热修复框架Tinker的从0到集成之路
- 热修复框架Tinker最完整讲解(01)——集成之路
- Android热修复之Tinker使用初探
- 热修复之Tinker 开源库Demo测试
- Android热补丁之Tinker原理解析
- android笔记之 tinker初步集成
- Android热修复之Tinker接入流程
- PHP laravel系列之PHP Artisan Tinker
- Zttp
- 调试手机中数据库的福音:Android-Debug-Database
- maven tomcat run
- 原来Content-Length指的是POST的内容
- android webview获取源代码,且不能显示全的日志
- Tinker爬坑之路
- Spring Data JPA例子[基于Spring Boot、Mysql]
- React优化方式
- BLE-NRF51822教程4-串口BLE解析
- LTE-TDD资源调度(1)-QCI、GBR和Non-GBR
- HDU 1196 JAVA
- 面试复习——Android工程师之网络基础
- android 控件按下与松开事件
- Zttp