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-compatandroid.media 兼容庫，包括 MediaBrowser 和 Mediasession。大小為 248k。

(5) support-fragmentfragment 的兼容庫，大小為 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) 也許這個拆分只是開始