发布 Android library 到 Maven 解析

前言

了解一下将 Android library 发布到中央仓库（比如 Maven Center,jitpack) 的过程中关于一些细节的疑惑。比如我们到底发布了啥？只有 xxx.aar 文件吗？代码中依赖的三方库又是怎么处理的？

疑惑

关于如何将一个功能完善的 Android Library 发布到 Maven Center 或者类似的中央仓库，已经是非常小儿科的东西了，网上有很多资料可以参考。

但是关于发布的内容，发布过程的一些细节，仍然有很多问题值得我们思考。

• 通过配置 publish 功能插件，执行发布任务之后，我们到底发布了啥？只有 aar 文件吗？
• 本地 library 依赖的三方库是怎么处理的？是编译到我们发布的包里了吗？
• 本地 library 依赖的三方库，dependencies 闭包下 libs 目录和直接 implementation 三方库最终会有什么差异吗？
• 资源文件是怎么处理的? assets 文件夹下的内容会发生什么？
• so 库文件呢，会发生什么？
• 代码的混淆配置怎么处理？library 下的 proguard-rules.pro 和 consumer-rules.pro 有啥用？

如果你对上面的这些内容了如指掌，那么下面的东西也就不用看了，可以直接叉掉了。

解惑

关于如何给 library 通过 gradle 进行发布相关的配置，相关的细节就不展开说了，可以参考的文章实在是太多了。

为了方便演示，本文直接使用本地仓库。当然你也可以通过 Nexux 搭建本地私服，有兴趣的同学可以参考 Android 使用maven publish插件发布产物(aar)流程实践。

这里将发布配置统一到一个 publish.gradle 文件当中.

发布配置

apply plugin: 'maven-publish'

def GROUP_ID = "com.engineer.third"
def ARTIFACT_ID = "thirdlib"
def VERSION = "1.0.0"

// 上传源码的 task 
task sourceJar(type: Jar) {
    from android.sourceSets.main.java.srcDirs
    arcHiveClassifier = "sources"
}

afterEvaluate {

    publishing {
        // 配置maven 仓库
        repositories { RepositoryHandler handler ->
            handler.mavenLocal()
            handler.maven {
                url "${rootDir}/local_repo/"
            }
        }
        publications { PublicationContainer publicationContainer ->
            debug(MavenPublication) {
                from components.debug 
                artifact sourceJar // 上传源码
                groupId = GROUP_ID
                artifactId = ARTIFACT_ID
                version = "${VERSION}_DEBUG"
            }
            release(MavenPublication) {
                from components.release
                artifact sourceJar // 上传源码
                groupId = GROUP_ID
                artifactId = ARTIFACT_ID
                version = VERSION
            }
        }
    }
}

为了方便，我们配置了 ${rootDir}/local_repo/ 作为本地仓库，本地仓库默认路径是 /Users/username/.m2/repository。其实，我们可以直接使用这个本地仓库，在 build.gradle 中添加 maven 地址就可以了。

allprojects {
    repositories {
        maven { url "${rootDir}/local_repo/" }
        Google()
        jcenter()
        mavenCentral()
    }
}

这样我们就可以在本地进行模拟发布和依赖 library 的功能。毕竟，仓库地址只是个地址而已。

这样在 library 依赖这个配置文件 apply from: file("publish.gradle") 后,我们便可以在 gradle task 中看到发布任务了。

发布内容

通过双击图中的 publish 任务或者是命令行执行 gradlew :thirdlib:publish 就可以开始执行发布任务，发布任务成功后我们就可以到 ${rootDir}/local_repo/ 查看一下到底有哪些产物。

有哪些内容

发布产物看着很多，但其实只有这么几类

• aar 文件
• module 文件
• pom 文件
• source.jar

其余都是这些文件的数字签名。

用 Android Studio 看一下 aar 的内容。

可以看到 library 源码中的 xxx.so 和 assets 目录下的文件会按照编译时的配置和内容，原封不动的打包到 aar 中。即便是没有使用到的内容。

aar 的内容就是我们的代码了，source.jar 是源代码，方便依赖 library 的时候进行查看。那么剩下的 module 文件和 pom 文件有什么作用呢？我们结合剩下的问题来解决这个疑问。

