preface

One of our perennial concerns is build speed. The build speed of AndroidStudio seriously affects the productivity of Android developers, especially when updating a version number causes the entire project to be rebuilt, which is intolerable on a slow network.

The buildSrc approach has become very popular in recent years because it has the following advantages:

  • A reference to the buildSrc library artifact is shared, and there is only one place to modify it globally
  • Support for AndroidStudio auto-completion

  • Support AndroidStudio click jump

There are advantages and disadvantages. Take a look at the Gradle documentation

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.

Changes to buildSrc can cause the entire project to become obsolete, so the — –no-rebuild command-line option usually helps get faster feedback when making small incremental changes. However, remember to run the full version on a regular basis or at least after completion.

In summary, buildSrc dependency updates will rebuild the entire project, so is there a way for auto-completion and one-click jumps to be implemented without rebuilding the entire project for Composing Builds? Next let’s demonstrate buildSrc and ComposingBuilds. I have uploaded the code for them to GitHub: ComposingBuilds- vS-buildSrc

You will learn the following in this article, which will be answered in the summary section at the end of the article

  • What is buildSrc?
  • What is Composing Builds?
  • How to use Composing Builds and buildSrc
  • BuildSrc versus Composing Builds: 1.42 gb
  • How about compiling speed?
  • How is buildSrc migrated to Composing Builds?
  • How many ways are there to manage Gradle dependencies? And how efficient?

This article involves a lot of important knowledge points, please read on patiently, I believe it should bring you a lot of different things.

Composing Builds versus buildSrc

Let’s explore some of the advantages and disadvantages of buildSrc and Composing Builds, while exploring some of the underlying concepts

What is a buildSrc

From the Gradle documentation: When running Gradle, it checks to see if a directory named buildSrc exists in the project. Gradle then automatically compiles and tests this code and places it in the classpath of the build script. For multi-project builds, there can only be one directory, buildSrc, which must be in the root project directory. BuildSrc is a directory in the root of the Gradle project. It can contain our build logic, and buildSrc should be preferred over script plug-ins because it is easier to maintain, refactor, and test code

What is Composing Builds

From the Gradle documentation: A composite build is just a build that contains other builds. In many ways, composite builds are similar to Gradle multi-project builds, except that they include full builds rather than individual projects

  • Combine builds that are typically developed independently, for example, when error fixes are attempted in a library used by an application
  • Break large multi-project builds into smaller, more isolated chunks that can work independently or together as needed

buildSrc vs Composing builds

To properly compare the two approaches, create two empty projects: project-buildSrc and project-ComposingBuild. The two projects reference the same dependencies: project-buildsrc contains buildSrc. Project-ComposingBuild includes Composing Builds.

Project-buildsrc and project-ComposingBuild are both similar in structure, so let’s take a look at the differences in build speed and usage.

Compilation speed

Project – buildSrc and Project – ComposingBuild the two projects, their androidx. Appcompat: appcompat version was 1.0.2, Now let’s take a look at the Build times from 1.0.2 to 1.1.0.

  • Project-buildsrc: modified version 1.0.2 -> 1.1.0 to Build again in 37s

  • Project-composingbuild: Modified version 1.0.2 -> 1.1.0 and rebuilt in 8s

