一、背景描述

二、效果展示

三、思路問題分析與模塊搭建

四、問題解決與實現

五、一天一個小驚喜

六、下一步展望

一、背景描述

在項目體量越來越大的情況下，編譯速度也隨著增長，有時候一個修改需要等待長達好幾分鐘的編譯時間。
基于這種普遍的情況，推出了 RocketX ,通過在編譯流程 動態 替換 module 為 aar ，提高全量編譯的速度。讓你體驗到所有模塊都是 aar 的速度，又能保留所有的 module 便于修改，簡直完美！

二、效果展示

2.1、測試項目介紹

• 目標項目一共 3W+ 個類與資源文件，全量編譯 4min 左右

• 通過 RocketX 全量增速之后的效果（每一個操作取 3 次平均值）
  

  build-speed.png

• 項目依賴關系如下圖，app 依賴 bm 業務模塊，bm 業務模塊依賴頂層 base/comm 模塊

架構圖.png

• rx(RocketX) 編譯 - 可以看到 rx(RocketX) 在無論哪一個模塊的編譯速度基本都是在控制在 30s 左右，因為只編譯 app 和 改動的模塊，其他模塊是 aar 包不參與編譯。
• 原生編譯 - 當 base/comm 模塊改動，底部的所有模塊都必須參與編譯。因為 app/bmxxx 模塊可能使用了 base 模塊中的接口或變量等，并且不知道是否有改動到。（那么速度就非常慢）
• 原生編譯和RocketX 的編譯差距就體現在這里，RocketX 少編了 60+ 個模塊，從而實現提速：

1641484922(1).png

三、思路問題分析與模塊搭建:

3.1、思路問題分析

• 上個思維導圖，涉及到以下問題：

  
  
  未命名文件 (3).jpg

1. 需要通過 gradle plugin 的形式動態修改沒有改動過的 module 依賴為 相對應的 aar 依賴，如果 module 改動，退化成 project 工程依賴，這樣每次只有改動的 module 和 app 兩個模塊編譯。
2. 需要把 implement/api moduleB，修改為implement/api aarB，并且需要知道插件中如何加入 aar 依賴和剔除原有依賴
3. 需要構建 local maven 存儲未被修改的 module 對應的 aar（也可以通過 flatDir 代替速度更快）
4. 編譯流程啟動，需要找到哪一個 module 做了修改
5. 需要遍歷每一個 module 的依賴關系進行置換， module 依賴怎么獲?。恳淮涡阅塬@取到所有模塊依賴，還是分模塊各自回調？修改其中一個模塊依賴關系會阻斷后面模塊依賴回調？
6. 每一個 module 換變成 aar 之后，自身依賴的 child 依賴 （網絡依賴，aar）,給到 parent module (如何找到所有 parent module) ? 還是直接給 app module ? 有沒有 app 到 module 依賴斷掉的風險？ 這里需要出一個技術方案。
7. 需要hook 編譯流程，完成后置換 loacal maven 中被修改的 aar
8. 提供 AS 狀態欄 button, 實現開啟關閉功能，加速編譯還是讓開發者使用已經習慣性的三角形 run 按鈕

3.2、模塊搭建

• 依照上面的分析，雖然問題很多，但是大致可以把整個項目分成以下幾塊：

image.png

四、問題解決與實現:

4.1、如何手動添加 aar 依賴，分析implement 源碼實現入口在 DynamicAddDependencyMethods 中的 tryInvokeMethod 方法。他是一個動態語言的 methodMissing 功能

• tryInvokeMethod 代碼分析

 public DynamicInvokeResult tryInvokeMethod(String name, Object... arguments) {
       //省略部分代碼 ...
       return DynamicInvokeResult.found(this.dependencyAdder.add(configuration, normalizedArgs.get(0), (Closure)null));
 }

• dependencyAdder 實現是一個 DirectDependencyAdder

private class DirectDependencyAdder implements DependencyAdder<Dependency> {
        private DirectDependencyAdder() {
        }
        public Dependency add(Configuration configuration, Object dependencyNotation, @Nullable Closure configureAction) {
            return DefaultDependencyHandler.this.doAdd(configuration, dependencyNotation, configureAction);
        }
    }

