从Ant到Gradle的迁移之路

Posted 2021-04-27 腾讯移动品质中心TMQ

 

笔者语

Gradle是一个类似于Ant和Maven的自动化构建工具，是android App天然的构建工具。

本文总结了项目从Ant迁移到Gradle的实践经验和相关技巧，供大家参考。

由于Gradle的种种优点（大家可以参考网上的资料，这里不多说了），前一段时间项目组打算将原来的Ant编译打包方式迁移到Gradle编译打包方式。

现在迁移基本完成，我这里将迁移过程遇到的坑以及经验做一个总结，希望能给大家在Ant转Gradle的时候带来一些提示。

一、Ant打包流程

这里，我们先来看一下Ant脚本的一个片段：

<antcalltarget="compile"/>

<antcalltarget="genMainDexFilelist" />

<antcalltarget="genSecondDexFilelist" />

<antcalltarget="package_res_with_assets"/>

<antcall target="package"/>

这段脚本执行的流程是：

上述编译打包关键任务的说明：

（1）compile：编译工程代码；

（2）genMainDexFilelist：生成主dex的类列表；

（3）genSecondDexFilelist：生成从dex的类列表；

（4）package_res_with_assets：打包资源文件

（5）package：将代码和资源一起打包成apk。

从Ant脚本和流程可以看出，Ant的任务都是直接在脚本中实现，然后按照脚本定义的执行顺序来依次执行任务。

二、Gradle打包流程

这里先给出一个Gradle脚本的最简单的模版，如下：

这个最简单模版即可完成apk的编译、打包、签名等过程。它是怎么做到的呢？

原来，在Gradle中，官方已经为我们定义好了一个专门编译打包App的Gradle插件，该插件包含了Apk编译打包的基本任务，我们就不用自己再费力去重写了，可以直接复用。这个添加的插件就是上面Gradle脚本的第一行：

apply plugin: 'com.android.application'

在该插件中，默认的编译打包流程如下：

上述编译打包关键任务的说明：

（1）compileReleaseJavaWithJavac、compileReleaseSources：主要完成了Java代码的编译，生成class文件。

（2）transformClassesAndResourcesWithProguardForRelease：主要完成了Java代码的混淆，生成混淆后的jar包和mapping文件。

（3）transformClassesWithDexForRelease：主要完成了将class文件和第三方库一起打包生成Dex字节码文件。

（4）packageRelease：主要完成了将Dex字节码文件和其他资源文件一起打包。

在这个插件中，代码编译、打包等基本任务已经有了，但是我们还有一部分自定义的任务怎么办呢？只能从Ant移植过去！

因为打包方式从Ant移植到Gradle后，最重要的是保证打包的功能和最终效果保持不变，做到平滑的移植。所以，这里我们就应该平滑的将Ant任务改造成Gradle任务，然后移植到Gradle脚本中。

这里Gradle跟Ant有一个很明显的区别就是，Ant的任务基本上都是自定义的，代码直接可见，所以我们想要添加、插入、删除任务都比较方便。但是Gradle的基本任务都在插件中，代码不可见，那么我们自定义任务以后该怎么跟插件的任务融合在一起呢？

接下来我们具体说明。

三、Ant任务改造成Gradle任务

下面就以dex分包过程中生成从dex的类列表为例，来说明如何将Ant中自定义的任务移植到Gradle。

Ant任务代码示例：

   <target name="genSecondDexFilelist">

       <echo>开始生成secondary dex filelist...</echo>

       <exec executable="bash">

           <arg value="${temp}/genSecondDexFilelist.sh"/>

           <arg value="${main_dex_filelist}"/>

           <arg value="${temp}"/>

           <arg value="${bin}"/>

       </exec>

</target>

这是一个shell脚本任务，目的是分包时生成从dex的类列表。

将Ant任务改造成Gradle任务时，为了平滑改造以及减少改造的工作量，我们仍然采用这个shell脚本。由于Gradle的方式也可以直接调用shell脚本，所以我们的Gradle任务定义如下：

def genSecondDexFilelist =project.task("genSecondDexFilelist", type: Exec) {

        executable 'bash'

        args"./genSecondDexFilelist.sh", main_dex_filelist, tempDir, binDir

    }

或者也可以这样定义：

def dxMainDex = project.task("genSecondDexFilelist", type:Exec) {

           commandLine "sh","-c", "./genSecondDexFilelist.sh " + main_dex_filelist +" " + tempDir + " " + binDir

        }

以上两种方式均可达到同样的效果。

上述代码中的main_dex_filelist、tempDir、binDir是该task中用到的自定义局部变量，它们可以跟单独的task就近定义，也可以多个任务一起集中定义。

任务定义好了，放在Gradle脚本的什么位置呢？直接放在脚本文件后面就好，跟android定义块分开。具体例子如下：

四、自定义Gradle任务的注入

Gradle的任务定义好以后，我们还需要将它加入到Gradle的编译打包流程中才可以被执行。

