2024年安卓最全编写 Android Library 的最佳实践，2024年最新百度 二面

最后

下面是辛苦给大家整理的学习路线

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

fun sayHello() {
//do something
}

这么一来编译器就会为你这个 Kotlin 方法（Kotlin function）单独生成一个静态可直接访问的 Java 方法（Java method），此时再回到 Java 类里面，你就可以直接 DemoPlatform.sayHello()了。

事实上这个方法 Google 自己也在用，如果你的项目在用 Kotlin，你可以尝试在代码树上右击 -> New -> Fragment -> Frgment(Blank)，让 Android Studio 自动为我们创建一个 Fragment。我们都知道一个规范的 Fragment 必须包含一个静态的 newInstance() 方法，来限制传进来的参数，可以看到 Android Studio 自动帮我们生成的这个方法上面，也有一个 @JvmStatic 注解。

@JvmStatic
fun newInstance(param1: String, param2: String) =
BlankFragment().apply {
arguments = Bundle().apply {
putString(ARG_PARAM1, param1)
putString(ARG_PARAM2, param2)
}
}

很多项目在迁移阶段肯定是 Java 与 Kotlin 混调的，而我们作为一个给别人用的 Android Library 就更不用说了，一个小小的注解可以省下接入者的一些学习成本，何乐而不为呢？

Proguard 混淆

自我混淆

如果你的库仅仅想供人使用，而并没有打算完全开源，请一定记得打开混淆。在打开之前。把需要完全暴露给调用者的方法或者属性打上@android.support.annotation.Keep注解就行，比如上面的 sayHello()方法，我希望把它暴露出去，那就变成了：

@Keep
@JvmStatic
fun sayHello() {
//do something
}

当然了，不仅仅是方法，只要是@Keep注解支持的范围都可以。如果你还不知道 @Keep注解是咋回事，兄弟你再不补课就真的要失业了。

而启用混淆的方法也很简单，在编译 release 版本的时候把混淆启用即可，就像这样：

release {
minifyEnabled true
proguardFiles getDefaultProguardFile(‘proguard-android.txt’), ‘proguard-rules.pro’
}

这样一来，调用者依赖了你的库之后，除了你自己暴露的方法或者类，一些内部实现就不那么容易找到了。

把自己的 ProGuard 配置文件打包进 aar

我们经常在一些开源库的主页介绍下面看到一段 Proguard 内容，目的是让调用者把他加到自己 app 模块的 Proguard 配置文件中去。其实 Android 的编译系统早就支持库模块包含自己的 ProGuard 配置文件了，如果你希望你自己库里的一些代码，在调用者编译时也不被混淆，可以在自己 library 的 proguard-rules.pro里定义好：

然后打开 library 的 build.gradle， 在 defaultConfig 闭包里调用 consumerProguardFiles() 方法：

defaultConfig {
minSdkVersion build_versions.min_sdk
targetSdkVersion build_versions.target_sdk

consumerProguardFiles ‘proguard-rules.pro’

…
}

加上之后我们可以编译一次 aar，打开看一下，会发现里面多了一个 proguard.txt文件，一旦你的库被依赖，Gradle 会把这个规则与 app 模块的 Proguard 配置文件 合并后一起运行混淆，这样一来引用你 library 的人就再也不用担心混淆配置的问题了，因为你已经完全帮他做好。

so 文件

CMake 直接编译 so 文件

联运 SDK 由于涉及支付业务，一些安全相关的工作势必要放到 C 层去执行。在最开始的时候我也考虑过直接编译好 so 文件，让接入方直接拷贝到 jni 目录下，事实上国内现在很多第三方库让别人接的时候都是这么做的，然而这个做法实在是太不酷了，接入方在操作过程中经常会遇到这几个问题：

1. so 名字是什么？
2. 拷到哪个目录下面？
3. build.gradle怎么配？
4. abi 怎么区分？

好的是，从 Android Studio 2.3 开始，CMake 已经被很好地集成了进来，我们可以在项目里直接添加 C/C++ 的代码，然后编译期间动态生成 so 文件。

关于项目里集成 C/C++ 编译的方法，网上已经有很多教程了，大家 Google 一下 Android Studio Cmake 就会有很多。当然我最推荐的还是官网教程。或者如果你跟我一样喜欢动手实践的话，可以新建一个干净的 Android Project，然后在向导里勾上 Include C++ Support，最后生成出来的工程就会包含一个简单的例子，学习起来非常容易。

extern “C” JNIEXPORT jstring JNICALL
Java_your_app_package_name_YourClass_stringFromJNI(
JNIEnv env,
jobject / this */) {
std::string hello = “Hello from C++”;
return env->NewStringUTF(hello.c_str());
}

