Android SDK 开发——发布使用踩坑之路

时间:2023-02-08 15:00:41

Android SDK 开发——发布使用踩坑之路

前言

在 Android 开发过程中,有些功能是通用的,或者是多个业务方都需要使用的。

为了统一功能逻辑及避免重复开发,因此将该功能开发成一个 SDK 是相当有必要的。

背景

刚好最近自己遇到了类似需求,在开发完 SDK 之后,集成到项目或者提供给别人的时候遇到了一些坑,这里分享一下,以避免其他需要开发 SDK 的开发者们重复踩坑。

文章要说明的内容如下:

  1. 集成方式对比
  2. AAR 集成方式的一些坑
  3. 使用 maven publish 和 maven 将 SDK 推送到 maven 仓库的区别
  4. Tips
  5. 总结

集成方式对比

SDK 开发完成之后,需要提供一种集成方式让其他人可以使用。

集成方式这边认为大概有 3 种。

1. 提供 Module

这种集成方式把整个 SDK 的源码都提供给其他人。

优点:没有什么坑,只要自己测试没问题,别人一般可以直接使用。

缺点:后续如果有更新,需要全量给别人进行替换。

         而且项目里面如果同时引用多个Module,项目结构会增加很多代码文件。

         还有可能一不小心就更改了 SDK。

         因为源码可以直接修改,没有任何保护。

2. 提供 AAR 文件

这种集成方式是把 SDK 编译之后提供 AAR 文件给其他人。

优点:只有一个文件,不需要给到具体源码。

缺点:某种情况下有坑,下面会讲到。另外更新 SDK 不方便,每次更新需要用户进行 AAR 文件替换。

3. 推送到仓库(这里以 MAVEN 仓库为例)(推荐)

这种集成方式是把 SDK 编译之后的 AAR 文件推送到仓库,后续可以通过 implementation 或者 api(旧版本 Gradle 为 compile)引用。

优点:集成方便,跟第三方库集成类似,方便开发者。而且有版本管理。

缺点:maven publish 有个坑。见下文分析。

表格对比如下:

集成方式 优点 缺点
提供 Module 没有坑 维护麻烦,没有代码保护
提供 AAR 文件 只有一个文件 有坑,更新麻烦
推送到仓库 集成方便,版本管理 maven publish有个坑

AAR 集成方式的一些坑

一般 SDK 开发是封装一些功能方便调用,因此比较少在 Module 里面引入第三方库。这种情况下使用 AAR 集成是没有太大问题的。

然而,当你的 SDK 中引入第三方库,比如 Retorfit 之类的库时(不是直接引入 jar 包或者 aar 包),这个时候你使用 AAR 集成,运行到对应代码时会提示 java.lang.NoClassDefFoundError 错误。这个时候你

Android SDK 开发——发布使用踩坑之路

明明 Module 运行没问题,怎么 AAR 就报错了。

如果你尝试在项目里面将 SDK 用到的第三方库再引入一遍,就会发现程序没报错了。

因此我们可以得出结论:

AAR 不能传递第三方依赖

Android SDK 开发——发布使用踩坑之路

别慌,方法总比问题多。

我们可以通过将 SDK 推送到仓库的方式来解决这个问题。

推送仓库有很多,比如开源的 jcenter 之类的。

这边考虑有些 SDK 是给公司内部使用的,因此以 maven 为例进行讲解。

使用 maven publish 和 maven 将 SDK 推送到 maven 仓库的区别

maven publish 其实是 maven 的一个升级。

所以一般优先采用 maven publish。

这边项目已经使用了 maven publish 了,所以这边一开始也是使用 maven publish。

结果坑来了。

发现出现和 AAR 一样的错误,依赖不能传递。

Android SDK 开发——发布使用踩坑之路

这,赶紧看一眼 pom 文件(跟 AAR 同级目录),发现真的没有依赖。

查了一下网上资料。发现

https://discuss.gradle.org/t/using-the-maven-publish-plugin-no-dependencies-in-pom-xml/7599

有一个提问

Android SDK 开发——发布使用踩坑之路

Android SDK 开发——发布使用踩坑之路

当然应该有对应的处理方式,但是由于项目时间需求比较紧,不想花太多时间,因此暂时没有查找解决方式。

如果有朋友知道,可以留言,后续有空研究,有解决方法也会更新。

因此这里不展开讨论 maven publish 的集成方式。

最后查阅资料使用了 maven 的推送方式。

那么如何使用呢?

1.先使用本地仓库,确保没问题之后再使用远程的

在 Module 的 build.gradle 文件中添加如下代码:

apply plugin: 'maven' //指定使用 maven
uploadArchives {
repositories {
mavenDeployer {
pom.groupId = "com.maven.demo" //包名
pom.artifactId = "login" //SDK 功能,自定义一个即可
pom.version = "0.0.1" //版本号
repository(url: "file://localhost/Users/用户名/Library/Android/sdk/extras/android/m2repository/") //用户名替换为自己的机器名,本地地址
}
}
}

执行 uploadArchives 任务就可以上报了。

然后到上面 url 指定的目录或者通过浏览器打开可以看到上传的相关文件。

查看 pom 文件可以看到依赖都在上面。

2.使用远程仓库,对上面略做修改。

apply plugin: 'maven' //指定使用 maven
uploadArchives {
repositories {
mavenDeployer {
pom.groupId = "com.maven.demo" //包名
pom.artifactId = "login" //SDK 功能,自定义一个即可
pom.version = "0.0.1" //版本号
repository(url: "网址") {
authentication(userName: "用户名", password: "密码")
}
}
}
}

其中网址、用户名和密码记得分别替换。

别人需要使用时只需要在 Module 添加如下:

implementation 'com.maven.demo.login.0.01'

所以仓库的组成就是pom.groupId+pom.artifactId+pom.version

Tips:

1.SDK 开发可能遇到同一个版本比如 0.0.1 在发布之前经常需要修改的情况。

这个时候如果你把修改后的 SDK 推送到远程,可能本地项目用的还是旧的内容。

这种时候有两个处理方式。

第一个,更新版本号,修改依赖新版本。

第二个,执行下面命令,强制从远程拉取,不使用缓存。

./gradlew build --refresh-dependencies

2.使用远程仓库时,一般用户名和密码都不会直接推送到代码仓库,可能会放到构建机。

这个时候需要使用类似于 local.properties 的外部文件来存放。

这个时候有个坑需要提醒一下,就是在 local.properties 定义比如 maven_user_name=username,千万记得不要加双引号,否则会出现认证失败,出现下面提示:

Received status code 401 from server: Unauthorized

3.使用 maven 的形式如何指定是 debug 还是 release?

通过在 android 块里面添加

android {
defaultPublishConfig "release"
}

可以指定。

通过查看 Module 的 build/outputs/aar 可以看到 aar 包。

通过查看 Module 的 build/poms/pom-default.xml 可以看到本地 pom 文件。

4.有些开发者如果按照上面操作之后还是出现 java.lang.NoClassDefFoundError 错误,可以尝试下面操作:

修改

implementation 'com.maven.demo.login.0.01'

implementation 'com.maven.demo.login.0.01' {
transitive = true
}

总结

  1. SDK 开发完成之后发布给其他人使用最好放到远程仓库(比如 maven)
  2. 如果出现 SDK 引入的第三方库没有找到的错误,记得到仓库看下 pom 文件是否有对应依赖

关注公众号一起交流:

Android SDK 开发——发布使用踩坑之路