再见吧 buildSrc, 拥抱 Composing builds 提高 Android 编译速度

时间 2020-06-11

标签再见 buildsrc 拥抱 composing builds 提高 android 编译速度栏目 Android 繁體版

原文原文链接

前言

长期以来困扰咱们的一个问题就是构建速度，AndroidStudio 的构建速度严重影响 Android 开发者的工做效率，尤为是更新一个版本号，致使整个项目从新构建，在网络慢的状况下，这是没法忍受的。html

buildSrc 这种方式，在最近几年是很是流行的，由于它有如下优势：java

共享 buildSrc 库工件的引用，全局只有一个地方能够修改它
支持 AndroidStudio 自动补全

支持 AndroidStudio 单击跳转

有优势的同时也有缺点，来看一下 Gradle 文档android

A change in buildSrc causes the whole project to become out-of-date. Thus, when making small incremental changes, the --no-rebuild command-line option is often helpful to get faster feedback. Remember to run a full build regularly or at least when you’re done, though.git

buildSrc的更改会致使整个项目过期，所以，在进行小的增量更改时，-- --no-rebuild命令行选项一般有助于得到更快的反馈。不过，请记住要按期或至少在完成后运行完整版本。github

汇总一句话就是说，buildSrc 依赖更新将从新构建整个项目，那么有没有一种方法支持自动补全和单击跳转，有不用从新构建整个项目，Composing builds 就能够实现，接下来咱们来演示一下 buildSrc 和 Composing builds 它们的 build 的时间，相关代码我已经上传到 GitHub 了：ComposingBuilds-vs-buildSrc算法

经过这篇文章你将学习到如下内容，将在文末总结部分会给出相应的答案编程

什么是 buildSrc？
什么是 Composing builds？
如何使用 Composing builds 和 buildSrc
buildSrc 和 Composing builds 优点劣势对比？
Composing builds 编译速度怎么样？
buildSrc 如何迁移到 Composing builds？
管理 Gradle 依赖都有那几种方式？以及效率怎么样？

这篇文章涉及不少重要的知识点，请耐心读下去，我相信应该会给你们带来不少不同的东西。数组

Composing builds 和 buildSrc 对比

接下来咱们来演示一下 buildSrc 和 Composing builds 它们的优点劣势对比，在分析以前，先来了解一下基本概念性能优化

什么是 buildSrc

摘自 Gradle 文档：当运行 Gradle 时会检查项目中是否存在一个名为 buildSrc 的目录。而后 Gradle 会自动编译并测试这段代码，并将其放入构建脚本的类路径中, 对于多项目构建，只能有一个 buildSrc 目录，该目录必须位于根项目目录中, buildSrc 是 Gradle 项目根目录下的一个目录，它能够包含咱们的构建逻辑，与脚本插件相比，buildSrc 应该是首选，由于它更易于维护、重构和测试代码bash

什么是 Composing builds

摘自 Gradle 文档：复合构建只是包含其余构建的构建. 在许多方面，复合构建相似于 Gradle 多项目构建，不一样之处在于，它包括完整的 builds ，而不是包含单个 projects

组合一般独立开发的构建，例如，在应用程序使用的库中尝试错误修复时
将大型的多项目构建分解为更小，更孤立的块，能够根据须要独立或一块儿工做

buildSrc vs Composing builds

为了正确对比这两种方式，新建了两个空的项目分别是 Project-buildSrc 和 Project-ComposingBuild，这两个项目引用的依赖都是同样的，Project-buildSrc 包含 buildSrc，Project-ComposingBuild 包含 Composing builds。

Project-buildSrc 和 Project-ComposingBuild 它们的结构都差很少，接下来咱们来看一下，编译速度和使用上有什么不一样。

编译速度

Project-buildSrc 和 Project-ComposingBuild 这两个项目，它们的 androidx.appcompat:appcompat 的版本是 1.0.2，如今咱们从 1.0.2 升级到 1.1.0 来看一下它们 Build 的时间。

Project-buildSrc：修改了版本号 1.0.2 -> 1.1.0 从新 Build 用时 37s

Project-ComposingBuild：修改了版本号 1.0.2 -> 1.1.0 从新 Build 用时 8s

当修改了版本号，Project-buildSrc 项目 Build 的时间几乎是 Project-ComposingBuild 项目的 4.6 倍（ PS: 每一个人的环境不一样，时间上会有差别，可是 Project-buildSrc 的时间老是大于 Project-ComposingBuild ）

在更大的项目中，网络慢的状况下，这种差别会更加明显，几分钟的构建都是常事，在 buildSrc 中作微小的更改，可能须要花很长时间构建，等待团队其余成员在他们提取更改以后，都将致使项目从新构建，这个代价是很是昂贵的。

它们在使用上有什么不一样呢

Project-buildSrc

在项目根目录下新建一个名为 buildSrc 的文件夹( 名字必须是 buildSrc，由于运行 Gradle 时会检查项目中是否存在一个名为 buildSrc 的目录 )
在 buildSrc 文件夹里建立名为 build.gradle.kts 的文件，添加如下内容

plugins {
    `kotlin-dsl`
}
repositories{
    jcenter()
}
复制代码

在 buildSrc/src/main/java/包名/ 目录下新建 Deps.kt 文件，添加如下内容

