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 中，所以依賴變成這樣：
compile ('com.android.support:appcompat-v7:24.2.0') {
exclude module: 'support-v4'
}
compile 'com.android.support:support-fragment:24.2.0'
上面介紹過現在 com.android.support:support-fragment 與 com.android.support:support-v4 已經幾乎無異，所以對於依賴 v7 的 App 來說這次的 v4 拆分不能帶來任何依賴包體積的精簡。
初步看來 data-binding 也依賴於 support-v4。
4. 好處
這樣看來 v4 包的拆分是否是 Google 的自娛自樂，對於開發者全無好處呢？我看並不是。
(1) 這個拆分本身對於 V4 包項目來說是好事
各模塊划清各自功能邊界，充分解耦。
(2) 也許這個拆分只是開始