美剧网站怎么做,wordpress文章 模板,用vs2012做网站,动物园网站建设的可行性分析一、前言 只有 Task 才可以在 Gradle 的执行阶段去执行#xff08;其实质是执行的 Task 中的一系列 Action#xff09;#xff0c;所以 Task 的重要性不言而喻。 二、Task 2.1 Task 定义与配置
Task 的定义方式有如下两种#xff1a; Task 的配置方式也有如下两种#xf…一、前言 只有 Task 才可以在 Gradle 的执行阶段去执行其实质是执行的 Task 中的一系列 Action所以 Task 的重要性不言而喻。 二、Task 2.1 Task 定义与配置
Task 的定义方式有如下两种 Task 的配置方式也有如下两种 配置了 group 后可以在 Android Studio 的 Gradle 面板看到对应的 Task Group 及其分组下的 Tasks如下图所示 一般来说都推荐为我们的 task 配置 group便于我们查找 task。另外group 和 descreption 只是最基本的配置我们看下 Task 的源码 可以看到这些属性都是可以进行配置的后面会一一讲解。
选型描述默认值nametask 名字无必须指定type需要创建的 task ClassDefaultTaskaction当 task 执行的时候需要执行的闭包 closure 或 行为 Actionnulloverwrite替换一个已存在的 taskfalsedependsOn该 task 所依赖的 task 集合[]group该 task 所属组nulldescriptiontask 的描述信息nullconstructorArgs传递到 task Class 构造器中的参数null 2.2 Task 执行
上一节我们定义了两个 task我们来执行其中一个 看到上述输出我们会有个疑问为什么我们执行 helloTask2但是 helloTask 也被执行输出了呢其实很简单因为这两个 task 都是在 gradle 配置阶段执行的所以我们任何 task 的执行我们 project 的整个配置代码都是会执行的所以这两个输出语句都会被执行到。
我们可以通过添加 doFirst 与 doLast 执行动作Action为我们的 task 指定执行阶段要执行的代码这样它就只会在 gradle 执行阶段去执行。需要注意的是doFirst 和 doLast 是可以被执行多次的。对于 doFirst 与 doLast 这两个 Action它们的作用分别如下所示
doFirst表示 task 执行最开始的时候被调用的 Action。doLast表示 task 将执行完的时候被调用的 Action。
我们来验证下 接下来我们就使用 doFirst 与 doLast 来进行一下实战来实现计算 build 执行期间的耗时其完整代码如下所示 2.3 Task 执行顺序
指定 Task 的执行顺序有三种方式如下图所示 2.3.1 dependsOn 强依赖方式
dependsOn 强依赖的方式可以细分为静态依赖和动态依赖首先看看静态依赖如下所示 taskZ 依赖 taskX 和 taskY 执行 taskZ 看看 可以看到被依赖的 task 先执行这和我们 java 的继承关系是很相似的。需要注意的是这里 taskX 和 taskY 的执行顺序是随机的。
下面我们再来看看动态依赖 2.3.2 通过Task输入输出指定 我们也可以通过 Task 来指定输入输出Task 的输入输出对应 TaskInput 和 TaskOutput。下面我们来看一个示例使用这种方式实现一个自动维护版本发布文档的 gradle 脚本其中输入输出相关的代码如下所示 首先我们定义了一个 WirteTask然后在注释1处指定了输出文件为 destFile 并写入版本信息到 XML 文件。接着定义了一个 readTask并在注释2处指定输入文件为上一个 task即 writeTask 的输出文件。最后在注释3处使用 dependsOn 将这两个 task 关联起来此时输入与输出的顺序是会先执行写入再执行读取。这样一个输入输出的实际案例就实现了。 2.3.3 通过API指定执行顺序
除了 dependsOn 的方式我们还可以在 task 闭包中通过 mustRunAfter 方法指定 task 的依赖顺序mustRunAfter 可以指定一个或多个 task其示例代码如下所示 下面我们在命令行中将 taskX、taskY、taskZ 打乱执行 可以看到最终的执行顺序始终是 taskX、taskY、taskZ。
mustRunAfter 是强制指定顺序另外还有一个 shouldRunAfter 不强制性指定实际应用中一般不会使用 shouldRunAfter了解一下即可。 2.4 挂接自定义 task 到构建生命周期
我们可以使用 gradle 提供的一系列生命周期 API 去挂接我们自己的 task 到构建生命周期之中比如使用 afterEvaluate 方法将我们第三小节定义的 writeTask 挂接到 gradle 配置完所有的 task 之后的时刻示例代码如下所示 2.5 Task 类型
除了定义一个新的 task 之外我们也可以使用 task 的 type 属性来直接使用一个已有的 task 类型比如 Gradle 自带的 Copy、Delete、Sync task 等等。示例代码如下所示 更多的 Task 类型我们可以查阅官方文档。 Android 对 Gradle 的扩展Variants、Transform
一、前言 本篇我们来学习下 Android 对 Gradle 的扩展Variants变体以及 Transform。通过扩展可以让我们在自定义 Gradle 插件时做更多的事情。 二、Variants变体 2.1 Variants 是什么
要理解 Variants 的作用就必须先了解 buildType、flavor、dimension 与 variant 之间的关系。在 android gradle plugin V3.x 之后每个 flavor 必须对应一个 dimension可以理解为 flavor 的分组然后不同 dimension 里的 flavor 会组合成一个 variant。示例代码如下所示 android {...defaultConfig {...}//gradle 默认就有 debug 和 release 两个 buildTypebuildTypes {debug{...}release{...}}flavorDimensions versionproductFlavors {demo {dimension version}full {dimension version}}}
根据上述配置 Gradle 会创建以下构建变体
demoDebugdemoReleasefullDebugfullRelease
在 Android 对 Gradle 插件的扩展支持之中其中最常用的便是利用变体Variants来对构建过程中的各个默认的 task 进行 hook。关于 Variants 共有 三种类型如下所示
applicationVariants只适用于 app plugin。libraryVariants只适用于 library plugin。testVariants在 app plugin 与 libarary plugin 中都适用。
2.2 Variants 的使用
我们来看看 applicationVariants 的使用首先我们在 app.gradle 中配置 buildTypes、flavorDimensions、productFlavors 同上。然后我们可以 使用 applicationVariants.all 在配置阶段之后去获取所有 variant 的 name 与 baseName。代码如下所示 最后我们来执行下 gradle clean 任务 可以看到name 与 baseName 的区别demoDebug 与 demo-debug 。
接下来我们来看看使用 applicationVariants.all 在配置阶段之后去修改输出的 APK 名称 可以看到我们上面用到了一个 releaseTime() 方法获取当前时间 最后我们来执行以下 gradle clean 可以看到正常修改了 apk 的名称。
最后我们来看一下如何对 applicationVariants 中的 Task 进行 Hook我们可以在 android.applicationVariants.all 的闭包中通过 variant.task 来获取相应的 Task。代码如下所示 然后执行 gradle clean其输出信息如下所示既然可以获取到变体中的 Task我们就可以根据不同的 Task 类型来做特殊处理。例如我们可以利用 variants 去解决插件化开发中的痛点编写一个对插件化项目中的各个插件自动更新的脚本其核心代码如下所示 至于 update_plugin 的实现主要就是一些插件安全校验与下载的逻辑这部分其实跟 Gradle 没有什么联系。
variant 中能获取到哪些 task 我们可以去 ApplicationVariant 的父类 BaseVariant 中去查看比如 2.3 Gradle 构建流程
在执行 Android 项目的构建流程可以发现没有任何修改的情况下就已经有 30 多个Task需要执行 其中关键的 task 如下 三、Transform Google 官方在 Android Gradle V1.5.0 版本以后提供了 Transfrom API允许第三方 Plugin 在打包成 .dex 文件之前的编译过程中操作 .class 文件我们需要做的就是实现 Transform 来对 .class 文件遍历以拿到所有方法修改完成后再对原文件进行替换即可。总的来说Gradle Transform 的功能就是把输入的 .class 文件转换为目标字节码文件。我们可以通过 Gradle Plugin 来注册我们编写的 Transform。注册后的 Transform 会被 Gradle 包装成一个 Gradle Task这个 TransForm Task 会在 java compile Task 执行完毕后运行。
我们来看看 Transform 的执行流程图 3.1 Transform 的使用
下面我们来看看如何使用 Transform首先如果是在 buildSrc 中由于 buildSrc 的执行时机要早于任何一个 project因此需要添加仓库 然后创建一个 Transform 的子类继承自 com.android.build.api.transform.Transform 可以看到其创建步骤可以细分为五步如下所示
3.1.1、getName()
指定自定义 Transform 的名称。返回对应的 Task 名称。
3.1.2、getInputTypes()
可以看到这个方法返回的是一个 SetQualifiedContent.ContentType 集合指明你自定义的这个 Transform 处理的输入类型集合。QualifiedContent.ContentType 是一个接口它的实现类有 DefaultContentType 和 ExtendedContentType。为了方便 TransformManager 为我们封装了以下几种输入类型集合 分别代表的是
CONTENT_CLASS表示需要处理 java 的 class 文件。CONTENT_JARS表示需要处理 java 的 class 与 资源文件。CONTENT_RESOURCES表示需要处理 java 的资源文件。CONTENT_NATIVE_LIBS表示需要处理 native 库的代码。CONTENT_DEX表示需要处理 DEX 文件。CONTENT_DEX_WITH_RESOURCES表示需要处理 DEX 与 java 的资源文件。
3.1.3、getScopes()
可以看到这个方法返回的是一个 SetQualifiedContent.Scope 集合用来指明自定义的 Transform 的输入文件所属的范围这是因为 gradle 是支持多工程编译的。Scope 是一个枚举类 可以看到目前有 5 种基本类型分别代表的是
PROJECT只有项目内容。SUB_PROJECTS只有子项目。EXTERNAL_LIBRARIES只有外部库TESTED_CODE由当前变体包括依赖项所测试的代码。PROVIDED_ONLY只提供本地或远程依赖项。
同样为了方便TransformManager 为我们封装了 getScope 的返回 如果一个 Transform 不想处理任何输入只是想查看输入的内容那么只需在 getScopes() 返回一个空集合然后在getReferencedScopes() 返回想要接收的范围。 public Set? super Scope getReferencedScopes() { return ImmutableSet.of(); }
3.1.4、isIncremental()
isIncremental 方法用于确定是否支持增量更新如果返回 trueTransformInput 会包含一份修改的文件列表如果返回 false则会进行全量编译并且会删除上一次的输出内容。
3.1.5、transform(TransformInvocation transformInvocation)
它是 Transform 的关键方法在 transform() 方法中就是用来给我们进行具体的输入输出转换过程的。它是一个空实现input 的内容将会打包成一个 TransformInvocation 对象因为我们要想使用 input我们需要详细了解一下 TransformInvocation 参数。
public interface TransformInvocation {// 输入作为 TransformInput 返回CollectionTransformInput getInputs(); //TransformOutputProvider 可以用来创建输出内容TransformOutputProvider getOutputProvider(); boolean isIncremental();
...
}
TransformInput 可认为是所有输入文件的一个抽象它主要包括两个部分如下所示
public interface TransformInput {CollectionJarInput getJarInputs();CollectionDirectoryInput getDirectoryInputs();
}public interface JarInput extends QualifiedContent {File getFile(); //jar文件SetContentType getContentTypes(); // 是class还是resourceSet? super Scope getScopes(); //属于Scope
}
其中
DirectoryInput 集合表示以源码方式参与项目编译的所有目录结构与其目录下的源码文件。JarInput 集合表示以 jar 包方式参与项目编译的所有本地 jar 包和远程 jar 包。需要注意的是这个 jar 所指也包括 aar。
TransformOutputProvider 表示 Transform 的输出利用它我们可以获取输出路径等信息。
public interface TransformOutputProvider {//根据 name、ContentType、QualifiedContent.Scope返回对应的文件( jar / directory)File getContentLocation(String name, SetQualifiedContent.ContentType types, Set? super QualifiedContent.Scope scopes, Format format);
}
即我们可以通过 TransformInvocation 来获取输入同时也获得了输出的功能。举个例子 Overridevoid transform(TransformInvocation transformInvocation) throws TransformException, InterruptedException, IOException {super.transform(transformInvocation)println --------------- MyCustomTransform visit start --------------- def startTime System.currentTimeMillis()def inputs transformInvocation.inputsdef outputProvider transformInvocation.outputProvider// 1、删除之前的输出 if (outputProvider ! null) {outputProvider.deleteAll()}// Transform 的 inputs 有两种类型一种是目录一种是 jar包要分开遍历 inputs.each { TransformInput input -// 2、遍历 directoryInputs本地 project 编译成的多个 class⽂件存放的目录 input.directoryInputs.each { DirectoryInput directoryInput -handleDirectory(directoryInput, outputProvider)}// 3、遍历 jarInputs各个依赖所编译成的 jar 文件 input.jarInputs.each { JarInput jarInput -handleJar(jarInput, outputProvider)}}def cost (System.currentTimeMillis() - startTime) / 1000println --------------- MyCustomTransform visit end --------------- println MyCustomTransform cost $cost s}
这里我们主要是做了三步处理如下所示
删除之前的输出。遍历 directoryInputs本地 project 编译成的多个 class ⽂件存放的目录。遍历 jarInputs各个依赖所编译成的 jar 文件。
在 handleDirectory 与 handleJar 方法中则是进行了相应的 文件处理 ASM 字节码修改。
编写完 Transform 的代码之后我们就可以在 Plugin 的 apply 方法中加入下面代码去注册 TransformTest 的实例代码如下所示