• 最后是在 DefaultDependencyHandler.this.doAdd 進行添加進去，而 DefaultDependencyHandler 在 project可以獲取

public interface Project extends Comparable<Project>, ExtensionAware, PluginAware {
     ...
     DependencyHandler getDependencies(); 
     ...
}

• 而 doAdd 方法三個參數通過 debug 源碼發現，configuration 就是 "implementation", "api", "compileOnly" 這三個字符串生成的對象，dependencyNotation 是一個 LinkHashMap 有兩個鍵值對，分別是 name:aarName, ext:aar,最后一個configureAction 傳 null 就可以了，調用 project.dependencies.add 最終會調到 doAdd 方法，也就是說直接調用 add 即可。

 public Dependency add(String configurationName, Object dependencyNotation) {
        return this.add(configurationName, dependencyNotation, (Closure)null);
    }

    public Dependency add(String configurationName, Object dependencyNotation, Closure configureClosure) {
       //這里直接調用到了 doAdd 
        return this.doAdd(this.configurationContainer.getByName(configurationName), dependencyNotation, configureClosure);
    }
    

• 那么依葫蘆畫瓢添加 aar/jar 的實現代碼：configName 是 childProject 中的 configName ，也就是 "implementation", "api", "compileOnly" 這三個字符串，原封不動拿過來：

    fun addAarDependencyToProject(aarName: String, configName: String, project: Project) {
        //添加 aar 依賴 以下代碼等同于 api/implementation/xxx (name: 'libaccount-2.0.0', ext: 'aar'),源碼使用 linkedMap
        val map = linkedMapOf<String, String>()
        map.put("name", aarName)
        map.put("ext", "aar")
        project.dependencies.add(configName, map)
    }

4.2、localMave 優先使用 flatDir 實現通過指定一個緩存目錄 getLocalMavenCacheDir 把生成 aar/jar 包丟進去,依賴修改時候通過 上面的 4.1 添加對應的 aar 即可：

  fun flatDirs() {
        val map = mutableMapOf<String, File>()
        map.put("dirs", File(getLocalMavenCacheDir()))
        appProject.rootProject.allprojects {
            it.repositories.flatDir(map)
        }
    }

4.3、編譯流程啟動，需要找到哪一個 module做了修改

• 使用遍歷整個項目的文件的 lastModifyTime 去做實現
• 已每一個 module 為一個粒度，遞歸遍歷當前 module 的文件，把每個文件的 lastModifyTime 整合計算得出一個唯一標識 countTime
• 通過 countTime 與上一次的作對比,相同說明沒改動,不同則改動. 并需要同步計算后的 countTime 到本地緩存中
• 整體 3W 個文件耗時 1.2s 可以接受，目前在類 ChangeModuleUtils.kt 進行實現

4.4、 module 依賴關系獲取

• 目的找到生成整個項目的依賴關系圖時機，并在此處生成依賴圖解析器。時機要在run 編譯的 task之前，確保依賴關系獲取后替換能生效，而且要在全局module依賴圖已經生成之后（也就是在 執行完build.gradle），那么有目前有兩種方式：DependencyResolutionListener 和 projectsEvaluated ，但是目前都有問題 。

1. 通過監聽DependencyResolutionListener，并在beforeResolve回調方法處理：

  public interface DependencyResolutionListener {
    void beforeResolve(ResolvableDependencies var1);

    void afterResolve(ResolvableDependencies var1);
}

   project.gradle.addListener(DependencyResolutionListener listener)

2. 但是出現的問題是beforeResolve 會回調多次，并且執行完畢每一個module的 build.gradle 把依賴解析出來則會回調。那么如果在業務層處理一下，等待到最后一個module 回調完畢，再通過 project.configurations 獲取到所有 module 的依賴圖？答案是可以的，但是 時機已經晚了，等到最后一個module 解析完畢之后 回調 beforeResolve ，再去修改依賴關系會報以下異常（無法修改依賴關系）：

