Android统一依赖管理的三种方式总结

目录
  • 简述
  • 传统apply from的方式(也是我以前项目中使用)
  • buildSrc方式
    • 什么是buildSrc
    • 小结
  • Composing builds
    • 什么是Composing builds
    • 小结
  • Composing builds项目实战
    • 在项目中新建一个model,用于管理配置信息
    • 新建一个ConfigPlugin的类,不用具体的实现
    • 编辑configPluginmodel中的build.gradle文件
    • 修改根目录的settings.gradle文件
    • 项目目录引入插件
    • 在configPluginmodel中定义一个DependencyManager文件来管理一些第三方的依赖
    • 在使用目录导入
    • 需要注意的地方
  • 总结

简述

每个项目从新建开始我们或多或少都会导入各种依赖库,如果项目中只有一个module的话,对于依赖库版本的管理很容易,但是多个module的话,稍加不注意,很容易导入多个版本的库甚至产生版本冲突,更新修改依赖库也需要多处操作,所以我们需要对依赖库版本进行统一管理。

传统apply from的方式(也是我以前项目中使用)

为了对模块进行统一管理,会在根目录新建一个config.gradle文件或者在根目录的build.gradle定义一些变量

ext {
    android = [
            compileSdkVersion   : 29,
            buildToolsVersion   : "30.0.2",
            applicationId       : "com.xionggouba.bearseller",
            minSdkVersion       : 19,
            targetSdkVersion    : 30,
            versionCode         : 27,
            versionName         : "3.9.1",
            defaultPublishConfig: 'release',
            publishNonDefault   : true,
            multiDexEnabled     : true,
            mapKey              : 'c7e1ee468aa1bf8a6739',
            pushKey             : '65aae199a0059eb1dbe7',
            pushChannel         : 'developer-default',
    ]
    appid = [
            app           : "com.xionggouba.bearseller",
            login         : "com.huitao.login",
            home          : "com.huitao.home",
            webview       : "com.huitao.webview",
            main          : "com.huitao.main",
            productManager: "com.huitao.productmanager",
            personal      : "com.huitao.personalcenter",
            map           : "com.huitao.map",
            bluetooth     : "com.huitao.bluetooth",
            push          : "com.huitao.push",
            markketing    : "con.huitao.marketing",
            printer       : "com.huitao.printer"
    ]
    versions = [
            "lifecycle_version": "2.2.0",
            "arch_version"     : "2.1.0",
            "retrofit_version" : "2.6.2",
            "dialog_version"   : "3.3.0",
            "glide_version"    : "4.9.0",
            "hilt"             : "2.28-alpha",
            "kotlin_version"   : "1.4.10",
            "fragment_version" : "1.2.5",
            "room_version"     : "2.2.6"
    ]
    architecture = [
            "viewmodel"          : "androidx.lifecycle:lifecycle-viewmodel-ktx:${versions['lifecycle_version']}",
            "livedata"           : "androidx.lifecycle:lifecycle-livedata-ktx:${versions['lifecycle_version']}",
            "lifecycleruntime"   : "androidx.lifecycle:lifecycle-runtime-ktx:${versions['lifecycle_version']}",
            "savedstate"         : "androidx.lifecycle:lifecycle-viewmodel-savedstate:${versions['lifecycle_version']}",
            // alternately - if using Java8, use the following instead of lifecycle-compiler
            "lifecyclecommon"    : "androidx.lifecycle:lifecycle-common-java8:${versions['lifecycle_version']}",
            // Saved state module for ViewModel
            "viewmodelsavedstate": "androidx.lifecycle:lifecycle-viewmodel-savedstate:${versions['lifecycle_version']}",
            "lifecycleextentions": "androidx.lifecycle:lifecycle-extensions:${versions['lifecycle_version']}",
            "retrofit2"          : "com.squareup.retrofit2:retrofit:${versions['retrofit_version']}",
            "gson"               : "com.squareup.retrofit2:converter-gson:${versions['retrofit_version']}",
            "persistentcookiejar": "com.github.franmontiel:PersistentCookieJar:v1.0.1",
            "glide"              : "com.github.bumptech.glide:glide:${versions['glide_version']}",
            "glidecompiler"      : "com.github.bumptech.glide:compiler:${versions['glide_version']}",
            "oss"                : "com.aliyun.dpa:oss-android-sdk:2.9.1",
            "luban"              : "top.zibin:Luban:1.1.8"
    ]
]

在工程的根目录build.gradle添加

apply from"config.gradle"

找一个东西就得靠搜索,逐一查找。

buildSrc方式

什么是buildSrc

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

小结

buildSrc在近几年时非常流行的,因为它共享 buildSrc 库工件的引用,全局只有一个地方可以修改它,支持自动补全(这个很爽),支持跳转。 但是他也有一个缺点,依赖更新将重新构建整个项目,这个不是很好。

