本文深入解析Android热修复库Tinker的Gradle插件，介绍了TinkerManifestTask、TinkerResourceIdTask等任务的具体行为，阐述了如何处理资源ID、混淆规则和多DEX等问题，以及在构建过程中如何注入和依赖任务。通过源码分析，揭示了TinkerGradlePlugin如何确保热修复patch文件的正确生成和资源一致性。
分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow
也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！
本文已在我的公众号hongyangAndroid原创首发。
转载请标明出处：
http://blog.csdn.net/lmj623565791/article/details/72667669
本文出自张鸿洋的博客
一、概述
前面写了两篇分析了tinker的loader部分源码以及dex diff/patch算法相关解析，那么为了保证完整性，最后一篇主要写tinker-patch-gradle-plugin相关了。
（距离看的时候已经快两个月了，再不写就忘了，赶紧记录下来）
注意：
本文基于1.7.7
前两篇文章分别为：
有兴趣的可以查看~
在介绍细节之前，我们可以先考虑下：通过一个命令生成一个patch文件，这个文件可以用于下发做热修复（可修复常规代码、资源等），那么第一反应是什么呢？
正常思维，需要设置oldApk，然后我这边build生成newApk，两者需要做diff，找出不同的代码、资源，通过特定的算法将diff出来的数据打成patch文件。
ok，的确是这样的，但是上述这个过程有什么需要注意的么？
- 我们在新增资源的时候，可能会因为我们新增的一个资源，导致非常多的资源id发生变化，如果这样直接进行diff，可能会导致资源错乱等（id指向了错误的图片）问题。所以应当保证，当资源改变或者新增、删除资源时，早已存在的资源的id不会发生变化。
- 我们在上线app的时候，会做代码混淆，如果没有做特殊的设置，每次混淆后的代码难以保证规则一致；所以，build过程中理论上需要设置混淆的mapping文件。
- 当项目比较大的时候，我们可能会遇到方法数超过65535的问题，我们很多时候会通过分包解决，这样就有主dex和其他dex的概念。集成了tinker之后，在应用的Application启动时会非常早的就去做tinker的load操作，所以就决定了load相关的类必须在主dex中。
- 在接入一些库的时候，往往还需要配置混淆，比如第三方库中哪些东西不能被混淆等（当然强制某些类在主dex中，也可能需要配置相对应的混淆规则）。
如果大家尝试过接入tinker并使用gradle的方式生成patch相关，会发现在需要在项目的build.gradle中，添加一些配置，这些配置中，会要求我们配置oldApk路径，资源的R.txt路径，混淆mapping文件路径、还有一些比较tinker相关的比较细致的配置信息等。
不过并没有要求我们显示去处理上述几个问题（并没有让你去keep混淆规则，主dex分包规则，以及apply mapping文件），所以上述的几个实际上都是tinker的gradle plugin 帮我们做了。
所以，本文将会以这些问题为线索来带大家走一圈plugin的代码（当然实际上tinker gradle plugin所做的事情远不止上述）。
其次，tinker gradle plugin也是非常好的gradle的学习资料~
二、寻找查看代码入口
下载tinker的代码，导入后，plugin的代码都在tinker-patch-gradle-plugin中，不过当然不能抱着代码一行一行去啃了，应该有个明确的入口，有条理的去阅读这些代码。
那么这个入口是什么呢？
其实很简单，我们在打patch的时候，需要执行tinkerPatchDebug（注：本篇博客基于debug模式讲解）。
当执行完后，将会看到执行过程包含以下流程：
:app:processDebugManifest:app:tinkerProcessDebugManifest（tinker）:app:tinkerProcessDebugResourceId (tinker):app:processDebugResources:app:tinkerProguardConfigTask(tinker):app:transformClassesAndResourcesWithProguard:app:tinkerProcessDebugMultidexKeep (tinker):app:transformClassesWidthMultidexlistForDebug:app:assembleDebug:app:tinkerPatchDebug(tinker)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
注：包含(tinker)的都是tinker plugin 所添加的task
可以看到部分task加入到了build的流程中，那么这些task是如何加入到build过程中的呢？
在我们接入tinker之后，build.gradle中有如下代码：
if (buildWithTinker()) { apply plugin: 'com.tencent.tinker.patch' tinkerPatch {} // 各种参数}
- 1
- 2
- 3
- 4
如果开启了tinker，会apply一个plugincom.tencent.tinker.patch：
名称实际上就是properties文件的名字，该文件会对应具体的插件类。
对于gradle plugin不了解的，可以参考http://www.cnblogs.com/davenkin/p/gradle-learning-10.html，后面写会抽空单独写一篇详细讲gradle的文章。
下面看TinkerPatchPlugin，在apply方法中，里面大致有类似的代码：
// ... 省略了一堆代码TinkerPatchSchemaTask tinkerPatchBuildTask = project.tasks.create("tinkerPatch${variantName}", TinkerPatchSchemaTask)tinkerPatchBuildTask.dependsOn variant.assembleTinkerManifestTask manifestTask = project.tasks.create("tinkerProcess${variantName}Manifest", TinkerManifestTask)manifestTask.mustRunAfter variantOutput.processManifestvariantOutput.processResources.dependsOn manifestTaskTinkerResourceIdTask applyResourceTask = project.tasks.create("tinkerProcess${variantName}ResourceId", TinkerResourceIdTask)applyResourceTask.mustRunAfter manifestTaskvariantOutput.processResources.dependsOn applyResourceTaskif (proguardEnable) { TinkerProguardConfigTask proguardConfigTask = project.tasks.create("tinkerProcess${variantName}Proguard", TinkerProguardConfigTask) proguardConfigTask.mustRunAfter manifestTask def proguardTask = getProguardTask(project, variantName) if (proguardTask != null) { proguardTask.dependsOn proguardConfigTask }}if (multiDexEnabled) { TinkerMultidexConfigTask multidexConfigTask = project.tasks.create("tinkerProcess${variantName}MultidexKeep", TinkerMultidexConfigTask) multidexConfigTask.mustRunAfter manifestTask def multidexTask = getMultiDexTask(project, variantName) if (multidexTask != null) { multidexTask.dependsOn multidexConfigTask }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
可以看到它通过gradle Project API创建了5个task，通过dependsOn,mustRunAfter插入到了原本的流程中。
例如：
TinkerManifestTask manifestTask = ...manifestTask.mustRunAfter variantOutput.processManifestvariantOutput.processResources.dependsOn manifestTask
- 1
- 2
- 3
TinkerManifestTask必须在processManifest之后执行，processResources在manifestTask后执行。
所以流程变为：
processManifest-> manifestTask-> processResources
- 1
其他同理。
ok，大致了解了这些task是如何注入的之后，接下来就看看每个task的具体作用吧。
注：如果我们有需求在build过程中搞事，可以参考上述task编写以及依赖方式的设置。
三、每个Task的具体行为
我们按照上述的流程来看，依次为：
TinkerManifestTaskTinkerResourceIdTaskTinkerProguardConfigTaskTinkerMultidexConfigTaskTinkerPatchSchemaTask
- 1
- 2
- 3
- 4
- 5
丢个图，对应下：
四、TinkerManifestTask
#TinkerManifestTask@TaskActiondef updateManifest() { // Parse the AndroidManifest.xml String tinkerValue = project.extensions.tinkerPatch.buildConfig.tinkerId tinkerValue = TINKER_ID_PREFIX + tinkerValue;//"tinker_id_" // /build/intermediates/manifests/full/debug/AndroidManifest.xml writeManifestMeta(manifestPath, TINKER_ID, tinkerValue) addApplicationToLoaderPattern() File manifestFile = new File(manifestPath) if (manifestFile.exists()) { FileOperation.copyFileUsingStream(manifestFile, project.file(MANIFEST_XML)) }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
这里主要做了两件事：
writeManifestMeta主要就是解析AndroidManifest.xml，在
<application>内部添加一个meta标签,value为tinkerValue。例如：
<meta-data android:name="TINKER_ID" android:value="tinker_id_com.zhy.abc" />- 1
- 2
- 3
这里不详细展开了，话说groovy解析XML真方便。
- addApplicationToLoaderPattern主要是记录自己的application类名和tinker相关的一些load class
com.tencent.tinker.loader.*，记录在project.extensions.tinkerPatch.dex.loader中。
最后copy修改后的AndroidManifest.xml至build/intermediates/tinker_intermediates/AndroidManifest.xml。
这里我们需要想一下，在文初的分析中，并没有想到需要tinkerId这个东西，那么它到底是干嘛的呢？
看一下微信提供的参数说明，就明白了：
在运行过程中，我们需要验证基准apk包的tinkerId是否等于补丁包的tinkerId。这个是决定补丁包能运行在哪些基准包上面，一般来说我们可以使用git版本号、versionName等等。
想一下，在非强制升级的情况下，线上一般分布着各个版本的app。但是。你打patch肯定是对应某个版本，所以你要保证这个patch下发下去只影响对应的版本，不会对其他版本造成影响，所以你需要tinkerId与具体的版本相对应。
ok，下一个TinkerResourceIdTask。
五、TinkerResourceIdTask
文初提到，打patch的过程实际上要控制已有的资源id不能发生变化，这个task所做的事就是为此。
如果保证已有资源的id保持不变呢？
实际上需要public.xml和ids.xml的参与，即预先在public.xml中的如下定义，在第二次打包之后可保持该资源对应的id值不变。
注：对xml文件的名称应该没有强要求。
<public type="id" name="search_button" id="0x7f0c0046" />
- 1
很多时候我们在搜索固化资源，一般都能看到通过public.xml去固化资源id，但是这里有个ids.xml是干嘛的呢？
下面这篇文章有个很好的解释~
http://blog.csdn.net/sbsujjbcy/article/details/52541803
首先需要生成public.xml，public.xml的生成通过aapt编译时添加-P参数生成。相关代码通过gradle插件去hook Task无缝加入该参数，有一点需要注意，通过appt生成的public.xml并不是可以直接用的，该文件中存在id类型的资源，生成patch时应用进去编译的时候会报resource is not defined，解决方法是将id类型型的资源单独记录到ids.xml文件中，相当于一个声明过程，编译的时候和public.xml一样，将ids.xml也参与编译即可。
ok，知道了public.xml和ids.xml的作用之后，需要再思考一下如何保证id不变？
首先我们在配置old apk的时候，会配置tinkerApplyResourcePath参数，该参数对应一个R.txt，里面的内容涵盖了所有old apk中资源对应的int值。
那么我们可以这么做，根据这个R.txt，把里面的数据写成public.xml不就能保证原本的资源对应的int值不变了么。
的确是这样的，不过tinker做了更多，不仅将old apk的中的资源信息写到public.xml，而且还干涉了新的资源，对新的资源按照资源id的生成规则，也分配的对应的int值，写到了public.xml，可以说该task包办了资源id的生成。
分析前的总结
好了，由于代码非常长，我决定在这个地方先用总结性的语言总结下，如果没有耐心看代码的可以直接跳过源码分析阶段：
首先将设置的old R.txt读取到内存中，转为：
- 一个Map，key-value都代表一个具体资源信息；直接复用，不会生成新的资源信息。
- 一个Map，key为资源类型，value为该类资源当前的最大int值；参与新的资源id的生成。
接下来遍历当前app中的资源，资源分为：
- values文件夹下文件
对所有values相关文件夹下的文件已经处理完毕，大致的处理为：遍历文件中的节点，大致有item，dimen，color，drawable，bool，integer，array，style，declare-styleable，attr，fraction这些节点，将所有的节点按类型分类存储到rTypeResourceMap（key为资源类型，value为对应类型资源集合Set）中。
其中declare-styleable这个标签，主要读取其内部的attr标签，对attr标签对应的资源按上述处理。
- res下非values文件夹
打开自己的项目有看一眼，除了values相关还有layout,anim,color等文件夹，主要分为两类：
一类是对 文件 即为资源，例如R.layout.xxx，R.drawable.xxx等；另一类为xml文档中以@+（去除@+android:id），其实就是找到我们自定义id节点，然后截取该节点的id值部分作为属性的名称（例如：@+id/tv，tv即为属性的名称）。
如果和设置的old apk中文件中相同name和type的节点不需要特殊处理，直接复用即可；如果不存在则需要生成新的typeId、resourceId等信息。
会将所有生成的资源都存到rTypeResourceMap中，最后写文件。
这样就基本收集到了所有的需要生成资源信息的所有的资源，最后写到public.xml即可。
总结性的语言难免有一些疏漏，实际以源码分析为标准。
开始源码分析
@TaskActiondef applyResourceId() { // 资源mapping文件 String resourceMappingFile = project.extensions.tinkerPatch.buildConfig.applyResourceMapping // resDir /build/intermediates/res/merged/debug String idsXml = resDir + 
最低0.47元/天 解锁文章
768
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
