android 插件实现原理,Gradle插件的实现方法和原理

混淆的另一重境界，今天给大家讲解了一个Gradle插件的实现方法和原理，对于想深入了解Android打包编译，gradle插件实现的开发者来说，绝对是一篇不错的案例。

前言

今天给大家讲解了一个Gradle插件的实现方法和原理，对于想深入了解Android打包编译，gradle插件实现的开发者来说，绝对是一篇不错的案例。

Mess介绍

众所周知，我们开混淆打包后生成的apk里，Activity、自定义View、Service等出现在xml里的相关Java类默认都会被keep住，那么这对于app的保护是不足够好的，Mess就是来解决这个问题，把即使出现在xml文件中的Java类照样混淆。

使用

此外，Mess还提供一个可选配置， ignoreProguard ，由于有些依赖库本身也配置了相关混淆配置，如 com.android.support:recyclerview-v7 、 com.jakewharton:butterknife 等，那么这些文件都将会被添加到 proguardFiles 中，导致依赖库无法被混淆，所以 ignoreProguard 配置就是来解决这个问题的。

比如忽视 com.android.support:recyclerview-v7 的混淆配置文件，则直接

实现原理

先来看看Android gradle plugin在构建时最后所走的几个task：

其中有几个关键性的task，可以看到 :app:transformClassesAndResourcesWithProguardForRelease 是走在 :app:packageRelease 之前的，那么我们就在打包前对混淆的task做些操作来实现我们的目的。

hook transformClassesAndResourcesWithProguardFor${variant.name.capitalize()}

hook ProcessAndroidResources Task，将生成的 aapt_rules.txt 中内容清空

如果需要混淆依赖库，则删除依赖库中的 proguard.txt 文件

遍历一遍mapping.txt获取所有Java类名的的映射关系得到一个Map

拿映射Map替换AndroidManifest.xml里的Java原类名

拿映射Map替换layout、menu和value文件夹下的xml的Java原类名

重新跑 ProcessAndroidResources Task

恢复之前删除依赖库中的 proguard.txt 文件

以上就是Mess干的关键性的东西，接下来依次说明。

hooktransformClassesAndResourcesWithProguardFor${variant.name}

这个task是处理类和资源混淆的，也是我们的突破口，Mess中大部分自定义task都是围绕在这个task执行的，之后会有详解。

hookProcessAndroidResourcesTask，将生成的aapt_rules.txt中内容清空

这一步是虽说只是把 aapt_rules.txt 文件中的内容清空，但是确实Mess Plugin能成功的最关键的一步。

ProcessAndroidResourcestask会生成一个 aapt_rules.txt ，可见源码 ProcessAndroidResources.groovy ，aapt_rules.txt里会keep住我们在xml里所书写的那些Activity、自定义View等Java类名部分，还可以看到 JackTask.java 里的相关代码：

其中getProcessAndroidResourcesProguardOutputFile方法所对应的文件就是我们所需要清空的aapt_rules.txt，可以在 VariantScope.java 中查看。

很明显，aapt_rules.txt所keep住的所有内容都将会添加到最后的混淆配置中，因此，我们需要在 ProcessAndroidResources 这个Task执行之后清空aapt_rules.txt中的内容，以保证编译出的main.jar中的所有.class都是混淆后的。

相关代码如下：

如果需要混淆依赖库，则删除依赖库中的proguard.txt文件

这一步就是删除依赖库中所保护的内容，具体 proguard.txt 文件位于 app目录下/build/intermediates/exploded-aar/依赖库maven名/proguard.txt 。

Mess中直接将 proguard.txt 文件名最后加上 ~ ，如 proguard.txt~ ，在linux中表示备份，以便之后文件的恢复。

相关代码如下：

遍历一遍mapping.txt获取所有Java类名的的映射关系得到一个Map

之前第一步已经将生成的main.jar中所有的.class文件做相关混淆了，那么我们之前所在xml里写的还是原来的Java类名，因此，我们想要替换xml里的Java类名，就得先知道原先的类名被替换成什么了，这个时候就得依赖mapping.txt了。

直接遍历：

这样后map里就存有所有类名的映射关系了，但是有个小问题要注意，假如存在这种情况，me.ele.foo -> me.ele.a，me.ele.fooNew -> me.ele.b，也就是恰巧有类名是另一个类名的开始部分，那么这样对我们之后的替换是会有bug的，会导致fooNew被替换成了aNew。因此，拿到map后需要对map做一次原类名长度的降序排序(也就是map中的key)，以避免这个bug发生。相关代码如下：

至此，一个正确的map已经拿到，接下来就是靠这个map来对相关的xml文件做替换了。

拿映射Map替换AndroidManifest.xml里的Java原类名

细心活，拿到AndroidManifest.xml一行一行读取，匹配到相关字符串则进行替换，但这里有个小坑，由于Java内部类的类名是用 $ 符号分割的，刚好它又是正则表达式表示匹配字符串的结尾，因此对于内部类，我们应该现将 $ 符号先替换成其他字符串，然后再做类名的替换，Mess中是替换成 inner ，相关代码如下：

拿映射Map替换layout、menu和value文件夹下的xml的Java原类名

前一步已经把AndroidManifest.xml中的对应Java类名替换了，这一步就是替换layout、menu和value这三个文件夹下的xml内容，感谢groovy语法让整件事情变得非常简单。layout、menu文件夹大家能立马理解，那么value呢？其实就是behavior引入后才存在的，所以value文件夹千万别忽视。

相关代码如下：

至此，整个工程的main.jar中的.class文件以及资源文件都替换成相互匹配的混淆后的名称了。

重新跑ProcessAndroidResourcesTask

前些步骤hook后 ProcessAndroidResources Task之后我们已经把静态的文件都替换好了，那么接下来就还得依靠Android gradle plugin的原有tasks了，于是乎我们重新执行 ProcessAndroidResources Task。

恢复之前删除依赖库中的proguard.txt文件

有头有尾。

尾语

想要写出Mess这样的plugin，对Android整个打包流程是要相当熟悉的，这样才能知道什么时候该hook什么task，平常开发过程中尽量不要直接点击run按钮，应该直接通过gradle assemble** 构建，这样无数次的看构建过程中经历哪些task，然后去阅读相关task源码，这样对整个打包流程才会越来越胸有成竹。

Mess有个小遗憾，那就是ButterKnife这个库在绝大多数app中都使用了，但是ButterKnife的混淆规则中有对使用注解的方法名和变量名做保护，这样就比较尴尬了，会导致Mess对使用ButterKnife库的app而言是没多大作用的。

但是不要灰心，ButterMess这个Lib就来解决这个问题，接下来会写篇详解ButterMess的文章，先放个ButterMess的链接： https://github.com/peacepassion/ButterMess

以上就是对于安卓开发方面的知识点简介，Gradle插件的实现方法和原理，更多相关内容请继续关注拓胜科技安卓技术频道，或者需要了解拓胜安卓培训方面的问题，可以在线免费咨询拓胜教育老师。