Cannot change dependencies of dependency configuration ':app:implementation' after it has been included in dependency resolution.

3. 換個法子通過project.gradle.projectsEvaluated {}回調之后拿到所有 module 依賴關系并且去修改。依賴圖可以拿到，但是修改依賴關系還是會報異常，時機終究還是晚了。

4. 那么過一遍 gradle 的生命周期（網上摳圖）

20190530121157928.png

5. 發現執行完畢build.gradle（解析完依賴）之后的生命周期只有：Project.afterEvaluate 和 Gradle.projectsEvaluated（在3中試過不行）。那么只有afterEvaluate ，afterEvaluate 還是每 個module 執行完畢依賴會回調一次，監聽最后一個module 回調的時機，并修改依舊還是報相同錯誤。綜上在生命周期找不到合適的時機
6. 直接找 gradle 源碼 找到異常出現的代碼，具體是在 ：DefaultConfiguration.preventIllegalMutation 這個方法

private void preventIllegalParentMutation(MutationType type) {
        if (type != MutationType.DEPENDENCY_ATTRIBUTES) {
            if (this.resolvedState == InternalState.ARTIFACTS_RESOLVED) {
                throw new InvalidUserDataException(String.format("Cannot change %s of parent of %s after it has been resolved", type, this.getDisplayName()));
            } else if (this.resolvedState == InternalState.GRAPH_RESOLVED && type == MutationType.DEPENDENCIES) {
                throw new InvalidUserDataException(String.format("Cannot change %s of parent of %s after task dependencies have been resolved", type, this.getDisplayName()));
            }
        }
    }
    

7. 出現這個異常的原因主要是type 為 MutationType.DEPENDENCY_ATTRIBUTES，那么在哪里賦值為 DEPENDENCY_ATTRIBUTES，并趕在它之前修改依賴不就解決了，給出相關 gradle 源碼調用流程：

未命名文件 (1).png

8. 那么基本是通過apply plugin: 'com.android.application' 開始調用進來并通過設置
   project.gradle.projectsEvaluated{} 監聽回調，把type 設置成 DEPENDENCY_ATTRIBUTES ，通過這次排查源碼知道 gradle 也是通過projectsEvaluated 這個生命周期才開始解決依賴關系（這時候所有的module 的依賴圖才全部生成）

9. 那么最后的解決方法 要在 projectsEvaluated 去修改依賴，但是要趕在 GradlePluginUtils 里面的一個監聽者之前，通過反射剔除設置進去的所有 projectsEvaluated監聽者（其實就是 Action 的匿名內部對象），先執行 rockectXPlugin 的監聽者，后面再執行其他的監聽者。大概是這樣子：

