新世代バージョンの依存関係管理バージョンカタログの探索と実践

序文

少し前に、新しいバージョンの Android Studio を使用してプロジェクトを作成し、何かをテストしたいと思ったのですが、プロジェクトの作成後に、Gradle 全体の依存関係管理が大幅に変更されていることを知りました。
まず、私が使用している Android Studio のバージョンについて説明します。
ここに画像の説明を挿入
プロジェクト作成後の主な変更点は以下のとおりです。

元の .gradle は .gradle.kts になりました。これは、kts スクリプトが将来的には間違いなくメインのスクリプトになることを意味します。grovvy と比較すると、kts は使いやすく、言語が統一されており、プロンプトもあります。
AGP バージョンが 8+ にアップグレードされました
バージョンの依存関係は以下のようになります

依存関係の検出をクリックするとgradleディレクトリ内のlibs.versions.tomlファイルにジャンプします

この libs.version.toml は実際には Gradle の新バージョンで提供される依存関係管理メソッドです詳細は正式版のカタログドキュメントを参照してください

バージョンカタログが登場する前に、実際には Android で Gradle の依存関係を管理する方法がいくつかありました。

最も原始的な方法に直接依存するため、依存バージョンを維持するのが非常に面倒
extで依存情報を宣言し、extで宣言した変数を使って依存先の依存関係を管理することで、依存バージョンの統一の問題は一応解決しますが、やはりプロンプトなしで書くのは非常に面倒です。
依存関係の管理は、組み込みの buildSrc プラグインによって実行され、依存関係情報はプラグイン内のコードによって維持されます。依存関係を使用する場合は、パッケージをインポートすることで使用できます。これは、本質的には静的変数メソッドです。この方法は比較的フレンドリーです。依存関係を記述するときにプロンプトが表示され、コンパイル中に検証が実行されます。各変更は完全なコンパイルにつながるため、コンパイル速度に一定の影響を与えます。
Include build を使用すると、 buildSrc と同様に依存関係情報をコード内に保持できます。使用方法は buildSrc と似ていますが、コンパイル速度が速く、プロンプトやクリックジャンプなどの機能もあります。

以前の方法を使用していましたが、バージョンカタログが登場する前は長い間Includeビルド方法を使用していましたが、ルートディレクトリ内のプラグインのバージョン管理ができないという別の問題が解決できませんでした。図に示すように、たとえば、com.yzq.dependency-manager でルーターのバージョンを宣言しているため、ルーターのプラグインのバージョンを管理したいと考えています。
ここに画像の説明を挿入
ただし、buildSrc または Include build のいずれであっても、有効になるのはコンパイル期間中のみであり、そのライフサイクルもルートディレクトリ build.geadle の実行後であるため、プラグインに関連する構成を維持する方法はありません。。

Vesion Catalog はこの問題を解決します。

バージョンカタログの利用と公開

バージョンカタログの使い方は非常に簡単で、公式ドキュメントに詳しく紹介されているので、直接公式ドキュメントにアクセスすることをお勧めします。
なお、バージョンカタログを利用するにはGradleのバージョンが必要ですが、AGP8以上のバージョンで直接利用することを推奨しており、変な制限はありません。

使い方を簡単に見てみましょう

方法 1

versionCatalog と関連する構成情報を settings.gradle.kts で直接宣言するだけです

dependencyResolutionManagement {
    
    
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
    
    
        google()
        mavenCentral()
     
    }
    versionCatalogs {
    
    
    
        create("androidLibs") {
    
    
            /*声明版本号*/
            version("minSdk", "21")
            version("compileSdk", "33")
            version("targetSdk", "33")
            version("kotlin", "1.8.22")
            /**
             * 声明依赖库
             *  方式一：别名, 依赖库的具体坐标和版本
             *  方式二：别名, group，artifact，version
             */
            library("androidx-appcompat", "androidx.appcompat:appcompat:1.3.1")//方式一
            library("androidx-core-ktx", "androidx", "core:core-ktx").version("1.6.0")//方式二
            /*把依赖库打包 一起依赖*/
            bundle("androidx", listOf("androidx-appcompat", "androidx-core-ktx"))
            /*声明插件*/
            plugin("android-library", "com.android.library").version("8.0.2")
            plugin("kotlin-android", "org.jetbrains.kotlin.android").versionRef("kotlin")
        }


    }
}