object Versions {
    ......
     
    val appcompat = "1.1.0"

    ......
}

object Deps {
    ......
   
    val appcompat =  "androidx.appcompat:appcompat:${Versions.appcompat}"
    
    ......
}
复制代码

重启你的 Android Studio，项目里就会多出一个名为 buildSrc 的 module，实现上面演示的效果

Project-ComposingBuild

新建的 module 名称 versionPlugin
在 versionPlugin 文件夹下的 build.gradle 文件内，添加如下内容

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        // 由于使用的 Kotlin 须要须要添加 Kotlin 插件
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.72"
    }
}

apply plugin: 'kotlin'
apply plugin: 'java-gradle-plugin'
repositories {
    // 须要添加 jcenter 不然会提示找不到 gradlePlugin
    jcenter()
}

gradlePlugin {
    plugins {
        version {
            // 在 app 模块须要经过 id 引用这个插件
            id = 'com.hi.dhl.plugin'
            // 实现这个插件的类的路径
            implementationClass = 'com.hi.dhl.plugin.Deps'
        }
    }
}
复制代码

在 versionPlugin/src/main/java/包名/ 目录下新建 Deps.kt 文件，添加如下内容

class Deps : Plugin<Project> {
    override fun apply(project: Project) {
    }

    companion object {
        val appcompat = "androidx.appcompat:appcompat:1.1.0"
    }
}
复制代码

在 settings.gradle 文件内添加 includeBuild 'versionPlugin' 重启你的 Android Studio
在 app 模块 build.gradle 文件内首行添加如下内容，就能够实现上面演示的效果

plugins{
    // 这个 id 就是在 versionPlugin 文件夹下 build.gradle 文件内定义的 id
    id "com.hi.dhl.plugin"
}
复制代码

ps：plugins{} 须要放在 app 模块 build.gradle 文件内首行位置

Project-ComposingBuild 比 Project-buildSrc 多了两步操做须要在 settings.gradle 和 build.gradle 引入插件，二者在使用都是差很少的

如何快速使用 buildSrc

访问 ComposingBuilds-vs-buildSrc 拷贝 buildSrc 文件夹到你的项目的根目录
重启你的 Android Studio，项目里就会多出一个名为 buildSrc 的 module

如何快速使用 Composing builds

访问 ComposingBuilds-vs-buildSrc 拷贝 versionPlugin 文件夹到你的项目的根目录
按照上面的配置方式，分配在 settings.gradle 和 app 模块的 build.gradle 引用插件便可

总结

总共从如下几个方面对比了 Composing builds 和 buildSrc

目录结构：它们的基本目录结构是相同的，能够根据本身的项目进行不一样的扩展
编译速度：当修改了版本号，Project-buildSrc 项目 Build 的时间几乎是 Project-ComposingBuild 项目的 4.6 倍（ PS: 每一个人的环境不一样，时间上会有差别，可是 Project-buildSrc 的时间老是大于 Project-ComposingBuild ）
使用上的区别：Composing builds 比 buildSrc 多了两步操做须要在 settings.gradle 和 build.gradle 引入插件

Project-buildSrc 和 Project-ComposingBuild 相关代码已经上传到 GitHub 了：ComposingBuilds-vs-buildSrc

到目前为止大概管理 Gradle 依赖提供了 4 种不一样方法：

手动管理：在每一个 module 中定义插件依赖库，每次升级依赖库时都须要手动更改（不建议使用）
使用 ext 的方式管理插件依赖库：这是 Google 推荐管理依赖的方法 Android官方文档
Kotlin + buildSrc：自动补全和单击跳转，依赖更新时 将从新 构建整个项目
Composing builds：自动补全和单击跳转，依赖更新时 不会从新 构建整个项目

buildSrc 如何迁移到 Composing builds？

若是当前项目使用的是 buildSrc 方式，迁移到 Composing builds 很简单，须要将 buildSrc 内容拷贝的 Composing builds 中，而后删掉 buildSrc 文件夹就能够便可

参考文献

结语

致力于分享一系列 Android 系统源码、逆向分析、算法、翻译、Jetpack 源码相关的文章，能够关注我，若是你喜欢这篇文章欢迎 star，一块儿来学习，期待与你一块儿成长

文章列表

算法

因为 LeetCode 的题库庞大，每一个分类都能筛选出数百道题，因为每一个人的精力有限，不可能刷完全部题目，所以我按照经典类型题目去分类、和题目的难易程度去排序

数据结构：数组、栈、队列、字符串、链表、树……
算法：查找算法、搜索算法、位运算、排序、数学、……

每道题目都会用 Java 和 kotlin 去实现，而且每道题目都有解题思路，若是你同我同样喜欢算法、LeetCode，能够关注我 GitHub 上的 LeetCode 题解：Leetcode-Solutions-with-Java-And-Kotlin，一块儿来学习，期待与你一块儿成长

再见吧 buildSrc, 拥抱 Composing builds 提高 Android 编译速度

前言

Composing builds 和 buildSrc 对比

什么是 buildSrc

什么是 Composing builds

buildSrc vs Composing builds

编译速度

它们在使用上有什么不一样呢

总结

参考文献

结语

文章列表

算法

Android 10 源码系列

Android 应用系列

工具系列

逆向系列