分享一下我老师大神的人工智能教程!零基础,通俗易懂!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 +