Composing builds

什么是Composing builds

复合构建只是包含其他构建的构建. 在许多方面,复合构建类似于 Gradle 多项目构建,不同之处在于,它包括完整的 builds ,而不是包含单个 projects

  • 组合通常独立开发的构建,例如,在应用程序使用的库中尝试错误修复时
  • 将大型的多项目构建分解为更小,更孤立的块,可以根据需要独立或一起工作

小结

这种方式拥有buildSrc的优点,同时依赖更新不用重新构建整个项目。

Composing builds项目实战

在项目中新建一个model,用于管理配置信息

新建一个ConfigPlugin的类,不用具体的实现

class ConfigPlugin: Plugin<Project> {
    override fun apply(p0: Project) {
    }

    companion object{
    }
}

编辑configPluginmodel中的build.gradle文件

我的文件大致内容如下

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        // 因为使用的 Kotlin 需要需要添加 Kotlin 插件
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.6.10"
    }
}

apply plugin: 'kotlin'
apply plugin: 'java-gradle-plugin'

repositories {
    // 需要添加 jcenter 否则会提示找不到 gradlePlugin
    jcenter()
    google()
}

dependencies {
    implementation gradleApi()
    implementation "org.jetbrains.kotlin:kotlin-gradle-plugin:1.6.10"
}

compileKotlin {
    kotlinOptions {
        jvmTarget = "1.8"
    }
}
compileTestKotlin {
    kotlinOptions {
        jvmTarget = "1.8"
    }
}

gradlePlugin {
    plugins {
        version {
            // 在 app 模块需要通过 id 引用这个插件
            id = 'com.umeshop.configplugin'
            // 实现这个插件的类的路径
            implementationClass = 'com.umeshop.configplugin.ConfigPlugin'
        }
    }
}

修改根目录的settings.gradle文件

项目目录引入插件

在configPluginmodel中定义一个DependencyManager文件来管理一些第三方的依赖

在使用目录导入

大致流程介绍完成

需要注意的地方

根目录的settings.gradle的配置

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
        jcenter() // Warning: this repository is going to shut down soon
    }
}
rootProject.name = "jetpackDemo"
include ':app'

有些版本是这样的,建议删除dependencyResolutionManagement的配置,在build.gradle中配置。大致是这样的

allprojects {
    repositories {
        google()
        mavenCentral()
        jcenter() // Warning: this repository is going to shut down soon
    }
}

还有一个就是依赖的修改

includeBuild("configPlugin")

是includeBuild标签,不是include

总结