class YourClass(private val context: Context) {
init {
System.loadLibrary(your-name-lib")
}
/**

• A native method that is implemented by the ‘native-lib’ native library,
• which is packaged with this application.
  */
  external fun stringFromJNI(): String //Kotlin 的 external 关键字 类似 Java 的 native 关键字
  }

尽量包含所有 abi，把选择权交给接入方

在联运 SDK 上线后的一个月，我们收到 cp 反馈接入了之后有奔溃，后来检查发现是 armeabi 下没有 so 文件导致的。这本没有什么问题。但是你没有办法保证接入方应用的 armeabi 文件里也是空的，一旦这里面有 so ，android 就会去这里面找；还有一种可能就是现在很多应用会设置 abiFilter 去过滤掉一些 abi，万一人家只想保留 armeabi，而你的 library 里面又没有，这两种情况都会导致 crash。然而：

ndk r16b 已经弃用了 armeabi ，r17c 直接移除了对 armeabi 的支持, 如果有生成 armeabi 的需求只能降低 ndk 版本。（感谢评论区 @我啥时候说啦jj整理指出）

所以为了确保兼容，我们必须在 library 的 build.gradle里手动声明自己需要编出哪几个 abi：

defaultConfig {
externalNativeBuild {
cmake {
cppFlags “”
abiFilters ‘arm64-v8a’, ‘armeabi’, ‘armeabi-v7a’, ‘x86’, ‘x86_64’
}
}
}

这么一来你的 library 编出来之后就会包含上面 5 种 abi，确保所有的新老机型起码都不会崩溃，如果你的接入方嫌你的 so 太多太大了，他自己可以在 app编译期间设置过滤，“反正我都有，你自己挑吧”。

Resource 资源

库内部资源的命名不要干扰接入方

相信大家平时开发过程中都有过类似的经历：一旦引入了一些第三方库，自己写代码的时候，想调用某个资源文件，一按提示，IDE 提示的全是这些第三方库里面的资源，而自己 app 里面的资源却要找半天。

我们平时写库的时候难免会自己定义一些 Resource 文件，包括string.xml xxx_layout.xml color.xml 等等，这些库生成的 R.java 一旦参与 app 的编译之后，是可以直接被引用到的，所以自然而言也会被 IDE 索引进提示里面。而照常来讲，一个应用是不应该直接引用一些第三方库里面的资源的，搞不好就很容易出现一些问题。比如万一哪天人家库升级把这串值改掉了，或者干脆拿掉了，你 app 就跪了。

联运 SDK 在开发的时候就注意到了这一点，比如我们的 SDK 叫 MeizuLibrarySdk，那么我在定义 strings.xml时，我会写：

你好
世界

再比如，我需要定义一个颜色，我会在 colors.xml里面写：

#8124F6

相信大家应该已经发现了，每一个资源都会以 mls 开头，这样有个好处，就是别人在引用了你的库之后，用代码提示的时候，只要看到 mls 开头的资源，就知道是你库里面的，不要用。但是这还不够，因为 Android Studio 还是会在人家写代码的时候把你的资源提示出来：

有没有一种办法，来让 library 开发者可以向 Android Studio 申明自己需要暴露哪些资源，而哪些不希望暴露呢？

当然是有的。我们可以在 library 的 res/values 下面建立一个 public.xml 文件：

这样依赖，如果你在 app 里面试图引用 mls_world，Android Studio 就会警告你引用了一个 private 资源。

这个方法的详细介绍可以看官方文档：

developer.android.com/studio/proj…

但是不知道为什么，这个方法我在15、16年的时候还是有效的。但是升级到 Android Studio 3.3 + Gradle Plugin 3.1.3 之后我发现 IDE 不会再警告了，也可以通过编译，不知道这又是什么坑。但官方文档依旧没有去掉关于这个用法的描述，估计是插件的一个 bug 吧。

第三方依赖库

JCenter() 能引用到的，不要打包进你自己里面

本着“不要重复造轮子”的原则，我们在开发第三方库的时候，自身难免也会依赖一些第三方库。比如用于解析 json 的 Gson，或者用于加载图片的 Picasso。这些库本身都是 jar 文件的，所以之前会有一些第三方库的作者在用到这些库的时候，把对应的 jar 下载到 libs 下面参与编译，最终编译到自己的jar或者aar里面。而接入者的项目原可能已经依赖了这些库，一旦再接入了你的，就会导致错误，提示 duplicated class was found。

这种做法与 Gradle 的依赖管理机制完全是背道而驰的。正确的原则应该是：

只要第三方应用自己能从 JCenter/MavenCentral 获取到的库，如果你的库也依赖了，请一概使用 compileOnly

举个例子，比如我的库里面需要发起网络请求，按照 Google 的推荐，目前最好用的库应该是 Retrofit 了，这个时候我应该在 library 的 build.gradle 里这样写：

compileOnly “com.squareup.retrofit2:retrofit:2.4.0”

compileOnly 标明后面的库只会在编译时有效，但不会你 library 的打包。这么一来，你只需要告诉你的引用者，让他们在自己 app 模块的 build.gradle 里加上引用即可，就像这样：

implementation “com.squareup.retrofit2:retrofit:$versions.retrofit”

这样做的好处是，如果引用者的项目本来就已经依赖了 Retrofit，那么皆大欢喜，什么都不用加，并且上面的 $versions.retrofit 意味着引用者可以自己决定他要用哪个版本的 Retrofit，一般来讲只要大于等于你编译库时用的版本都不会有太大问题，除非 Retrofit 自己大量修改了 API 导致编不过的那种。这么一来就再一次把选择权交给了你的引用者，既不用担心冲突，也不用担心版本跟你用的不匹配。

使用单个文件统一依赖库的版本

如果你的项目分了好多模块，结构比较复杂，我这边推荐大家使用一个 versions.gradle 文件来统一所有模块依赖库的版本。这一招并不是我原创的，而是 Google 在 architecture-components 的官方 demo 里体现的。这个 demo 的 Project 包含了大量的 module，有 library 有 app，而所有的 module 都需要统一版本的依赖库，拿 buildToolsVersion 为例，总不能不能你依赖 27.1.1，我依赖 28.0.0 这样。我把链接放在下面，推荐大家都去学习一下这个文件的写法，以及它是如何去统一所有 module 的。

github.com/googlesampl…

API 设计

关于 API 设计，由于大家的库所要实现的功能不一样，所以没有办法具体列举，但是依然在这里为大家分享一些注意点，其实这些注意点只要能站在接入者的角度去考虑，大多数都能想到，而问题就在于你在写库的时候愿不愿意去为你的接入者多考虑一点。

不要在人家的 Application 类里蹦迪

相信暴露一个 init() 方法让你的调用者在 Application 类里做初始化，是很多库作者喜欢干的事。然而大家反过来想一下，我们都看过很多性能优化的文章，通常第一篇都是让大家检查一下自己的 Application 类，有没有做太多耗时的操作？因为 Application 是你应用起来之后第一个要走的，如果你在里面做了耗时操作了，势必会推迟 Activity 的加载，然而这一点却很容易被大家忽略。所以如果你是一个库的作者，请：

1. 不要在你的 init() 方法里做任何耗时操作
2. 更不要提供一个 init() 方法，让人家放在 Application 类里，还让人家“最好建议异步”，这跟耍流氓没区别

统一入口，用一个平台类去包含所有的功能

这里的平台类是我自己取的名字，你可以叫 XXXManager、XXXProxy、XXXService、XXXPlatform都可以，把它设计成单例，或者把内部所有的方法写成静态方法。不要让你的调用者费劲心思去找应该实例化哪个类，反正所有的方法都在这一个类里面，拿到实例之后调用对应的方法即可。这样统一入口，既降低了维护成本，你的调用者也会感谢你。

所有的常量，定义到一个类

if (code == 10012) {
//do something
}

这个 10012 是什么？是你库里面定义的返回码？那为啥不写成常量暴露给你的调用者呢？

@Keep
class DemoResult private constructor(){

@Keep
companion object {
/**

• 支付失败，原因：无法连接网络，请检查网络设置
  */
  const val CODE_ERROR_CONFIG_ERROR: Int = 10012
  const val MSG_ERROR_CONFIG_ERROR: String = “配置错误，请检查参数”

…
}
}

这样一写，你的调用者只要点点鼠标，进来看一下你这个类，就能迅速把错误码跟错误提示对应上。懒一点的话，他们甚至可以直接用你定义的这些提示去展现给用户。而且万一有一天，服务端的同事告诉你，10012 需要变成别的值，此时你只需要修改你自己的代码就行，对库的接入者而言，它依然是 DemoResult.CODE_ERROR_CONFIG_ERROR ，不需要做任何修改，这样方便接入者的事何乐而不为呢？

文末

当你打算跳槽的时候，应该把“跳槽成功后，我能学到什么东西？对我的未来发展有什么好处”放在第一位。这些东西才是真正引导你的关键。在跳槽之前尽量“物尽其用”，把手头上的工作做好，最好是完成了某个项目或是得到提升之后再走。跳槽不是目的，而是为了达到最终职业目标的手段

最后祝大家工作升职加薪，面试拿到心仪Offer

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

链图片转存中…(img-H6ePhgcW-1715762446981)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！