次に、次のように使用します。

plugins {
    
    
//    id("com.android.library")
//    id("org.jetbrains.kotlin.android")
	/*依赖插件 等同于上面注释掉的代码*/
    alias(androidLibs.plugins.android.library)
    alias(androidLibs.plugins.kotlin.android)
}

android {
    
    
    namespace = "com.yzq.mylibrary2"
    compileSdk = androidLibs.versions.compileSdk.get().toInt()
}

dependencies {
    
    
    /*单独依赖*/
    implementation(androidLibs.androidx.core.ktx)
    implementation(androidLibs.androidx.appcompat)
    /*打包依赖*/
    implementation(androidLibs.bundles.androidx)
}

依存関係を追加するときにプロンプトが表示され、プラグインのバージョンも管理されます。

方法2

2 番目の方法は公式に推奨されている方法で、toml ファイルで依存関係を管理する方法です。これは、新しいプロジェクトを作成するときのデフォルトの方法です。デフォルトのファイルパスは、gradle フォルダー内にある記事の冒頭にも示されています。
ここに画像の説明を挿入

書き方に関しても非常に簡単なので、ここでは詳しく説明しません。

[versions] は宣言されたバージョンです
[libraries] は依存ライブラリを宣言します。
[plugins] はプラグインを宣言します。
[バンドル] はパッケージ化された依存関係であり、依存関係を簡素化するために使用されます。

例は次のとおりです。

[versions]
agp = "8.2.0-alpha10"
kotlin = "1.8.21"
core-ktx = "1.9.0"
junit = "4.13.2"
androidx-test-ext-junit = "1.1.5"
espresso-core = "3.5.1"
appcompat = "1.6.1"
material = "1.9.0"
constraintlayout = "2.1.4"
lifecycle-livedata-ktx = "2.6.1"
lifecycle-viewmodel-ktx = "2.6.1"
navigation-fragment-ktx = "2.6.0"
navigation-ui-ktx = "2.6.0"

[libraries]
core-ktx = {
    
     group = "androidx.core", name = "core-ktx", version.ref = "core-ktx" }
junit = {
    
     group = "junit", name = "junit", version.ref = "junit" }
androidx-test-ext-junit = {
    
     group = "androidx.test.ext", name = "junit", version.ref = "androidx-test-ext-junit" }
espresso-core = {
    
     group = "androidx.test.espresso", name = "espresso-core", version.ref = "espresso-core" }
appcompat = {
    
     group = "androidx.appcompat", name = "appcompat", version.ref = "appcompat" }
material = {
    
     group = "com.google.android.material", name = "material", version.ref = "material" }
constraintlayout = {
    
     group = "androidx.constraintlayout", name = "constraintlayout", version.ref = "constraintlayout" }
lifecycle-livedata-ktx = {
    
     group = "androidx.lifecycle", name = "lifecycle-livedata-ktx", version.ref = "lifecycle-livedata-ktx" }
lifecycle-viewmodel-ktx = {
    
     group = "androidx.lifecycle", name = "lifecycle-viewmodel-ktx", version.ref = "lifecycle-viewmodel-ktx" }
navigation-fragment-ktx = {
    
     group = "androidx.navigation", name = "navigation-fragment-ktx", version.ref = "navigation-fragment-ktx" }
navigation-ui-ktx = {
    
     group = "androidx.navigation", name = "navigation-ui-ktx", version.ref = "navigation-ui-ktx" }