依赖的规则

关于依赖，一般有两种：

• 将 xxx.jar 或 xxx.aar 文件放到本地 libs 目录下，然后通过 implementation fileTree(include: ['*.jar','*.aar'], dir: 'libs') 进行依赖。
• 通过 implementation 'com.google.code.gson:gson:2.9.0' 这种直接声明中央仓库 group_id:artifact_id:version 的方式进行依赖。

这里的情况比较复杂，分开说明一下。首先看本地依赖直接依赖 libs 包的内容。

本地依赖

aar

直接从 libs 包依赖三方组件的时候，如果是 aar 包，那么为了编译生成 library 自己的 aar ,则只能用 compileOnly fileTree(include: ['*.aar'], dir: 'libs') 的方式。否则会报错：

Direct local .aar file dependencies are not supported when building
an AAR. The resulting AAR would be broken because the classes and 
Android resources from any local .aar file dependencies would not be
packaged in the resulting AAR.

至于为什么有这种限制官方的报错信息已经说明原因了。显而易见，本地依赖的 aar 包是无法打进最终产物的。 那么如果必须要用到这个 aar 该怎么办呢？两种办法，一是将 aar 发布到中央仓库，进行远程依赖；二是哪里缺这个 aar ,就在哪里直接进行本地依赖。

jar

jar 类型的文件要分情况：

• compilyOnly 依赖，那么不会输出到最终产物中。
• implementation 和 api 依赖，将在最终 aar 文件的 libs 目录下保留相应的依赖。

可以看到源码中 libs 目录下的两个 .jar 文件最终都输出到了 aar 文件中。这里需要注意的是，class.jar 中并没有包含 libs 目录下 jar 文件的 *.class 文件，只是一些配置文件。

中央仓库的依赖

这里首先需要明确一点是，只要是通过声明中央仓库 group_id:artifact_id:version 的方式进行依赖，那么所依赖的内容一定不会打包到最终的 aar 文件的。这么做是合理的，也是必须得，否则这 Android 的依赖管理将是一场噩梦。试想一下，如果所有依赖的东西，都可以打到一个包里，那如果发生冲突了，岂不是要解到天荒地老。

通过声明中央仓库 group_id:artifact_id:version 的方式进行依赖的内容，在编译时必然是需要的，那么依赖这个 library 的使用方，又该如何获取到这些依赖呢？这就要靠前面提到的 pom 文件了。

这里我们先比较一下，dependencies 各种配置一下，pom 文件的内容。

• api

dependencies {
    compileOnly fileTree(include: ['*.aar'], dir: 'libs')
    implementation fileTree(include: ['*.jar'], dir: 'libs')
    compileOnly 'com.squareup.radiography:radiography:2.4.1'
    implementation 'androidx.appcompat:appcompat:1.5.1'
    api 'com.google.android.material:material:1.6.1'
}

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="Http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- This module was also published with a richer model, Gradle metadata,  -->
  <!-- which should be used instead. Do not delete the following line which  -->
  <!-- is to indicate to Gradle or any Gradle module metadata file consumer  -->
  <!-- that they should prefer consuming it instead. -->
  <!-- do_not_remove: published-with-gradle-metadata -->
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.engineer.third</groupId>
  <artifactId>thirdlib</artifactId>
  <version>1.0.0</version>
  <packaging>aar</packaging>
  <dependencies>
    <dependency>
      <groupId>com.google.android.material</groupId>
      <artifactId>material</artifactId>
      <version>1.6.1</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.jetbrains.Kotlin</groupId>
      <artifactId>kotlin-stdlib-jdk8</artifactId>
      <version>1.6.10</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>androidx.appcompat</groupId>
      <artifactId>appcompat</artifactId>
      <version>1.5.1</version>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

看到 compile 这个在使用 Android Studio 2.x 版本时的常见的配置，是不是有种似曾相识的感觉。可以看到

• 本地依赖的配置不会出现在 pom 文件中
• compileOnly 依赖的内容，不会出现在 pom 文件中
• implementation 在 pom 文件中 scope 变成了 runtime
• api 在 pom 文件中 scope 变成了 compile

这些都是符合预期的。关于 pom 文件是什么以及 scope 的作用，这里就不解释了，网上有很多相关的科普，很容易理解的。