到此这篇关于Android统一依赖管理的三种方式的文章就介绍到这了,更多相关Android统一依赖管理内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • AndroidStudio Gradle第三依赖统一管理的实现方法

    AndroidStudio由于使用了gradle的进行项目构建,使我们开发app方便很多,今天我就给大家列出几点是用gradle的方便之处. 一.AndroidStudio Gradle第三依赖统一管理 二.AndroidStudio Gradle基于友盟的多渠道打包 三.AndroidStudio安全管理签名文件keystroe和签名密码 这三篇文章很好的讲解了gradle的在打包和项目依赖管理的优点,大家可以参考一下,来提高自己的开发效率,增强签名文件的安全性. 在很多时候我们使用Andro

  • Android Gradle依赖管理、去除重复依赖、忽略的方式

    常用依赖 //1.直接依赖第三方开源库,一般是托管在 jitpack 或者 jcenter implementation 'com.google.code.gson:gson:2.2.4' implementation 'com.android.support:cardview-v7:25.0.0' implementation 'com.android.support:design:25.0.0' //2.直接依赖本地的aar文件,一般是在libs目录下 implementation(name

  • 详解Android使用Gradle统一配置依赖管理

    在介绍使用 Gradle 统一配置依赖管理前我们先来简单介绍一下 Gradle, Gradle 是一个基于 JVM 的构建工具,也是一款非常灵活强大的构建工具,支持  jcenter.maven.Ivy 仓库,支持传递性依赖管理(即 A 依赖 B,B 依赖 C,那么 A 也就可以依赖 C,不用再单独去依赖),而不需要远程仓库或者是 pom.xml 和 ivy.xml 配置文件,抛弃了各种繁琐,基于 Groovy,build 脚本使用 Groovy 编写 而在我们的 Android studio

  • Android统一依赖管理的三种方式总结

    目录 简述 传统apply from的方式(也是我以前项目中使用) buildSrc方式 什么是buildSrc 小结 Composing builds 什么是Composing builds 小结 Composing builds项目实战 在项目中新建一个model,用于管理配置信息 新建一个ConfigPlugin的类,不用具体的实现 编辑configPluginmodel中的build.gradle文件 修改根目录的settings.gradle文件 项目目录引入插件 在configPlu

  • 记录Android studio JNI开发的三种方式(推荐)

    概述 在Andorid Studio不支持JNI开发之前大家一般都是使用Eclipse开发JNI,各种配置让人觉得很蛋疼.从Andorid Studio支持JNI开发后,让我们开发JNI变的如此简单. NDK 和 JNI介绍 JNI (Java Native Interface)是一套编程接口,用来实现Java代码和其他语言(c.C++或汇编)进行交互.这里需要注意的是JNI是JAVA语言自己的特性,也就是说JNI和Android没有关系.在Windows下面用JAVA做开发也经常会用到JNI,

  • Android Flutter实现搜索的三种方式详解

    目录 示例 1 :使用搜索表单创建全屏模式 编码 示例 2:AppBar 内的搜索字段(最常见于娱乐应用程序) 编码 示例 3:搜索字段和 SliverAppBar 编码 结论 示例 1 :使用搜索表单创建全屏模式 我们要构建的小应用程序有一个应用程序栏,右侧有一个搜索按钮.按下此按钮时,将出现一个全屏模式对话框.它不会突然跳出来,而是带有淡入淡出动画和幻灯片动画(从上到下).在圆形搜索字段旁边,有一个取消按钮,可用于关闭模式.在搜索字段下方,我们会显示一些搜索历史记录(您可以添加其他内容,如建

  • 详解Spring依赖注入的三种方式以及优缺点

    目录 0.概述 1.属性注入 1.1 优点分析 1.2 缺点分析 2.Setter 注入 优缺点分析 3.构造方法注入 优点分析 总结 0.概述 在 Spring 中实现依赖注入的常见方式有以下 3 种: 属性注入(Field Injection): Setter 注入(Setter Injection): 构造方法注入(Constructor Injection). 它们的具体使用和优缺点分析如下. 1.属性注入 属性注入是我们最熟悉,也是日常开发中使用最多的一种注入方式,它的实现代码如下:

  • 详析Spring中依赖注入的三种方式

    前言 平常的java开发中,程序员在某个类中需要依赖其它类的方法,则通常是new一个依赖类再调用类实例的方法,这种开发存在的问题是new的类实例不好统一管理,spring提出了依赖注入的思想,即依赖类不由程序员实例化,而是通过spring容器帮我们new指定实例并且将实例注入到需要该对象的类中.依赖注入的另一种说法是"控制反转",通俗的理解是:平常我们new一个实例,这个实例的控制权是我们程序员,而控制反转是指new实例工作不由我们程序员来做而是交给spring容器来做. 在Sprin

  • Spring依赖注入的三种方式实例详解

    Spring依赖注入(DI)的三种方式,分别为: 1. 接口注入 2. Setter方法注入 3. 构造方法注入 下面介绍一下这三种依赖注入在Spring中是怎么样实现的. 首先我们需要以下几个类: 接口 Logic.java 接口实现类 LogicImpl.java 一个处理类 LoginAction.java 还有一个测试类 TestMain.java Logic.java如下: package com.spring.test.di; public interface Logic { pub

  • Android获取view高度的三种方式

    本文为大家分享了Android获取view高度的方法,供大家参考,具体内容如下 getMeasuredHeight()与getHeight的区别 实际上在当屏幕可以包裹内容的时候,他们的值相等, 只有当view超出屏幕后,才能看出他们的区别: getMeasuredHeight()是实际View的大小,与屏幕无关, 而getHeight的大小此时则是屏幕的大小. 当超出屏幕后,getMeasuredHeight()等于getHeight()加上屏幕之外没有显示的大小 具体方法 我们知道在oncr

  • Spring依赖注入的三种方式小结

    Spring的主要特性包括IOC和DI,其中DI是IOC的基础.在以前的Spring使用过程中大部分都是使用XML配置文件显式配置spring组件,导致大量的XML配置文件以及冗余的XML配置代码.阅读<Spring in Action>后总结Spring的DI功能的三种主要装配方式以及混合装配方式 根据注解自动装配 Spring中有非常丰富的注解,通过这些注解可以方便地配置Spring容器,使得Spring容器可以自动识别相关Bean并做自动注入装配. 使用注解 @Component注解:标

  • Android实现轮询的三种方式

    本文实例为大家分享了Android实现轮询的方式,供大家参考,具体内容如下 1.通过rxjava实现(代码中使用了Lambda表达式) private static final int PERIOD = 10 * 1000; private static final int DELAY = 100; private Disposable mDisposable; /** * 定时循环任务 */ private void timeLoop() { mDisposable = Observable.

  • 详解Android之解析XML文件三种方式(DOM,PULL,SAX)

    1.xml文件代码 <?xml version="1.0" encoding="UTF-8" ?> <%@ page language="java" contentType="text/xml; charset=UTF-8" pageEncoding="UTF-8"%> <%@ taglib uri="http://java.sun.com/jsp/jstl/core

随机推荐