如何对 Android 库进行依赖管理？
Android 开发人员为项目选择库的时候，考虑的因素不仅仅是功能、可用性、性能、文档丰富度和技术支持情况。他们还关心库的大小，以及要添加的方法数量。因为项目越大，依赖也越多，要把应用的方法数量控制在65k 以下，开发人员感觉很有压力。另外，对于非发行版项目而言，Proguard 使用起来效率太低，而且开发人员视 multidex 如瘟疫，避之唯恐不及。因此，编写库的作者必须特别注意项目的大小。
为了减少库的方法数量，最简单的途径就是不包含任何多余的依赖。因为你包含的所有依赖，都会被传递并添加至用户的项目里。举个例子，如果你只需要几个简单的工具方法，比如默默地关闭一个资源，那就没必要为此添加 Guava。自己编写方法，或者从一个现有的库中提取（但是务必做出说明）就可以了。用户肯定会感激你去除了多余的14k方法。
但是，这并不是说你不该使用外部库，而是你要做出明智的选择。比如，像 HTTP 客户端这样的库已经有了，你若再去重写一个，最终结果只能是浪费时间，倒不如用这些时间改进自己的库。
除了有选择地使用库以外，还有几个策略也可以帮助你保持库的精简。其中一个策略就是使用 provided scope（已提供范围）来声明依赖。 这是 gradle 中 Android build system（Android 构建系统）的一部分。与 compile scope（编译范围）不同，provided scope 仅在编译时包含依赖。这就意味着，用户在构建项目时，该依赖不会随着 APK 文件打包。如果想在运行时使用该依赖，用户需要在应用的 build.gradle 里显式声明。
注意： 还有一种与 provided scope 相反的机制叫 package scope（包范围）。这种依赖会随 APK 文件打包，但是在编译时不可用。
你可能还想在库中使用可选择性依赖。其中一个原因是，某些功能可能只有部分用户使用。例如 Retrofit 1.x，该库可以使用 REST 调用来响应，而不使用回调。那些想使用 RxJava 的用户可以添加之，而不想使用它的用户也可以不添加，以免加重负担。自从 Retrofit 使用 maven build system（maven 构建系统）以后，其配置稍有更改，但理念还是相似的。
在此笔者要提醒大家，如果你发现自己库中的某些功能只对少数用户有用，你应该认真考虑一下是否还要保留这些功能。关于这一点，后文中还会讲到。
在库里包含可选择性依赖的另一个原因，是Android 框架已经提供了一种解决方案，但是某个外部库提供的解决方案性能更好。如果用户本就依赖于该外部库，或者愿意增加方法数量以获得更好的性能，就可以添加可选择性依赖。
我最近看到的PlacesAutocompleteTextView库，就属于这种情况。该库使用的内部 HTTP 客户端，既可以是 OkHttpClient，也可以是 HttpURLConnection。通常，前者的性能更好，但是需要添加 OkHttp 作为依赖。 如果用户不想包含该依赖，可以自动从标准库回退到 HttpURLConnection。
为此，需要一个「resolver」 类以确定运行时要使用的依赖。 例如，以下的类就用于选择 HTTP 客户端：
public final class PlacesHttpClientResolver {
public static final PlacesHttpClient PLACES_HTTP_CLIENT;
static {
boolean hasOkHttp;
try {
Class.forName("com.squareup.okhttp.OkHttpClient");
hasOkHttp = true;
} catch (ClassNotFoundException e) {
hasOkHttp = false;
}
PlacesApiJsonParser parser = JsonParserResolver.JSON_PARSER;
PLACES_HTTP_CLIENT = hasOkHttp ? new OkHttpPlacesHttpClient(parser) : new HttpUrlConnectionMapsHttpClient(parser);
}
private PlacesHttpClientResolver() {
throw new RuntimeException("No Instances!");
}
}该类被加载时，会检查 OkHttpClient 的完全限定类名是否可用。如果抛出 ClassNotFoundException，我们就知道用户没有添加 OkHttp，于是回退到 HttpURLConnection。PlacesHttpClient 是包装以上两种实现方式的公共接口，因此在整个代码库中，这两种实现方式可以交换使用。JSON 解析也采用了同样的方法，Gson 可选择性地作为依赖包含在库中。
如果性能表现与库的大小之间的权衡系数很大，这个方法确实不错。但是，如果回退的实现方式比较困难（比如 JSON 解析就是这种情况），笔者建议你先使用外部库来节省时间，在后续的版本中再考虑添加回退实现。
笔者在前文中提到，你应该对库中包含的功能做出明智的选择。如果某个功能几乎所有用户都不需要，最好将其除去，而且这里也没有必要使用前面提到的第一种可选择性依赖。再次以 Retrofit 为例，在 2.x 版本 中，使用 REST 调用来响应这个功能，不再作为核心库的一部分提供给用户，而是移到一个单独的模块上，并作为 Retrofit 的 maven 构件发布 。
同样地，不同的响应转换器也被拆成了独立的依赖。例如，Retrofit 用户想要转换一个 JSON 响应，而且已经依赖于 Gson，他们可以在 build.gradle 文件中添加以下依赖：
dependencies {
compile 'com.squareup.retrofit:converter-gson:2.0.0-beta2'
}而那些使用其他 JSON 库（比如 Jackson）的用户，或者需要解析其他数据格式（比如 XML 或 protocol buffers）的用户，也可以采用这种方式添加自己需要的依赖，而且避免通用型依赖带来的额外负担。与此同时，核心库也不会被这些附加功能干扰，可以专注于需要解决的主要问题。
总而言之，如果你正在编写的库有意给 Android 开发人员使用，在设计时务必记住以上几个策略。库的大小，不应该只当做属性，而应该视为一种特性予以考虑，你的用户绝对会因此而感激你！
OneAPM Mobile Insight 以真实用户体验为度量标准进行 Crash 分析，监控网络请求及网络错误，提升用户留存。访问 OneAPM 官方网站感受更多应用性能优化体验，想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
原文地址：http://johnpetitto.com/android-lib-dependency-management/