//AppProjectDependencies.kt
    init {
        val projectsEvaluatedList = hookProjectsEvaluatedAction()
        project.gradle.projectsEvaluated {
            //先執行重依賴
            resolveDenpendency()
            //后執行移除的監聽（主要調整執行順序，重依賴才能生效和不報錯，可能有AGP 版本兼容問題）
            val clazz = Class.forName("org.gradle.api.invocation.Gradle")
            val method = clazz.getDeclaredMethod("projectsEvaluated", Action::class.java)
            val mMethodInvocation = MethodInvocation(method, arrayOf(it))
            projectsEvaluatedList.forEach {
                it.dispatch(mMethodInvocation)
            }

        }
    }

    //把所有 監聽了 projectsEvaluated 的匿名內部類移除
    fun hookProjectsEvaluatedAction(): List<BroadcastDispatch<BuildListener>> {
        var removeDispatch = mutableListOf<BroadcastDispatch<BuildListener>>()
        try {
            var buildListenerBroadcast: ListenerBroadcast<BuildListener>? = null
            val fBuildListenerBroadcast =
                    DefaultGradle::class.java.getDeclaredField("buildListenerBroadcast")
            fBuildListenerBroadcast.isAccessible = true
            buildListenerBroadcast =
                    fBuildListenerBroadcast.get(project.gradle) as? ListenerBroadcast<BuildListener>

            val fBroadcast = ListenerBroadcast::class.java.getDeclaredField("broadcast")
            fBroadcast.isAccessible = true
            val broadcast: BroadcastDispatch<BuildListener>? =
                    fBroadcast.get(buildListenerBroadcast) as? BroadcastDispatch<BuildListener>
            val fDispatchers = broadcast?.javaClass?.getDeclaredField("dispatchers")
            fDispatchers?.isAccessible = true
            val dispatchers: ArrayList<BroadcastDispatch<BuildListener>>? =
                    fDispatchers?.get(broadcast) as? ArrayList<BroadcastDispatch<BuildListener>>

            val clazz =
                    Class.forName("org.gradle.internal.event.BroadcastDispatch\$ActionInvocationHandler")
            val iterator = dispatchers?.iterator()
            iterator?.let {
                while (iterator.hasNext()) {
                    try {
                        val next = iterator.next()
                        val fDispatch = next.javaClass.getDeclaredField("dispatch")
                        fDispatch.isAccessible = true
                        val dispatch: Any? = fDispatch.get(next)
                        val fMethodName = clazz.getDeclaredField("methodName")
                        fMethodName.isAccessible = true
                        val methodName = fMethodName.get(dispatch) as? String
                        if (methodName?.contains("projectsEvaluated") == true) {
                            removeDispatch.add(next)
                            iterator.remove()
                        }
                    } catch (ignore: Exception) {
                    }
                }
            }
        } catch (ignore: Exception) {
        }
        return removeDispatch
    }

10. 至此完美解決修改依賴時機問題，更多詳情可查看 issue18

• 如何獲取每個module 的依賴，依賴就藏在 Configuration.dependencies，那么通過project.configurations.maybeCreate(configName) 找到所有的 Configuration 對象，就能得到每個module的 dependencies

4.5、 module 依賴關系 project 替換成 aar 技術方案

• 每一個 module 依賴關系替換的遍歷順序是無序的，所以技術方案需要支持無序的替換
• 目前使用的方案是：如果當前模塊 A 未改動，需要把 A 通過 localMaven 置換成 A.aar,并把 A.aar 以及 A 的 child 依賴，給到第一層的 parent module 即可。（可能會質疑如果 parent module 也是 aar 怎么辦，其實這塊也是沒有問題的，這里就不展開說了，篇幅太長）
• 為什么要給到 parent 不能直接給到 app ，下圖一個簡單的示例如果 B.aar 不給 A 模塊的話，A 使用 B 模塊的接口不見了，會導致編譯不過
  
  8b6e18135662895b9fae8e9940f3aed.png

• 給出整體項目替換的技術方案演示：

  
  
  RocketXPlugin (3).jpg

• 整體的實現在 DependenciesHelper.kt 這個類中，由于講起來篇幅太長，有興趣可查閱開源庫代碼

4.5、hook 編譯流程，完成后置換 loacal maven 中被修改的 aar

• 點擊三角形 run，執行的命令是 app:assembleDebug , 需要在 assembleDebug 后面補一個 uploadLocalMavenTask, 通過 finalizedBy 把我們的 task 運行起來去同步修改后的 aar ：

val localMavenTask = childProject.tasks.maybeCreate("uploadLocalMaven"+buildType.capitalize(),LocalMavenTask::class.java)
localMavenTask.localMaven = this@AarFlatLocalMaven
bundleTask?.finalizedBy(localMavenTask)

4.6、提供 AS 狀態欄 button，小火箭按鈕一個噴火一個沒有噴火，代表 enable/disable , 一個 掃把clean rockectx 的緩存，需要通過編寫 intellij idea plugin 即可，也就是 目前擁有兩個插件了，一個 gradle 插件一個 AS 插件:

image.png

五、一天一個小驚喜( bug 較多)

5.1、發現點擊 run 按鈕 ，執行的命令是 app:assembleDebug ，各個子 module 在 output 并沒有打包出 aar

