从Ant到Gradle的迁移之路

2017-07-12 11:13:31来源:http://tmq.qq.com/2017/07/从ant到gradle的迁移之路/作者:TMQ人点击

笔者语


本文总结了项目从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脚本,其中关键的地方还是在于如何定义任务、如何让任务做正确的事,这才是真正考验我们代码能力的地方。


欢迎大家一起讨论交流!


版权所属,禁止转载


微信扫一扫

第七城市微信公众平台