When the version number is changed, the project-BuildSrc Project builds almost 4.6 times longer than the project-ComposingBuild Project (PS: The timing varies from person to person, but project-buildsrc is always longer than project-ComposingBuild.

In larger projects where the network is slow, this difference can be even more pronounced, where a few minutes of build time is common, making small changes in buildSrc that can take a long time to build, and waiting for the rest of the team to extract the changes can cause the project to be rebuilt, which can be very expensive.

How are they different in use

Project-buildSrc

  • Create a new folder at the root of your project called buildSrc (the name must be buildSrc because running Gradle checks to see if there is a directory called buildSrc in your project)
  • Create a file called build.gradle.kts in the buildSrc folder and add the following
plugins {
    `kotlin-dsl`
}
repositories{
    jcenter()
}
Copy the code
  • inBuildSrc/SRC/main/Java/package nameCreate a deps. kt file in the directory and add the following content
object Versions { ...... Val appCompat = "1.1.0"...... } object Deps { ...... val appcompat = "androidx.appcompat:appcompat:${Versions.appcompat}" ...... }Copy the code
  • Restart your Android Studio and you will have an extra module called buildSrc in your project that will do the same as shown above

Project-ComposingBuild

  • The name of the new Module is versionPlugin
  • In the build.gradle file in the versionPlugin folder, add the following
Buildscript {repositories {jCenter ()} dependencies {// Add the Kotlin plug-in classpath "Org. Jetbrains. Kotlin: kotlin - gradle - plugin: 1.3.72"}} the apply plugin: 'kotlin apply plugin: } gradlePlugin {plugins {version {'java-gradle-plugin' repositories {'java-gradle-plugin' repositories {'java-gradle-plugin' repositories {// // Insert into your app module and the implementationClass = 'com.hi.dhl. Plugin '}}}Copy the code
  • inVersionPlugin/SRC/main/Java/package nameCreate a deps. kt file in the directory and add the following content
class Deps : Plugin<Project> { override fun apply(project: Project) {} companion object {val appcompat = "androidx. Appcompat: appcompat: 1.1.0"}}Copy the code
  • Add it in settings.gradleincludeBuild 'versionPlugin'Restart your Android Studio
  • To achieve the effect shown above, add the following to the first line of the app module build.gradle file
Plugins {// this id is defined in the build.gradle file in the versionPlugin folder. Id "com.hi.dhl. Plugin "}Copy the code

Ps: Plugins {} should be placed in the first line of the app module build.gradle file

Project-composingbuild is two more steps than project-buildsrc. It requires plugins to be introduced in settings.gradle and build.gradle, both of which are used in the same way

How to use buildSrc quickly

  • Visit the ComposingBuiltes-vs-buildSrc folder and copy the buildSrc folder to the root directory of your project
  • Restart your Android Studio and you’ll have an extra module called buildSrc in your project

How to use Composing Builds quickly

  • Access the ComposingBuilds-vs-buildSrc and copy the versionPlugin folder to the root directory of your project
  • Gradle reference plugin is assigned to settings.gradle and app module as above

conclusion

In total, I have compared Composing Builds and buildSrc in the following aspects

  • Directory structure: The basic directory structure is the same and can be extended differently depending on your project
  • Build speed: A project-buildSrc Project builds 4.6 times faster than a project-ComposingBuild when the version number is changed (PS: The timing varies from person to person, but project-buildsrc is always longer than project-ComposingBuild.
  • Differences in use: Composing Builds is two more steps than buildSrc requiring the introduction of plugins in settings.gradle and build.gradle

The Project-buildSrc and Project-ComposingBuild code has been uploaded to GitHub: ComposingBuilds-vs-buildSrc

So far there are roughly four different ways to manage Gradle dependencies:

  • Manual management: Define plug-in dependencies in each module and manually change them each time you upgrade them (not recommended)
  • Manage plug-in dependency libraries the Ext way: This is Google’s recommended method for managing dependencies
  • Kotlin + buildSrc: Auto-complete and click jump, rebuilding the entire project when relying on updates
  • Composing Builds: Auto-complete and one-click jumps that rely on updates without rebuilding an entire project

How is buildSrc migrated to Composing Builds?

If your current project is using a buildSrc approach, migrating to Composing Builds is simple as copying the buildSrc content into Composing Builds and deleting the buildSrc folder

reference

  • Organizing Gradle Projects
  • Composing builds
  • The official Android document, which uses Ext to manage the plug-in dependency library

conclusion

Dedicated to sharing a series of Android system source code, reverse analysis, algorithm, translation, Jetpack source code related articles, can pay attention to me, if you like this article welcome star, to learn together, look forward to growing with you

We are planning to build a complete and up-to-date project of AndroidX Jetpack related components and related component theory analysis articles. So far, we have already included App Startup, Paging3, Hilt, etc. We are gradually adding other new Jetpack members, and the warehouse is continuously updated. Check it out: AndroidX-Jetpack-Practice, if this warehouse is helpful to you, please give me a like, I will finish more Jetpack new members project Practice.

algorithm

Due to the huge question bank of LeetCode, hundreds of questions can be screened for each category. Due to the limited energy of everyone, it is impossible to complete all the questions. Therefore, I classified the questions according to the classical types and sorted the questions according to their difficulty

  • Data structures: arrays, stacks, queues, strings, lists, trees…
  • Algorithms: search algorithms, search algorithms, bit operations, sorting, mathematics,…

Each problem is implemented in Java and Kotlin, and each problem has a solution idea. If you like algorithms and LeetCode as I do, you can follow my LeetCode problem on GitHub: Leetcode-solutions-with-java-and-kotlin, let’s learn And look forward to growing with you

Android 10 source code series

I am writing a series of Android 10 source code analysis articles. Understanding the system source code is not only helpful for analyzing problems, but also very helpful for us in the interview process. If you like studying Android source code like I do, Keep an eye on my GitHub android 10-Source-Analysis repository, where articles will be synced

  • Android 10 source code analysis: How is APK generated
  • 0xA02 Android 10 Source code Analysis: APK installation process
  • 0xA03 Android 10 Source code Analysis: APK load process resource loading
  • 0xA04 Android 10 source code Analysis: APK Load Process resource Load (2)
  • 0xA05 Android 10 source code analysis: Dialog load drawing process and use in Kotlin, DataBinding
  • 0xA06 Android 10 Source code Analysis: WindowManager View binding and architecture
  • More and more

Android Apps

  • How to obtain video screenshots efficiently
  • How to encapsulate Kotlin + Android Databinding in a project
  • Google engineers have just released a new feature for Fragments, “A new way to transfer data between Fragments” and source analysis
  • [2.4k Start] Drop Dagger Koin
  • [5K +] Kotlin performance optimization those things
  • How to use Koin and some source code analysis with FragmentFactory
  • Decrypt RxJava’s exception handling mechanism

Tool series

  • The few people who know about AndroidStudio shortcuts (1)
  • The few people who know about AndroidStudio shortcuts (part 2)
  • What you need to know about the ADB command
  • 10 minutes to get started with Shell scripting

The reverse series

  • Android Studio dynamically debugs the APP based on Smali files
  • The Android Device Monitor tool cannot be found in Android Studio 3.2