Is the latest Support V4 package big split of Android useful ?, Android Package Size

Is the latest Support V4 package big split of Android useful ?, Android Package Size

Google updated the latest Support Library version, the most prominent feature of which is the support-v4 big split, which now seems not so nice.

The v4 package was introduced in 2011, including ViewPager, FragmentActivity, and other common features. Currently, it has reached 1.3 MB. Google will split this library into five sub-modules in this upgrade, each Module can be referenced separately.

1. Introduction to sub-Module

The five sub-modules are:
(1) support-compat
Compatible with some Framework APIs. For example, Context. getDrawable () and View. javasmaccessibilityaction (). The size is 602 k.

(2) support-core-utils
Provides a series of core tools, such as AsyncTaskLoader and PermissionChecker. The size is 90 KB.

(3) support-core-ui
Provides a series of core UIS, such as ViewPager and NestedScrollView. The size is 240 k.

(4) support-media-compat
Android. media compatible library, including mediabrosion and MediaSession. The size is 248 k.

(5) support-fragment
The compatible database of fragment. The size is 136 KB.

2. dependencies between sub-modules

PS: the support-annotations are annotation declaration libraries, such as commonly used RequiresApi, UiThread, and NonNull. The size is 21 kb.

From this we can see that support-fragment depends on all other sub-modules, and the support-v4 contains all modules, so now we introduce
compile 'com.android.support:support-fragment:24.2.0'And
compile 'com.android.support:support-v4:24.2.0'
The effect is the same.

3. Problem

The benefit of support-v4 split first glance is to reduce the application size, because you don't need to reference the complete support-v4 package, just need to reference the sub Module.

For example, if I only use AsyncTaskLoader, I only need to reference support-core-utils. It is only 90 k, which is an order of magnitude lower than the original 1.3 M, and the application is reduced by more than 1 M, but is that true?

(1) support-compat is too large
As we all know, the size of AAR does not contain the dependent size. Therefore, the support-core-utils 90 k size only indicates the total size of your code and resources.

From the preceding dependency, we can see that all of them depend on support-compat, while support-compat has 602 k, and support-annotations depend on 21 k, in this way, the reference support-core-utils is actually increased by about 700 k +.

This is even better than 1.3 M, but it is not over yet.

(2) support-v4 tentacles too deep
V4 package from 2011, because of ViewPager, FragmentActivity and other classes, v4 is referenced by a large number of other packages, has been children all over the world, such as v7 compatible package appcompat-v7 depends on v4.

We can try to use the exclude module to remove v4 from v7. However, v7 depends on the FragmentActivity class, And FragmentActivity is located in the support-fragment of v4, so the dependency becomes like this:

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 and com. android. support: The support-v4 is almost the same, so this v4 split for apps dependent on v7 won't lead to any streamlined dependency package size.

Initially, data-binding also depends on support-v4.

4. Benefits

In this case, it seems that the splitting of the v4 package is Google's self-entertainment, which is not good for developers? I don't think so.

(1) This split is a good thing for the V4 package project.
Each module has its own functional boundaries and is fully decoupled.

(2) Maybe this split is just the beginning