正如前面所说，由于Gradle的App编译打包插件已经有一个基本的、完整的流程，我们自定义的任务必须插入到这个流程中合适的位置，这一步也称作任务的注入。

任务注入的方法是利用Gradle任务之间的依赖关系。

比如，我们这个任务genSecondDexFilelist需要放在代码编译之后、apk打包之前，怎么做呢？可以放在afterEvaluate块中注入。具体代码如下：

afterEvaluate {

                tasks.getByName("transformClassesAndResourcesWithProguardForRelease"){

               tasks.findByName("genSecondDexFilelist").dependsOnit.taskDependencies.getDependencies(it)

               it.dependsOntasks.findByName("genSecondDexFilelist")

            }

}

下面对这段代码进行解释：

（1）afterEvaluate说明是在Gradle脚本解析完之后、task开始执行之前插入任务；

（2）第一个dependsOn是使“genSecondDexFilelist”任务依赖于“transformClassesAndResourcesWithProguardForRelease”所有的依赖；第二个dependsOn是使“transformClassesAndResourcesWithProguardForRelease”依赖于“genSecondDexFilelist”。这样一来，就将“genSecondDexFilelist”置于“transformClassesAndResourcesWithProguardForRelease”之前了。

在完成genSecondDexFilelist任务的注入以后，我们的Gradle脚本变成如下的样子：

这样，一个Ant任务就改造成Gradle任务并注入完成了。

其他的Ant任务可以同样移植过来。

五、任务移植实例

1、dex分包

Gradle自带dex分包插件，但是缺点是定制比较麻烦。我们在Ant下已经有现成的自己定制的dex分包脚本和相关配置，如果能直接在Gradle中使用，那就好了。怎么做呢？

根据上面自定义任务和插入任务的做法，我们只需将Ant下已有的分包任务改写成Gradle任务，已有的shell脚本照搬过来，然后再把任务注入到Gradle插件的编译打包流程中即可。

前面已经演示了如何把生成从dex类列表的任务改造、注入Gradle任务流程中，其他任务可用类似的方法来实现移植。

2、代码混淆

代码混淆在我们的移植过程中也是一个坑。

Gradle也自带代码混淆插件，但是它默认的混淆跟我们Ant下混淆出来的结果很不相同。要想让Gradle下的混淆跟我们Ant下的混淆完全一样，则需要重写混淆配置文件和调试，这个过程比较麻烦。如果能把我们在Ant下已有的混淆配置拿过来直接用，那肯定是最好的。怎么做呢？方法就是弃用Gradle自带的混淆任务，使用我们自定义的混淆任务。

弃用Gradle混淆任务的方法是在Gradle脚本的buildTypes中设置minifyEnabled为false，然后自定义混淆任务并注入到编译打包流程的适当位置。

自定义混淆任务时，混淆的配置可以放在一个配置文件中，然后在任务中引用；也可以直接放在任务体的代码中。这两种形式体现在代码上有所不同，具体举例如下：

第一种形式：混淆配置放在配置文件中

proguard.cfg：

-injars ./build/libs/temp.jar

 

-injars ./libs/android-support-v4-lite.jar

-injars./libs/android-support-v7-recyclerview-lite.jar

……

-keep public class * extendsandroid.app.Activity

-keep public class * extendsandroid.app.Application

-keep class * extendsandroid.widget.BaseAdapter

-keep public class * extendsandroid.view.View

-keep public class * extendsandroid.app.Service

-keep public class * extendsandroid.content.BroadcastReceiver

……

在代码中引用proguard.cfg：

task proguardTask(type:proguard.gradle.ProGuardTask) {

   configuration 'proguard.cfg'

}

第二种形式：混淆配置直接放在任务体中

def proguardJar =project.task("proguardJar", type: proguard.gradle.ProGuardTask) {

       injars tempJar

 

       injars "./libs/android-support-v4-lite.jar"

       injars "./libs/android-support-v7-recyclerview-lite.jar"

       libraryjars "./libs/tmslite_2.1.jar"

       libraryjars "./libs/sm.jar"

       ……

       keep 'public class com.test.* { \

           public *; \

           }'

       ……

}

这两种形式本质上是一样的，但是它们还是有些使用上的不同：

第一种形式的优点是Proguard的配置都放在一个独立的配置文件中，可以减少Gradle脚本的代码量，代码看起来更清爽。不过，它有一个缺点就是不好传入和使用Gradle脚本中定义的通用变量，这在某些情况下可能不太方便（比如，Proguard使用的jar包路径可能包含编译时的环境变量，我们就无法在配置文件中使用该环境变量）。

第二种形式的优缺点正好跟第一种形式相反。

我们在使用的时候可以根据情况来选择使用哪种形式。

六、总结

 

以上讲述了我们从Ant到Gradle的移植方法和案例。无论是Ant脚本还是Gradle脚本，其中关键的地方还是在于如何定义任务、如何让任务做正确的事，这才是真正考验我们代码能力的地方。

欢迎大家一起讨论交流！

---

长按指纹识别图中的二维码，获取更多测试干货分享！