写给 Android 开发者的 Gradle 系列(二)编写 task

640


接着上一篇《写给 Android 开发者的 Gradle 系列(一)基本姿势》,这篇文章 Joker 将带我们一起学习如何写 task。

作者:Joker点击阅读原文前往原文地址本文基于 Android Gradle plugin 3.0.1

  • 前言

  • task 撰写

    • 扩展

    • task 声明

    • task 内容格式

    • task 依赖关系

  • task 实战

    • install && launch apk

    • hook assets

  • 后记

前言

在 app/build.gradle 中添加如下依赖:

compileOnly 'com.android.tools.build:gradle:3.0.1'

即可在 External Libraries 中看到关于 Gradle plugin 的源码。

640

Gradle 源码如何引入将会在下一节中介绍

task 撰写

task 声明

根据官方文档和 Task#create() 可以知道,task 的基本写法可以是如下四种:

task myTask
task myTask { configure closure }
task (myTask) { configure closure }
task (name: myTask) { configure closure }

每一个 task 都有自己的名字,这样开发者才能调用它,例如调用上面的 task:

./gradlew myTask

但是有一个问题,倘若当前项目的 app module 和 a module 都含有一个名为 myTask 的 task,那么会不会起冲突,该如何调用它们?答案是不会冲突,调用方式如下:

./gradlew app:myTask(调用 app module 的 myTask)

./gradlew a:myTask(调用 a module 的 myTask)

通过 ProjectName:taskName 的形式便可以指定唯一绝对路径去调用指定 Project 的指定 task 了。

扩展

根据 Task#create() 可以知道,task 的创建是可以声明参数的,除了上述的 name 参数之外,还有如下几种:

  • type:默认为 DefaultTask。类似于父类。在后文中将会提及该参数。

  • dependsOn:默认为[]。希望依赖的 tasks,等同于 Task.dependsOn(Object... path) 中的 path。在后文中将会提及该参数。

  • action:默认为 null。等同于 Task.doFirst { Action } 中的 Action。

    task (name: actionTest, action: new Action<Task>() {
      @Override
      void execute(Task task) {
        println 'hello'
      }
    }) {
    }

    等同于

    task (name: actionTest) {
        doFirst {
            println 'hello'
        }
    }
  • override:默认为 false。是否替换已存在的 task。

  • group:默认为 null。task 的分组类型。

  • description:默认为 null。task 描述。

  • constructorArgs:默认为 null。传给 task 构造函数的参数。

后面四种大部分开发过程中应该不怎么会用到,有需要的读者自行查阅文档。

task 内容格式

  1. 根据官方文档以及前一篇文章中可以知道,如果想给 task 添加操作,可以添加在 doLast {}/doFirst {} 等闭包中,例如:

    task myTask {
        doFirst {
            println 'myTask 最先执行的内容'
        }
        doLast {
            println 'myTask 最后执行的内容'
        }
        // warning
        // println 'Configuration 阶段和 Execution 阶段皆会执行'
    }

    切记大部分的内容是写在 doLast{} 或 doFirst{} 闭包中,因为写在如果写在 task 闭包中的话,会在 Configuration 阶段也被执行。

  2. 根据官方文档可知,为了提高 task 复用性,Gradle 还支持 Task 类的书写——

    2.1 将下述代码写在 build.gradle 中,并用 @TaskAction 标记想要执行的方法。

    class GreetingTask extends DefaultTask {String greeting = 'hello from GreetingTask'

    @TaskAction
    def greet() {
        println greeting
    }

    }

    2.2 在 build.gradle 中撰写 task 调用 GreetingTask 类:

    task (name: hello , type: GreetingTask)

    task (name: greeting , type: GreetingTask) {greeting = 'greetings from GreetingTask'}

    2.3 调用该 task——

    ./gradlew hello
    
    > Task :app:hello
    hello from GreetingTask
    
    ./gradlew greeting
    
    > Task :app:greeting
    greetings from GreetingTask

所以看到这里应该不仅能够理解 Task 类的书写,并且应该能够大致明白 type 这个参数的含义了。

不知道会不会和笔者一样事儿逼的读者此时会疑惑 @TaskAction 修饰的方法和 doLast {} 以及 doFirst {} 闭包的执行顺序是怎样的?

task (name: hello, type: GreetingTask) {
  doFirst {
    def list = getActions()
    for (int i = 0; i < list.size(); i++) {
      println list.get(i).displayName
    }
  }

  doLast {

  }
}