解決：通過研究 gradle 源碼發現打包是由 bundle${Flavor}${BuildType}Aar 這個task執行出來，那么只需要將各個模塊對應的 task 找到并注入到 app:assembleDebug 之后運行即可：

        android.applicationVariants.forEach {
            getAppAssembleTask(ASSEMBLE + it.flavorName.capitalize() + it.buildType.name.capitalize())?.let { task ->
                    hookBundleAarTask(task, it.buildType.name)
                }
        }

5.2、發現運行起來后存在多個 jar 包重復問題

解決： implementation fileTree(dir: "libs", include: ["*.jar"]) jar 依賴不能交到 parent module，jar 包會打進 aar 中的lib 可直接剔除。通過以下代碼可以判斷：

// 這里的依賴是以下兩種： 無需添加在 parent ，因為 jar 包直接進入 自身的 aar 中的libs 文件夾
if (childDepency is DefaultSelfResolvingDependency && (childDepency.files is DefaultConfigurableFileCollection || childDepency.files is DefaultConfigurableFileTree)) {
// 這里的依賴是以下兩種： 無需添加在 parent ，因為 jar 包直接進入 自身的 aar 中的libs 文件夾
//    implementation rootProject.files("libs/tingyun-ea-agent-android-2.15.4.jar")
//    implementation fileTree(dir: "libs", include: ["*.jar"])
} else { 
    parentProject.key.dependencies.add(childConfig.name, childDepency)
}

5.3、發現 aar/jar 存在多種依賴方式

 implementation (name: 'libXXX', ext: 'aar') 
 implementation files("libXXX.aar")

解決：使用第一種，第二種會合并進aar,導致類重復問題

5.4、發現 aar 新姿勢依賴

configurations.maybeCreate("default")
artifacts.add("default", file('lib-xx.aar'))

上面代碼把 aar 做了一個單獨的 module 給到其他 module 依賴，default config 其實是 module 最終輸出 aar 的持有者，default config 可以持有一個 列表的aar ，所以把 aar 手動添加到 default config，也相當于當前 module 打包出來的產物。

解決：通過 childProject.configurations.maybeCreate("default").artifacts 找到所有添加進來的 aar ，單獨發布 localmaven

   fun getAarByArtifacts(childProject: Project): MutableList<String> {
        //找到當前所有通過 artifacts.add("default", file('xxx.aar')) 依賴進來的 aar
        var listArtifact = mutableListOf<DefaultPublishArtifact>()
        var aarList = mutableListOf<String>()
        childProject.configurations.maybeCreate("default").artifacts?.forEach {
            if (it is DefaultPublishArtifact && "aar".equals(it.type)) {
                listArtifact.add(it)
            }
        }

        //拷貝一份到 localMaven
        listArtifact.forEach {
            it.file.copyTo(File(FileUtil.getLocalMavenCacheDir(), it.file.name), true)
            //剔除后綴 （.aar）
            aarList.add(removeExtension(it.file.name))
        }

        return aarList
    }
    

5.5、發現 android module 打包出來可以是 jar

解決：通過找到名字叫做 jar 的task，并且在 jar task 后面注入 uploadLocalMaven task,代碼實現在 JarFlatLocalMaven.kt

5.6、發現 arouter 有 bug，transform 沒有通過 outputProvider.deleteAll() 清理舊的緩存

解決：詳情查看 issue，結果arouter 問題是解決了，代碼也是合并了。但并沒有發布新的插件版本到 mavenCentral，于是先自行幫 arouter 解決一下。然而arouter 并沒有啟動 增量編譯，導致 DexArchiveBuilderTask 運行巨慢，也就是打 dex 包很慢，項目中我重改了 arouter 插件源碼支持 TransForm 增量速度提升一倍, 具體細節就下節和 dex 速度優化一起講。

六、下一步展望

目前初步的版本已經能夠在在項目 run 起來，但是還是有很多小問題不斷的冒出并解決，路漫漫其修遠兮，吾將上下而求索。。

下步計劃：

• dexBuild task 優化
• 解決各種兼容性問題

目前插件趨于穩定，喜歡嘗鮮的朋友可以通過github教程接入，一起關注后期進展。后續 issue 的解決思路都會在本文不斷更新，如果你喜歡本文就給我們 star 吧。
github開源地址