随着项目的不断迭代，项目越来越大，编译时间也是越来越多，特别是多module的项目更是严重，每次编译项目的时候都是痛苦的等待，那么我们怎么去发现项目里面编译时间花费的地方呢？
查看Task编译时间
通过命令窗口，输入gradlew build –profile 命令，如图
2017-07-28_222419.png
android studio就会进行编译，经过漫长的等待。并在项目的根目录–build–report底下生成一个文件（4），如图：
root.png
然后在浏览器打开该文件
2017-07-28_212603.png
我们可以看到task 总共花了10分钟。。。。。
first.png
定位耗时Task
具体的时间花费可以进入Task Execution查看，我们可以发现主要是lint这个task花费了很多时间，这里就只对这个task 进行分析。
lint.png
我们知道lint 是用来代码检查的，为了项目的代码更加的符合规范。这个是android studio 内置的task ，一般情况下是不建议把这个关闭的，这里只是为了引出关闭耗时的task，作为分析的。或者你可以刚开始开发的时候关闭，后面再开启检测，专门进行整理，按照自己的习惯安排。
setting.png
那么我们怎么去关闭这个任务呢？
如何关闭不必要的Task
- 更改配置
一个最简单的方法，自定义一个inspections,如图，将所有lint(我这里为了简单全部去掉，读者可以根据需要勾选)
self.png
如果你不想修改配置，还是想关闭lint，那怎么做呢？还是有办法的！
- 通过命令执行
比如 ./gradlew build -x lint （linux系统执行命令要加./ windows则不需要，其中的 -x就是不执行的意思，build就是具体的命令）
如果需要跳过多个命令的话./gradlew build -x checkstyle -x pmd -x findbugs -x lint -x test
- 代码里面执行
如果想所有情况都生效，可以写在gradle文件里面。
tasks.whenTaskAdded{ task->
if(task.name.equals(“lint”)) {
task.enabled=false
}
}
这段代码放到gradle文件的最顶端（在apply的前面执行）
查看效果
最后再一次执行 gradlew build –profile 查看相应的分析文件，花费的时间变成了以前的五分之一（公司的项目比较大，所以编译时间比较多）
profile2.png
lint这个task没有了
lint2.png
其他编译优化
这点就不展开了，这里提供根目录的gradle.properties 的配置，具体请看注释，其他优化，网上有很多，请自行查阅
# Specifies the JVM arguments used for the daemon process.
# The setting is particularly useful for tweaking memory settings.
#手动配置Gradle编译时内存分配
# Default value: -Xmx10248m -XX:MaxPermSize=256m
org.gradle.jvmargs=-Xmx2048m -Xms512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
# When configured, Gradle will run in incubating parallel mode.
# This option should only be used with decoupled projects. More details, visit
# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects 开启并行编译
org.gradle.parallel=true
//按需编译
org.gradle.configureondemand=true
#开启编译守护进程 该进程在第一次启动后回一直存在，当你进行二次编译的时候，可以重用该进程。
org.gradle.daemon=true
# 开启JNI编译支持过时API
android.useDeprecatedNdk=true
常见的task
* :app:clean
该步骤主要是清理上次编译的遗留产物，删除module下的build文件夹内所有内容
* :app:preDebugBuild
新建build文件夹，内部新增intermediates/incremental文件夹，针对各个不同的buildType，新建对应的文件夹，内部新增zip-cache文件夹，内容为空
* :app:checkDebugManifest
AndroidManifest检查，貌似不包括内容检查，故意写错也不会报错
* :app:preBt1Build
看起来没有做特别的事情……
* :app:preBt2Build
看起来没有做特别的事情……
* :app:preReleaseBuild
看起来没有做特别的事情……
* :app:prepareBrowserProfessionalLibrary
将工程中用到的某个aar拷贝并解压缩到module下的build/intermediates/exploded-aar/**/目录下，内容已经解压缩了
* :app:prepareComAndroidSupportAnimatedVectorDrawable2340Library
将support对应的包解压缩到exploded-aar文件夹下，与上一个逻辑基本相同
* :app:prepareComAndroidSupportAppcompatV72340Library
与上述一致
* :app:prepareComAndroidSupportDesign2340Library
与上述一致
* :app:preDebugAndroidTestBuild
_没有看到对应的结果，使用的工程里面没有test吧，估计_
* :app:prepareComAndroidSupportMultidex101Library
对multidex的支持，在exploded-aar中新建对应文件
* :app:prepareComAndroidSupportRecyclerviewV72340Library
同上support操作
* :app:prepareComAndroidSupportSupportV42340Library
* :app:prepareComAndroidSupportSupportVectorDrawable2340Library
* :app:prepareComBrowserCommomCore720Library
将对应aar解压缩到对应位置，如上述
* :app:prepareDebugDependencies
_没有看到对应的变化，应该是没有对应的配置导致的_
* :app:compileDebugAidl
生成generated文件夹，下面对应有aidl文件夹，针对当前buildtype生成对应的文件夹
* :app:compileDebugRenderscript
generated文件夹下，生成res文件夹，针对对应的buildtype生成对应文件夹
* :app:generateDebugBuildConfig
generated/source文件夹下，生成buildConfig文件夹，针对对应的buildtype生成对应文件夹
* :app:generateDebugResValues
generated/res文件夹下，生成resValues文件夹，针对对应的buildtype生成对应文件夹
* :app:generateDebugResources
_看起来没有新的文件生成……_
* :app:mergeDebugResources
merge资源文件，在intermediates下生成res文件夹以及blame文件夹，其中放置merge后的资源文件
* :app:processDebugManifest
将merge后的Manifest文件放在intermediates/manifests文件夹下
* :app:processDebugResources
处理资源文件，生成R.txt文件，同时也生成对应的multidex文件夹，内容为空
* :app:generateDebugSources
在generated文件夹下生成对应的R.java文件
* :app:incrementalDebugJavaCompilationSafeguard
在incremental-safeguard目录下生成tag.txt，标识已经执行过task
* :app:compileDebugJavaWithJavac
intermediates下生成classes文件夹，以及对应的dependency-cache文件夹，classes文件夹中包含之前已经解压的各个aar文件中的类，但是不包含libs下的jar包中的内容；_同时还会生成一个tmp文件夹，内容为空_；**目录下不包括libs下的jar包内容**
* :app:compileDebugJavaWithJavac - is not incremental (e.g. outputs have changed, no previous execution, etc.).
* :app:compileDebugNdk
工程下没有对应的ndk编译，没有新内容增加
* :app:compileDebugSources
_看起来没有什么文件变化，不清楚这个阶段在做什么，可能是加入R文件参与编译吧_
* :app:mergeDebugShaders
_新建了一个shaders文件夹，但是内容为空，这块还需要看下_
* :app:compileDebugShaders
_没有文件变化，不清楚是干嘛的_
* :app:generateDebugAssets
在generated文件夹下生成assets文件夹，但是内容为空
* :app:mergeDebugAssets
在intermediates下生成assets文件夹，将其他module/aar中的assets文件拷贝过来
* :app:transformClassesWithTransformImplForDebug
由于工程gradle实现了transform的plugin，文件被拷贝到对应的目录，对应的class文件也已经被操作过了；对应的jar包也被操作过了。jar目录中的文件数量是libs下和aar下的所有jar包的合集。folder下的目录也无缺失
* :app:transformClassesWithJarMergingForDebug
将所有jar包merge到一起，在transform的jarMerging下，生成一个combined.jar，其他地方未见对应jar包
* :app:transformClassesWithMultidexlistForDebug
在multi-dex文件夹下生成对应buildtype的componentClasses.jar\components.flags\maindexlist.txt文件，_由于demo工程较小，因此未见多个jar包_
* :app:transformClassesWithDexForDebug
新增一个pre-dexed文件夹，内部为空
transform内部新增一个dex文件夹，内部存在一个classes.dex文件
* :app:mergeDebugJniLibFolders
新增一个jniLibs文件夹，内部将工程使用的所有so都放置在一起
* :app:transformNative_libsWithMergeJniLibsForDebug
将所有so库都放在transform目录下，按照架构区分放置
* :app:processDebugJavaRes UP-TO-DATE
生成aapt-temp文件夹，内容为空
* :app:transformResourcesWithMergeJavaResForDebug
在transform目录下生成mergeJavaRes文件夹，内部有一个main.jar
* :app:validateSigningDebug
应该是在做一些校验操作，没有明显的文件变化
* :app:packageDebug
在output文件夹中生成app-debug.apk，此时app已经可以安装了（这里忽略了签名的过程）
* :app:assembleDebug
_没看出来文件有啥具体变化……_
上面这个task列表转自http://blog.csdn.net/zhaofuchang321/article/details/54892412 ,里面的对错没有详细研究过，所以读者自行查阅。
再给个福利（一般可以干掉的task）
tasks.whenTaskAdded { task ->
if (task.name.contains(“lint”)//如果instant run不生效，把clean这行干掉
||task.name.equals(“clean”)//项目中有用到aidl则不可以舍弃这个任务
||task.name.contains(“Aidl”)//用不到测试的时候就可以先关闭
||task.name.contains(“mockableAndroidJar”)
||task.name.contains(“UnitTest”)
||task.name.contains(“AndroidTest”)//用不到NDK和JNI的也关闭掉
|| task.name.contains(“Ndk”)
|| task.name.contains(“Jni”)
) {
task.enabled = false
}
}
