使用Android Gradle的增量编译-案例分析

因为公司产品技术上的需求，更为了不落后于时代的潮流，这几天在调研Android的热修复技术。最终方案决定采用DexClassLoader的方式，方案跟nuwa 差不多。自定义了Gradle Task来插入到原有的打包流程，在打包过程中对生成的jar文件进行修改。

Groovy开发Gradle plugin的过程中有遇到些许问题，但是整体功能最终还是实现了。但是，功能实现后，发现每次直接点击Android Studio中额run都特别慢，尤其是即使我不修改代码的情况下run也需要90s以上。而如果不使用这个Plugin，不修改代码run只需要6-10s。

我意识到自定义task肯定影响了Gradle自身对打包过程的优化。然后就在网上调查相关的资料，然后发现了Gradle Incremental Build需要注意的事项。链接地址

To take advantage of the incremental build support, you need to provide Gradle with information about your task’s inputs and outputs. It is possible to configure a task to only have outputs. Before executing the task, Gradle checks the outputs and will skip execution of the task if the outputs have not changed.

其中提到比较重要的一点是Task至少要有outputs，才能保证增量式更新。

第一次修改：给所有自定义task添加outputs。
修改完成之后，第二次build的总时间并没有得到提升。 于是打印出打包的日志。

gradlew aDebug --info > debug_log.txt

如果task被Skip的话，log会给出 task up-to-date的提示。

:Zeus:packageReleaseResources Skipping task
':Zeus:packageReleaseResources' as it is up-to-date (took 0.002 secs).
:Zeus:packageReleaseResources UP-TO-DATE
:Zeus:packageReleaseResources (Thread[Daemon worker Thread 10,5,main]) completed. Took 0.003 secs.

然后发现最耗时的dexDebug Task并不是Up-To-Date状态，而原因是输入文件 allclasses.jar跟上次此task执行时发生了变化。

:app:dexDebug (Thread[Daemon worker Thread 10,5,main]) started.
:app:dexDebug Executing task ':app:dexDebug' (up-to-date check took 0.001 secs) due to:
Input file /Users/.../app/build/intermediates/multi-dex/debug/allclasses.jar has changed.

进一步追踪导致这个输入变化的原因，找到以下信息：

:app:packageAllDebugClassesForMultiDex (Thread[Daemon worker Thread 10,5,main]) started.
:app:packageAllDebugClassesForMultiDex
Executing task ':app:packageAllDebugClassesForMultiDex' (up-to-date check took 0.066 secs) due to:
Output file /Users/.../ap p/build/intermediates/multi-dex/debug/allclasses.jar has changed.

是MultiDex的task生成的jar包与上次该task执行时的输出发生了变化。为何呢？ 后来联想了以下，是因为我在 MultiDex 的packageAllDebugClassesForMultiDex task之后又对allClasses.jar进行了修改，所以第二次build到这个task它会认为jar文件发生了变化需要重新生成，这才引起了整个流程都不能走增量编译。

那么问题就来了，在不能修改MultiDex的packageAllDebugClassesForMultiDex task源码的情况下，我怎么能保证它的输出不会变化呢？ 与此同时，我确实还要对jar包进行修改。

花费了半天才臆想到解决办法，那就是通过Groovy的语法，指定 packageAllDebugClassesForMultiDex task 在执行完原有逻辑之后，执行另外的一部分修改jar的逻辑。系统会认为修改jar是packageAllDebugClassesForMultiDex task 做的操作。具体代码就是利用task.doLast 来实现：

if (multiDexPackageTask) {
//如果开启MultiDex, preDex应该默认是被禁用了
multiDexPackageTask.doFirst(zeusPrepareClosure)
multiDexPackageTask.doLast {
    def inputFiles = dexTask.inputs.files.files
    def paths = []
    inputFiles.each { inputFile ->
        def path = inputFile.absolutePath
        paths.add(path)
        if (path.endsWith(".jar")) {
            ZeusProcessor.processJar(hashFile, inputFile, patchDir, hashMap, excludeClass)
        }}
    }
}

在MultiDex的packageAllDebugClassesForMultiDex 跑完之后生成的jar文件就已经是我需要的jar了。并且会被认为是该task自己生成的没被其他任务修改过的。

最终第二次build的速度终于正常了。Cheers！

这不是一个多么严重的问题，但是解决这个问题的过程中遇到一些有意思的事情也花了不少的时间，分享出来，希望对大家有帮助。

PS.
产品中用了MultiDex，所以是这么解决，而对于没有用MultiDex的工程，就需要从preDexDebug这个task来入手了。