当我们在 gradle 中配置一个三方库依赖的时候，在 Android Studio 底部的信息栏你应该大概率看到过 download xxx.pom 文件的信息。gradle 就是通过这个 pom 文件的信息，明确当前依赖的 library 自身还依赖了那些内容，这就是所谓的依赖传递。

冲突

关于依赖，其实还有点其他内容。如果你是一个有追求的开发者，有代码洁癖。一定希望自己输出的东西越干净越好，使用者用起来越简单、问题越少越好。比如你声明的依赖和使用者声明的依赖冲突了怎么办？人家用的 glide 就是版本就是 3.x ，okhttp 版本就是 3.10.x ，而且还不能随意变动，你比人家高该怎么办？ 这时候对外输出的时候就要做好选择，到底是用 compileOnly 还是 api 。也可以使用 exclude 排除一些自身没有用到的内容，既可以排除可能造成冲突的依赖，又可以稍微加快一定编译速度，何乐而不为呢。

比如像下面这样：

    implementation("com.squareup.retrofit2:retrofit:2.9.0") {
        exclude group: "com.squareup.okhttp3", module: "okhttp"
        exclude module: "okio"
    }

本身只是使用 retrofit 进行了一些简单的封装，完全可以将 okhttp 相关的内容排除掉。尽可能避免给使用方带来冲突的可能性。

    <dependency>
      <groupId>com.squareup.retrofit2</groupId>
      <artifactId>retrofit</artifactId>
      <version>2.9.0</version>
      <scope>runtime</scope>
      <exclusions>
        <exclusion>
          <artifactId>okio</artifactId>
          <groupId>*</groupId>
        </exclusion>
        <exclusion>
          <artifactId>okhttp</artifactId>
          <groupId>com.squareup.okhttp3</groupId>
        </exclusion>
      </exclusions>
    </dependency>
  </dependencies>

可以看到，pom 文件会很自然的记录这种优化，使用方在依赖的时候，也会排除这些依赖，自然不会莫名其妙的引入一些意料之外又用不到的东西。

当然，这种冲突也不是致命的，使用者也可以自己配置 exclude 移除冲突的依赖项，或者是主动声明关闭依赖传递。

module 文件的作用暂时没理解出来，有知道的同学可以科普一下 ?囧

混淆配置

最后再说一下混淆配置。一般情况下，当我们新建一个 library 类型的 Android Module 时，会自动创建 proguard-rules.pro 和 consumer-rules.pro 这两个文件。为什么需要两个，各自有什么用呢？

其实也很简单，通俗来说：

• proguard-rules.pro 是 library 自己用的
• consumer-rules.pro 是给依赖这个 library 的使用者用的。

proguard-rules.pro 中配置当前 library 中那些内容需要混淆，那些内容需要保留。比如以 thridlib library 为例。

分别对这两个文件进行配置，这里简单起见，随便配置一下，主要是说明问题。

proguard-rules.pro

-keep class com.engineer.third.internal.NativeMethodsFactory {*;}

consumer-rules.pro

-keep class com.engineer.third.** {*;}

我们看一下打包输出的 aar：

可以看到 proguard-rules.pro 配置的内容对当前 library 生效了（当然这个配置完全可以不用写，Android 自带的 proguard 规则会 keep native 方法及类，这里只是举例）

这个就比较有意思了 consumer-rules.pro 的内容变成了 proguard.txt 。那么这个文件，又有什么用呢？这里就牵扯到另一个知识点了，Android 在输出 release apk 进行混淆的过程中，会收集每个依赖库中的混淆配置，合并到一起。生成一个最终的混淆配置文件，最终会基于这个文件进行混淆处理。这个总的混淆配置文件一般在 app/build/outputs/mapping/falvor/configuration.txt 中，其中就可以看到各个依赖库的混淆说明。

这就是 library 中混淆配置的用法。

小结

本文通过总结发布 library 和平时使用三方 library 时的一些疑问和困惑，就普通情况进行了相关的梳理。这样下次遇到相关问题时就有理可循了，不会再抓虾

到此这篇关于发布 Android library 到 Maven 解析的文章就介绍到这了,更多相关Android library  Maven内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网！