这是首发在我维护的微信公众号 codeKK 上的文章，欢迎大家关注。

Google 昨天更新了最新的 Support Library 版本，其中最为显眼的功能莫过于 support-v4 大拆分，然后这个拆分现在看来并没有那么美好。

 

v4 包从 2011 年开始引入，包含 ViewPager、FragmentActivity 等我们常用的功能，目前已经达到 1.3 M，Google 此次升级将这个库拆分为 5 个子的 Module，每个 Module 可以被单独引用。

 

1. 子 Module 介绍

五个子 Module 分别为：
(1) support-compat
兼容一些 Framework API。如 Context.getDrawable() 和 View.performAccessibilityAction()。大小为 602k。

 

(2) support-core-utils
提供一系列核心的工具，如 AsyncTaskLoader 和 PermissionChecker。大小为 90k。

 

(3) support-core-ui
提供一系列核心的 UI，如 ViewPager、 NestedScrollView。大小为 240k。

 

(4) support-media-compat
android.media 兼容库，包括 MediaBrowser 和 MediaSession。大小为 248k。

 

(5) support-fragment
fragment 的兼容库，大小为 136k。

 

2. 子 Module 间依赖关系

PS：其中 support-annotations 为一些注解的声明库，如我们比较常用的 RequiresApi、UiThread、NonNull。大小为 21k。

 

从中可以看出 support-fragment 依赖于所有其他子 Module，而 support-v4 包含所有 Module，所以现在引入
compile 'com.android.support:support-fragment:24.2.0' 与
compile 'com.android.support:support-v4:24.2.0'
的效果是一样的。

 

3. 问题

support-v4 拆分的好处第一眼看来便是能减少应用大小，因为你不需要引用完整的 support-v4 包，只需要引用子的 Module 即可。

 

比如我只用了 AsyncTaskLoader，只需要引用 support-core-utils 即可，只有 90k 哎，比原来的 1.3M 降了一个数量级多，应用减少了 1M 多哎，然而真的这样吗？

 

(1) support-compat 过大
大家知道 AAR 的大小是不包含它的依赖大小的，所以 support-core-utils 90k 大小仅表示自己的代码和资源总大小。

 

从上面的依赖关系可以看出它们都依赖 support-compat，而 support-compat 有 602k，它依赖的 support-annotations 还有 21k，这样引用 support-core-utils 实际增大大小约为 700k+。

 

这样比 1.3M 还是少了一半，也不错，然而还没有结束。

 

(2) support-v4 触角太深
v4 包从 2011 年开始出来，由于 ViewPager、FragmentActivity 等类，v4 被大量其他包引用，早已子孙遍全球，比如 v7 兼容包 appcompat-v7 就依赖 v4。

 

我们可以尝试通过 exclude module 可以把 v7 中 v4 去掉，然并卵，v7 依赖 FragmentActivity 这个类，而 FragmentActivity 位于 v4 的 support-fragment 中，所以依赖变成这样：

上面介绍过现在 com.android.support:support-fragment 与 com.android.support:support-v4 已经几乎无异，所以对于依赖 v7 的 App 来说这次的 v4 拆分不能带来任何依赖包体积的精简。

 

初步看来 data-binding 也依赖于 support-v4。

 

4. 好处

这样看来 v4 包的拆分是否是 Google 的自娱自乐，对于开发者全无好处呢？我看并不是。

 

(1) 这个拆分本身对于 V4 包项目来说是好事
各模块划清各自功能边界，充分解耦。

 

(2) 也许这个拆分只是开始