prefacio
Hace algún tiempo, utilicé una nueva versión de Android Studio para crear un proyecto y quería probar algo.Después de que se creó el proyecto, descubrí que la gestión de dependencias de todo Gradle ha sufrido cambios tremendos.
Permítanme hablar primero sobre la versión de Android Studio que uso de la siguiente manera.
Los principales cambios después de crear el proyecto son los siguientes:
- El .gradle original se ha convertido en .gradle.kts, lo que significa que el script kts definitivamente será el script principal en el futuro. En comparación con grovvy, kts es más cómodo de usar, el idioma está unificado y hay indicaciones.
- Versión AGP actualizada a 8+
- La dependencia de la versión se convierte en la siguiente:
al hacer clic en el descubrimiento de dependencia, se saltará allibs.versions.tomlarchivo en el directorio gradle
Este libs.version.toml es en realidad un método de gestión de dependencias proporcionado por la nueva versión de Gradle. Para obtener más información, consulte el documento del catálogo de la versión oficial.
Antes del catálogo de versiones, en realidad hay varias formas de administrar las dependencias de Gradle en Android
- Depende directamente de la forma más primitiva, es muy problemático mantener la versión dependiente
- Declare la información dependiente en ext, y luego use las variables declaradas en ext para administrar las dependencias en el lugar dependiente , lo que inicialmente resuelve el problema de unificar las versiones dependientes, pero aún es muy problemático escribir sin preguntar
- La administración de dependencias se realiza a través del complemento buildSrc incorporado , y la información de dependencia se mantiene a través del código dentro del complemento. Cuando se usan dependencias, se pueden usar mediante la importación de paquetes, que es esencialmente un método de variable estática. Este método es relativamente amigable. Hay avisos cuando se escriben dependencias, y la verificación se realizará durante la compilación. Dado que cada cambio conducirá a la compilación completa, tendrá un cierto impacto en la velocidad de compilación.
- Al usar Incluir compilación , puede mantener la información de dependencia en el código como compilarSrc.Es similar a compilarSrc cuando se usa, pero la velocidad de compilación es más rápida y también hay funciones como avisos y saltos de clic.
He usado los métodos anteriores, antes de que saliera el catálogo de versiones, usé el método de compilación Incluir durante mucho tiempo, pero hay otro problema que no se puede resolver, es decir, no se puede administrar la versión del complemento en el directorio raíz. ., como se muestra en la figura, por ejemplo, quiero administrar la versión del complemento del enrutador, porque he declarado su versión en com.yzq.dependency-manager.
Sin embargo, ya sea buildSrc o include build, solo tiene efecto durante el período de compilación, y su ciclo de vida también es posterior a la ejecución del directorio raíz build.geadle, por lo que no hay forma de mantener la configuración relacionada con el complemento. .
El Catálogo Vesion resuelve este problema.
Uso y publicación del Catálogo Vesion
El uso del Catálogo de Versiones es muy sencillo, y la documentación oficial lo ha presentado con gran detalle, se recomienda ir directamente a la documentación oficial .
Cabe señalar que para utilizar el Catálogo de versiones se requiere la versión de Gradle, se recomienda utilizarlo directamente sobre la versión superior a AGP8, y no existen restricciones extrañas.
He aquí un vistazo rápido a cómo usarlo
método uno
Simplemente declare versionCatalogs y la información de configuración relacionada directamente en 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")
}
}
}
Luego úsalo de la siguiente manera:
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)
}
Hay un mensaje cuando se agregan dependencias y también se administra la versión del complemento.
forma dos
El segundo método es el recomendado oficialmente, que consiste en administrar las dependencias en el archivo toml. Este es el método predeterminado al crear un nuevo proyecto. La ruta del archivo predeterminado también se proporciona al principio del artículo, que se encuentra en la carpeta gradle.
En cuanto al método de escritura, también es muy simple, por lo que no entraré en detalles aquí.
- [versiones] es la versión declarada
- [bibliotecas] es declarar bibliotecas dependientes
- [complementos] es declarar el complemento
- [bundles] son dependencias empaquetadas, utilizadas para simplificar las dependencias
Los ejemplos son los siguientes:
[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"] }
El uso es exactamente el mismo que el método 1. Por defecto, no necesitamos configurar nada en settings.gradle.kts. Gradle cargará automáticamente el archivo libs.versions.toml en el directorio de gradle, y el nombre predeterminado también es libs.
Por supuesto, si desea cambiar el nombre del archivo o la ruta, no hay ningún problema, simplemente configure manualmente las dependencias después del cambio.
Por ejemplo
versionCatalogs {
create("libs") {
from(files("version-catalog/libs.versions.toml"))
}
}
publicar en remoto
Si no necesita compartir dependencias, entonces el método anterior es suficiente.
Pero ahora es básicamente un desarrollo basado en componentes, especialmente cuando la cantidad de componentes es relativamente grande o hay otras aplicaciones en la empresa, existe una alta probabilidad de que se necesiten versiones de dependencia unificadas y dependencias compartidas.
Luego podemos publicar el Catálogo de versiones en el extremo remoto, y los componentes u otros proyectos pueden depender directamente de él y usarlo cuando sea necesario, por lo que es muy conveniente realizar la unificación de versiones y la dependencia rápida. Después de todo, copiar y copiar es muy problemático y difícil de mantener.
El lanzamiento de Version Catalog también es relativamente simple, solo siga la documentación oficial .
Una vez completada la versión, puede confiar directamente en la configuración remota.
Ejemplo:
versionCatalogs {
create("libs") {
from("com.xeonyu:version-catalog:0.0.2-SNAPSHOT")
}
}
En este punto, hemos implementado el directorio de versiones compartidas.
Coopere con Incluir compilación para simplificar la configuración
Después de resolver el problema de las dependencias compartidas, también podemos cooperar con el Incluir compilación utilizado anteriormente para simplificar la configuración de dependencia diaria.
Por ejemplo, como módulo, su configuración es relativamente fija, nada más que minSdk, targetSdk, configuración confusa, configuración de plug-in, etc., y la configuración de cada módulo es básicamente la misma. componente de la empresa, esperamos que la versión del componente (como minSdk, targetSdk, etc.) pueda ser consistente con la versión de la aplicación, luego podemos combinar Incluir compilación con el catálogo de versiones para lograrlo.
También hay algunas dependencias de tres partes, como la habitación, el enrutador, etc. Sus configuraciones son fijas y completas. Podemos centralizar sus configuraciones escribiendo complementos. Cuando se necesita usar el proyecto, una línea de código puede arreglar las dependencias. .
Ejemplo:
plugins {
alias(libs.plugins.yzq.android.application)
alias(libs.plugins.yzq.android.room)
}
La parte del complemento no es muy general y, por lo general, debe codificarse y personalizarse de acuerdo con las necesidades de cada uno, por lo que no seré extenso aquí, principalmente para brindar algunas ideas y comenzar una discusión.
Para el lanzamiento del complemento, consulte
el documento Publicación del complemento de Gradle , y el resto es escribir el lanzamiento del complemento y aplicarlo.
Resumir
En general, el Catálogo de versiones e Incluir compilación pueden ayudar a los desarrolladores a administrar y configurar mejor las bibliotecas dependientes y los complementos en los proyectos, mejorar la eficiencia del desarrollo y mantener la consistencia de la versión. Al mismo tiempo, al publicar el Catálogo de versiones y escribir complementos de Gradle, se puede realizar el uso compartido y la administración centralizada de las dependencias.
Si crees que este artículo es útil para ti, por favor dale me gusta. Puede ayudar a más desarrolladores. Si hay algún error en el artículo, corrígeme. Para volver a imprimir, indica que estás reenviando desde el blog de Yu Zhiqiang, ¡ gracias !