[plugins]
androidApplication = {
    
     id = "com.android.application", version.ref = "agp" }
kotlinAndroid = {
    
     id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }

[bundles]
androidX = {
    
     modules = ["core-ktx", "appcompat", "material", "constraintlayout", "lifecycle-livedata-ktx", "lifecycle-viewmodel-ktx", "navigation-fragment-ktx", "navigation-ui-ktx"] }

使用方法は方法 1 とまったく同じです。デフォルトでは、settings.gradle.kts で何も設定する必要はありません。Gradle は、gradle ディレクトリに libs.versions.toml ファイルを自動的にロードします。デフォルト名も libs です。
もちろん、ファイル名やパスを変更したい場合は、変更後に依存関係を手動で設定するだけで問題ありません。

例えば

  versionCatalogs {
    
    
        create("libs") {
    
    
            from(files("version-catalog/libs.versions.toml"))
        }
    }

リモートに公開する

依存関係を共有する必要がない場合は、上記の方法で十分です。
しかし現在は基本的にコンポーネントベースの開発となっており、特にコンポーネントの数が比較的多い場合や社内に他のアプリがある場合には、依存関係のバージョンを統一し、依存関係を共有する必要が生じる可能性が高くなります。
その後、バージョンカタログをリモートエンドに公開することができ、コンポーネントや他のプロジェクトは必要に応じてバージョンカタログに直接依存して使用できるため、バージョンの統一と迅速な依存関係を実現するのに非常に便利です。結局のところ、コピーとコピーは非常に面倒でメンテナンスが困難です。

バージョンカタログのリリースも比較的簡単で、公式ドキュメントに従うだけです。
リリースが完了したら、リモート構成を直接利用できます。
例：

    versionCatalogs {
    
    
        create("libs") {
    
    
           from("com.xeonyu:version-catalog:0.0.2-SNAPSHOT")
        }
}

この時点で、共有バージョンディレクトリが実装されました。

Include Build と連携して構成を簡素化する

共有依存関係の問題を解決した後、以前に使用した Include Build と連携して、日常的な依存関係の構成を簡素化することもできます。
例えば、モジュールとしては、その構成は比較的固定されており、minSdk、targetSdk、紛らわしい構成、プラグイン構成などに過ぎず、各モジュールの構成は基本的に同じです。会社のコンポーネントの場合、コンポーネント (minSdk、targetSdk など) のバージョンがアプリのバージョンと一致することを望みます。その後、Include Build とバージョンカタログを組み合わせて実現できます。
ルーム、ルーターなどのサードパーティの依存関係もいくつかあります。それらの構成は固定されており、完全です。プラグインを作成することでそれらの構成を一元化できます。プロジェクトを使用する必要がある場合、1 行のコードで依存関係を修正できます。

例：

plugins {
    
    
    alias(libs.plugins.yzq.android.application)
    alias(libs.plugins.yzq.android.room)
}

プラグインの部分はあまり一般的ではなく、一般に自分のニーズに応じてコード化してカスタマイズする必要があります。そのため、ここでは主にいくつかのアイデアを提供し、議論を開始するために詳しく説明しません。
プラグインのリリースについては、
Publishing Gradle Plug-inドキュメントを参照してください。あとは、プラグインリリースを作成して適用するだけです。

要約する

全体として、バージョンカタログとインクルードビルドは、開発者がプロジェクト内の依存ライブラリとプラグインをより適切に管理および構成し、開発効率を向上させ、バージョンの一貫性を維持するのに役立ちます。同時に、バージョンカタログを公開し、Gradle プラグインを作成することで、依存関係の共有と集中管理を実現できます。

この記事が役立つと思われる場合は、高評価をお願いします。より多くの開発者を助けることができます。記事に間違いがある場合は、修正してください。転載する場合は、Yu Zhiqiang のブログからの転載であることを明記してください。ありがとう！_