Jetpack 一定好么
说别人不好时，要先给与肯定，所以先谈下它的优势
- 谷歌爸爸推出并维护
- 最佳实践
- 向后兼容
- 减少bug率
- 轻松实现MVVM架构
其实就第一条就足够打动很多人用了，但发展至今，对于国内的程序员而言，这些新的框架，既熟悉又陌生，就本人而言，我除了熟悉并使用过Lifecycle，AppCompat，Multidex之外，一概没用过，可能是因为我做业务少了的原因，即便我用的不多，但从组件的角度上讲，我还是有一些不满的，对于Jetpack不好的点，我总结如下：
- 框架复杂
- 易用性也就那样
- 库依赖树也很恐怖，每依赖一个库，就会带很多子库
- 学习成本高，有大佬专门卖Jetpack课程，可见学习成本之高
其实我最想知道的是，如果每个应用都依赖这些库，打包到自己的apk中，那岂不是存在大量的重复的代码？你是不是觉得这些无所谓呢？那我们就算下它的大小，来看看他到底占了我们多少的空间
Jetpack 有多大
所有的库都在这里：
developer.android.google.cn/jetpack/and…
我们只统计大家常用的库，来看看到底能有多大，两个纬度，一个是jar包大小，一个是apk大小，为什么这样区分呢？因为Android在打包过程中，会将jar包打包成Dex格式，而Dex对于jar包的合并是有一定的压缩的，jar和dex前后肯定是有区别的，所以分两个纬度来看，我们先来创建一个空项目，如下：
一行代码没有，什么都不引用，来看下项目大小
如何统计项目依赖的Jar包呢？
历经九九八十一难，我为你找到了合适的方法（兼容Gradle 7.0），如下：
它可以将项目中依赖的jar包及aar统统给你找出来，并乖乖的放到项目的build/output/libs 下。
task copyAllDependencies(type: Copy) { configurations.implementation.setCanBeResolved(true) configurations.api.setCanBeResolved(true) from project.configurations.implementation from project.configurations.api into "${buildDir}/output/libs" }
空项目-Jar包统计
脚本运行完后，如上，jar包总量 1.8MB
空项目-APK包统计
打完包1.2M，下面我们将Jetpack引入，且慢，突然想到，Apk只是用户下载时的感受，但其实它落盘后有多大呢？这才是占满你内存的元凶，安装后如下：
嘿，还变小了
Jetpack项目-Jar包统计
我们将常用的引入，如下：
implementation 'androidx.core:core-ktx:1.3.2' implementation 'androidx.appcompat:appcompat:1.4.1' implementation 'com.google.android.material:material:1.3.0' def fragment_version = "1.5.0" // Java language implementation implementation "androidx.fragment:fragment:$fragment_version" // Kotlin implementation "androidx.fragment:fragment-ktx:$fragment_version" def lifecycle_version = "2.5.0-rc02" def arch_version = "2.1.0" // ViewModel implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:$lifecycle_version" // ViewModel utilities for Compose implementation "androidx.lifecycle:lifecycle-viewmodel-compose:$lifecycle_version" // LiveData implementation "androidx.lifecycle:lifecycle-livedata-ktx:$lifecycle_version" // Saved state module for ViewModel implementation "androidx.lifecycle:lifecycle-viewmodel-savedstate:$lifecycle_version" def nav_version = "2.5.0" // Java language implementation implementation "androidx.navigation:navigation-fragment:$nav_version" implementation "androidx.navigation:navigation-ui:$nav_version" // Kotlin implementation "androidx.navigation:navigation-fragment-ktx:$nav_version" implementation "androidx.navigation:navigation-ui-ktx:$nav_version" def paging_version = "3.1.1" implementation "androidx.paging:paging-runtime:$paging_version" def room_version = "2.4.2" implementation "androidx.room:room-runtime:$room_version" annotationProcessor "androidx.room:room-compiler:$room_version" implementation "androidx.viewpager2:viewpager2:1.0.0" implementation "androidx.swiperefreshlayout:swiperefreshlayout:1.1.0" implementation "androidx.constraintlayout:constraintlayout:2.1.4" implementation "androidx.gridlayout:gridlayout:1.0.0" implementation "androidx.datastore:datastore-preferences:1.0.0" implementation "androidx.startup:startup-runtime:1.1.1" def work_version = "2.7.1" // (Java only) implementation "androidx.work:work-runtime:$work_version" // Kotlin + coroutines implementation "androidx.work:work-runtime-ktx:$work_version"
加这些不过分吧，大小如何，来揭晓
28 - 1.8 ，多了 26.2 MB，不恐怖么？
Jetpack项目-APK包统计
嘿，多了比之前20k左右
小结一下
| jetpack | jar包 | apk包安装前 | apk安装后 |
| 非Jetpack | 1.8 | 1.2 | 0.755 |
| 引入Jetpack | 28 | 7.5 | 7.52 |
| 差值 | 26.2 | 6.3 | 6.765 |
通过如上统计，我们假设一种场景，你的应用安装100款这样的应用，再假如Android不转Dex，直接打包运行Jar包，则需要2620/1024≈2.56G，这也是Dex的优势，而转Dex后安装后，则需要676.5M，对于现在的手机而言，真的是小牛一毛，不值一提，所以我的担心是多余的，但如果再算上三方库呢？好吧，我不挣扎了，你们赢了。其实通过这件事我只想表明一个观点，那就是jetpack随着时间的推移越来越大，对我的感觉它就像 Framework的升级版，那为什么不在将来合并到Framework中呢，这样岂不是两全其美呢，一来每个应用的包可以在下载时就减少几M，安装时又可以少几M，这样不好么？有的人说了，如果合入Framework中，咋用新版本呢？岂不是又造成了另一种困扰呢？其实不用担心，因为你现在用的Framework，不就有很多基于Framework封装开源的库么，其实就是提供基于Framework版本的增量版本就行了，然后在不久的将来再合并到Framework中。但由于这样做的成本大于收益，所以谷歌爸爸选择不作为。
宣判
法官：
Jetpack由于对手机的伤害不足以构成犯罪，现无罪当场释放。
Jetpack：
这时的心情：又可以自由的玩耍了，继续猥琐发育。