首先声明 doFirst {} 和 doLast {} 闭包;然后戳进 DefaultTask 源码并追踪到顶级父类 AbstractTask 中可以看到内部通过使用 actions 存储所有执行的 Action,并通过 getAction() 暴露;actions 是 List 类型,内部的元素类型是 ContextAwareTaskAction,该接口又实现了 Describable,Describable 仅声明了一个 getDisplayName()方法,所以可以直接通过 displayName 获取该 Action 的名称。

理解以上三步即可完成上述 task 撰写,在命令行中试试——

./gradlew hello

> Task :app:hello
Execute doFirst {} action
Execute greet
Execute doLast {} action

Gradle 内部将会自动为变量设置 setter、getter 方法,所以当一个 Gradle 有 getXxx() 方法时,可以直接使用 xxx 变量。如果不清楚这个细节,建议回顾上一篇文章的附录。

task 依赖关系

开发者常使用 dependsOn 来指定依赖关系(另外两种是指定 task 执行顺序,详见文档 Task Dependencies and Task Ordering),如下:

task a {
    doLast {
        println 'a'
    }
}

task b {
    dependsOn('a')
    doFirst {
        println 'b'
    }
}

不妨将以上代码写在 app build.gradle 文件下,当执行 task b 的时候,会输出如下信息:

./gradlew task app:b

> Task :app:a

a

> Task :app:b

b

可以看到,由于 task b 需要依赖 task a,所以 task b 执行的时候会先执行 task a。

有经验的开发者如果在命令行中试过 assembleDebug 等命令会发现,它们的执行将会依赖于许多其他 task。所以不妨在命令行中试试 ./gradlew assembleDebug 观察输出结果。

task 实战

install && launch apk

com.android.application 自带 installDebug task,开发者可以使用 installDebug 安装当前项目 apk:

./gradlew installDebug

> Task :app:installDebug

Installing APK 'app-debug.apk' on 'xxxxx' for app:debugInstalled on 1 device.

但是似乎看起来有些不尽人意的地方,例如开发者希望安装的时候能够顺带能够启动该 app。那么该如何做呢?

首先从问题的可行性上来进行分析,开发者的直觉告诉我们是可以通过 gradle 实现的——命令行可以安装、启动 apk——adb install -r app-debug.apk 和 adb shell am start -n 包名/首 Activity。所以关键点就是如何通过 gradle 调用命令行代码以及如何获取到 包名/首 Activity 信息。

  1. 开发者的直觉同样告诉我们 Gradle 开发文档中有关于命令行调用的信息,只需要使用 exec {} 闭包就好了。

  2. 如何获取 包名/首 Activity 信息?

    可以通过 AndroidManifest.xml 来获取。部分经验丰富的开发者知道——打入 apk 中的 AndroidManifest.xml 文件并不是我们平常写的 AndroidManifest.xml,而是 apk 编译后位于 Project/app/build/intermediates/manifests/full/debug/ 包下的 AndroidManifest.xml(当然,如果是 Release 包的话,应该是 Project/app/build/intermediates/manifests/full/release/ 包下)。

  • 包名就是 android 闭包下的 defaultConfig 闭包下的 applicationId

    640

  • 目标 Activity 则是包含 action 为 android.intent.action.MAIN 的 Activity。

    640

理解了以上内容,便不难理解下面的内容:

