开发者

Gradle 依赖切换源码实践示例详解

目录
  • 引言
  • 1、一般的修改办法
  • 2、通过 Gradle 脚本动态修改依赖
    • 2.1 配置文件和工作流程抽象
    • 2.2 为项目动态添加子工程
    • 2.3 使用子工程替换依赖
    • 2.4 注意事项
  • 总结

    引言

    最近,因为开发的时候经改动依赖的库,所以,我想对 Gradle 脚本做一个调整,用来动态地将依赖替换为源码。这里以 android-mvvm-and-architecture 这个工程为例。该工程以依赖的形式引用了我的另一个工程 AndroidUtils。在之前,当我需要对 AndroidUtils 这个工程源码进行调整时,一般来说有两种解决办法。

    1、一般的修改办法

    一种方式是,直接修改 AndroidUtils 这个项目的源码,然后将其发布到 MavenCentral. 等它在 MavenCentral 中生效之后,再将项目中的依赖替换为最新的依赖。这种方式可行,但是修改的周期太长。

    另外一种方式是,修改 Gradle 脚本,手动地将依赖替换为源码依赖。此时,需要做几处修改,

    修改 1,在 settings.gradle 里面将源码作为子工程添加到项目中,

    include ':utils-core', ':utils-ktx'
    project(':utils-core').projectDir = new File('../AndroidUtils/utils')
    project(':utils-ktx').projectDir = new File('../AndroidUtils/utils-ktx')
    

    修改 2,将依赖替换为工程引用,

    // implementation "com.github.Shouheng88:utils-core:$androidUtilsVersion"
    // implementation "com.github.Shouheng88:utils-ktx:$androidUtilsVersion"
    // 上面的依赖替换为下面的工程引用
    implementation project(":utils-core")
    implementation project(":utils-ktx")
    

    这种方式亦可行,只不过过于繁琐,需要手动修改 Gradle 的构建脚本。

    2、通过 Gradle 脚本动态修改依赖

    其实 Gradle 是支持动态修改项目中的依赖的。动态修改依赖在上述场景,特别是组件化的场景中非常有效。这里我参考了公司组件化的切换源码的实现方式,用了 90 行左右的代码就实现了上述需求。

    2.1 配置文件和工作流程抽象

    这种实现方式里比较重要的一环是对切换源码工作机制的抽象。这里我重新定义了一个 json 配置文件,

    [
      {
        "name": "AndroidUtils",
        "url": "git@github.com:Shouheng88/AndroidUtils.git",
        "branch": "feature-2.8.0",
        "group": "com.github.Shouheng88",
        "open": true,
        "children": [
          {
            "name": "utils-core",
            "path": "AndroidUtils/utils"
          },
          {
            "name": "utils-ktx",
            "path": "AndroidUtils/utils-ktx"
          }
        ]
      }
    ]
    

    它内部的参数的含义分别是,

    • name:工程的名称,对应于 Github 的项目名,用于寻找克隆到本地的代码源码
    • url:远程仓库的地址
    • branch:要启用的远程仓库的分支,这里我强制自动切换分支时的本地分支和远程分支同名
    • group:依赖的 group id
    • open:表示是否启用源码依赖
    • children.name:表示子工程的 module 名称,对应于依赖中的 artifact id
    • children.path:表示子工程对应的相对目录

    也就是说,

    • 一个工程下的多个子工程的 group id 必须相同
    • children.name 必须和依赖的 artifact id 相同

    上述配置文件的工作流程是,

    def sourceSwitches = new HashMap<String, SourceSwitch>()
    // Load sources configurations.
    parseSourcesConfiguration(sourceSwitches)
    // Checkout remote sources.
    checkoutRemoteSources(s编程客栈ourceSwitches)
    // Replace dependencies with sources.
    replaceDependenciesWithSources(sourceSwitches)
    
    • 首先,Gradle 在 setting 阶段解析上述配置文件
    • 然后,根据解析的结果,将打开源码的工程通过 project 的形式引用到项目中
    • 最后,根据上述配置文件,将项目中的依赖替换为工程引用

    2.2 为项目动态添加子工程

    如上所述,这里我们忽略掉 json 配置文件解析的环节,直接看拉取最新分支并将其作为子项目添加到项目中的逻辑。该部分代码实现如下,

    /** Checkout remote sources if necessary. */
    def checkoutRemoteSources(sourceSwitches) {
        def settings = getSettings()
        def rootAbsolutePath = settings.rootDir.absolutePath
        def sourcesRootPath = new File(rootAbsolutePath).parent
        def sourcesDirectory = new File(sourcesRootPath, "open_sources")
        if (!sourcesDirectory.exists()) sourcesDirectory.mkdirs()
        sourceSwitches.forEach { name, sourceSwitch ->
            if (sourceSwitch.open) {
                def sourceDirectory = new File(sourcesDirectory, name)
                if (!sourceDirectory.exists()) {
                    logd("clone start [$name] branch [${sourceSwitch.branch}]")
                    "git clone -b ${sourceSwitch.branch} ${sourceSwitch.url} ".execute(null, sourcesDirectory).waitFor()
                    logd("clone completed [$name] branch [${sourceSwitch.branch}]")
                } else {
                    def sb = new StringBuffer()
                    "git rev-parse --abbrev-ref HEAD ".execute(null, sourceDirectory).waitForProcessOutput(sb, System.err)
                    def currentBranch = sb.toString().trim()
                    if (currentBranch != sourceSwitch.branch) {
                        logd("checkout start current branch [${currentBranch}], checkout branch [${sourceSwitch.branch}]")
                        def out = new StringBuffer()
                        "git pull".execute(null, sourceDirectory).waitFor()
                        "git checkout -b ${sourceSwitch.b开发者_Js入门ranch} origin/${sourceSwitch.branch}"
                                .execute(null, sourceDirectory).waitForProcessOutput(out, System.err)
                        logd("checkout completed: ${out.toString().trim()}")
                    }
                }
                // After checkout sources, include them as subprojects.
                sourceSwitch.children.each { child ->
                    settings.include(":${child.name}")
                    settings.project(":${child.name}").projectDir = new File(sourcesDirectory, child.path)
                }
            }
        }
    }
    

    这里,我将子项目的源码克隆到 settings.gradle 文件的父目录下的 open_sources 目录下面。这里当该目录不存在的时候,我会先创建该目录。这里需要注意的是,我在组织项目目录的时候比较喜欢将项目的子工程放到和主工程一样的位置。所以,上述克隆方式可以保证克隆到的 open_sources 仍然在当前项目的工作目录下。

    Gradle 依赖切换源码实践示例详解

    然后,我对 sourceSwitches,也就是解析的 json 文件数据,进行遍历。这里会先判断指定的源码是否已经拉下来,如果存在的话就执行 checkout 操作,否则执行 clone 操作。这里在判断当前分支是否为目标分支的时候使用了 git rev-parse --abbrev-ref HEAD 这个 Git 指令。该指令用来获取当前仓库所处的分支。

    最后,将源码拉下来之后通过 Settingsinclude() 方法加载指定的子工程,并使用 Settingsproject() 方法指定该子工程的目录。这和我们在 settings.gradle 文件中添加子工程的方式是相同的,

    include ':utils-core', ':utils-ktx'
    project(':utils-core').projectDir = new File('../AndroidUtils/utils')
    project(':utils-ktx').projectDir = new File('../AndroidUtils/utils-ktx')
    

    2.3 使用子工程替换依赖

    动态替换工程依赖使用的是 Gradle 的 ResolutionStrategy 这个功能。也许你对诸如

    configurations.all {
      resolutionStrategy.force 'io.reactivex.rxJava2:rxjava:2.1.6'
    }
    

    这种写法并不陌生。这里的 forcedependencySubstitution 一样,都属于 ResolutionStrategy 提供的功能的一部分。只不过这里的区别是,我们需要对所有的子项目进行动态更改,因此需要等项目 loaded 完成之后才能执行。

    下面是依赖替换的实现逻辑,

    /** Replace dependencies with sources. */
    def replaceDependenciesWithSources(sourceSwitches) {
        def gradle = settings.gradle
        gradle.projectsLoaded {
            gradle.rootProject.subprojects {
                configurations.all {
                    resolutionStrategy.dependencySubstitution {
                        sourceSwitches.forEach { name, sourceSwitch ->
                            sourceSwitch.children.each { child ->
                                substitute module("${sourceSwitch.artifact}:${child.name}python") with project(":${child.name}")
                            }
                        }
                    }
                }
            }
     android   }
    }
    

    这里使用 Gradle 的 projectsLoaded 这个点进行 hook,将依赖替换为子工程。

    此外,也可以将子工程替换为依赖,比如,

    dependencySubstitution {
      substitute module('org.gradle:api') using project(':api')
      substitute project(':util') using module('org.gradle:util:3.0')
    }
    

    2.4 注意事项

    上述实现方式要求多个子工程的脚本尽可能一致。比如,在 AndroidUtils 的独立工程中,我通过 kotlin_version 这个变量指定 kotlin 的版本,但是在 android-mvvm-and-architecture 这个工程中使用的是 kotlinVersion. 所以,当切换了子工程的源码之后就会发现 kotlin_version 这个变量找不到了。因此,为了实现可以动态切换源码,是需要对 Gradle 脚本做一些调整的。

    编程客栈

    在我的实现方式中,我并没有将子工程的源码放到主工程的根目录下面,也就是将 open_sources 这个目录放到 appshell 这个目录下面。而是放到和 appshell 同一级别。

    Gradle 依赖切换源码实践示例详解

    这样做的原因是,实际开发过程中,通常我们会克隆很多仓库到 open_sources 这个目录下面(或者之前开发遗留下来的克隆仓库)。有些仓库虽然我们关闭了源码依赖,但是因为在 appshell 目录下面,依然会出现在 Android Studio 的工程目录里。而按照上述方式组织目录,我切换了哪个项目等源码,哪个项目的目录会被 Android Studio 加载。其他的因为不在 appshell 目录下面,所以会被 Android Studio 忽略。这种组织方式可以尽可能减少 Android Studio 加载的文本,提升 Android Studio 响应的速率。

    总结

    上述是开发过程中替换依赖为源码的“无痕”修改方式。不论在组件化还是非组件化需要开发中都是一种非常实用的开发技巧。按照上述开发开发方式,我www.devze.com们可以既能开发 android-mvvm-and-architecture 的时候随时随地打开 AndroidUtils 进行修改,亦可对 AndroidUtil 这个工程独立编译和开发。

    源代码参考 android-mvvm-and-architecture 项目(当前是 feature-3.0 分支)的 AppShell 下面的 sources.gradle 文件。

    以上就是Gradle 依赖切换源码实践示例详解的详细内容,更多关于Gradle 依赖切换的资料请关注我们其它相关文章!

    0

    上一篇:

    下一篇:

    精彩评论

    暂无评论...
    验证码 换一张
    取 消

    最新开发

    开发排行榜