task installAndRun(dependsOn: 'assembleDebug') {
  doFirst {
    exec {
      workingDir "${buildDir}/outputs/apk/debug"
      commandLine 'adb', 'install', '-r', 'app-debug.apk'
    }
    exec {
      def path = "${buildDir}/intermediates/manifests/full/debug/AndroidManifest.xml"
      // xml 解析
      def parser = new XmlParser(false, false).parse(new File(path))
      // application 下的每一个 activity 结点
      parser.application.activity.each { activity ->
        // activity 下的每一个 intent-filter 结点
        activity.'intent-filter'.each { filter ->
          // intent-filter 下的 action 结点中的 @android:name 包含 android.intent.action.MAIN
          if (filter.action.@"android:name".contains("android.intent.action.MAIN")) {
            def targetActivity = activity.@"android:name"
            commandLine 'adb', 'shell', 'am', 'start', '-n',
                "${android.defaultConfig.applicationId}/${targetActivity}"
          }
        }
      }
    }
  }
}
  1. install apk 的前提必须是得有一个 apk,所以势必需要依赖 assembleDebug task。

    实际上 installDebug task 也是依赖 assembleDebug task 的,不妨可以试试——

    task showInstallDepends {
      doFirst {
        println project.tasks.findByName("installDebug").dependsOn
      }
    }

    ./gradlew showInstallDepends

    > Configure project :app

    task 'installDebug' input files, assembleDebug

  2. exec 闭包中的几个参数提及下——

    2.1 workingDir:工作环境,参数为 File 格式。默认为当前 project 目录。

    2.2 commandLine:需要命令行执行的命令,参数为 List 格式。

  3. 前一篇文章中提到 ——

    说白了它们其实就是一些闭包、一些固定格式,正是因为它们的格式是固定的,task 才能够读取到相应的数据完成相应的事情。

    在第二个 exec 闭包的第八行就很好的体现了这一点,通过 {android.defaultConfig.applicationId} 直接获取到 Gradle 文件中 android 闭包下的 defaultConfig 闭包下的 applicationId 的值。由此就获得了当前应用的包名。

    当然,除了 Gradle 能够调用命令行以外,实际上 groovy 也是可以调用命令行的,但在此就不做扩展了。

  4. 至于最先启动的 Activity,肯定是 action 为 android.intent.action.MAIN 的 Activity,那么问题就是变成如何在 AndroidManifest.xml 中寻找到该 Activity 的事了——作为一个合格的老司机,应该能够想到 groovy 一定会提供相应的 xml 解析 API 的,至于具体的使用笔者就不在此扩展了,留给各位读者去源码中探索成长。

  5. 除去上面的信息以外,还需要什么?还需要知道一些 gradle 构建的信息——例如 debug 包会最终出现在 ${buildDir}/outputs/apk/debug;例如 debug 包中的 AndroidManifest.xml 并不是日常开发中写的那个 AndroidManifest.xml(虽然可能它俩基本没什么差异),而是 ${buildDir}/intermediates/manifests/full/debug 下的 AndroidManifest.xml。所以一是希望各位读者日常多去翻翻 build 文件夹,二是要知道 ${buildDir}(build 文件夹)有多么重要,因为 Gradle 构建 apk 的过程中,但凡有输出文件那么基本都会存在这个文件夹中,所以多去翻一翻。

由此之后,可以在命令行输入以下命令:

./gradlew installAndRun

> Task :app:installAndRun

[ 4%] /data/local/tmp/app-debug.apk

[ 8%] /data/local/tmp/app-debug.apk

[ 12%] /data/local/tmp/app-debug.apk...

Success

Starting: Intent {com.test.Test/TestActivity}

至此便完成了一个安装并启动 apk 的 task 撰写了。

hook assets

上面的 task 看起来似乎和 Android 的构建过程并无多大关系,没错,那么接下来不妨深层次接触试试——通过 hook 原生 task 实现更改打包中的文件——在打包过程中向 assets 插入一张图片。

尽管这看起来丝毫没卵用

在打包流程中,有一个 task 名为 packageDebug,该 task 是打包文件生成 apk 的——

640

接着,不妨在命令行键入以下命令:

./gradlew help --task "packageDebug"

Type

PackageApplication (com.android.build.gradle.tasks.PackageApplication)

可以看到,该 task 的 type 是 PackageApplication——

640

不妨再看看它的父类 PackageAndroidArtifact

640

看到关键信息,该 task 中有一个类型为 FileCollection assets 字段,这便是最终打入 apk 中的那个 assets 了。所以不难写出以下代码——

task hookAssets {
  afterEvaluate {
    tasks.findByName("packageDebug").doFirst { task ->
      copy {
        from "${projectDir.absolutePath}/test.png"
        into "${task.assets.asPath}"
      }
    }
  }
}
  1. 在 project afterEvaluate 之后找到 packageDebug task

  2. 不妨在 app 目录下放入一个 test.png,使用 copy {} 闭包,from 填入的参数为 test.png 的路径,into 填入的参数为输出的路径,也就是 assets 的路径。

可以看到 /app/build/intermediates/assets/debug/ 下存有 test.png

640

同样地,解压 apk 文件也可以看到——

640

一个实打实的 Gradle task hook 流程就这么操作完了。

后记

如果说 Gradle task 是函数的话,那么 Gradle plugin 就是函数库,在后一节笔者将会对 Gradle plugin 进行阐述。

当然,如果各位读者有疑问的话,欢迎加入笔者的微信群。如果二维码失效,可以查看笔者最新文章的尾部。640



推荐阅读

我的安卓开发半年工作经验总结

安卓开发必备知识体系:Java篇

跳槽需要内推?这里有一大波机会



640


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值