作者:i校长
转载地址:https://juejin.cn/post/7120752268781027358
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包统计
7.5 - 1.2 ,多了6.3MB,再看安装完如下:
嘿,多了比之前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:
这时的心情:又可以自由的玩耍了,继续猥琐发育。
最后我准备了一些 Android 学习文档,可以有效的帮助大家掌握知识、理解原理。当然你也可以拿去查漏补缺,提升自身的竞争力。有需要的小伙伴可以点击这里查看获取方式 传送门直达 !!!里面记录许多Android 相关学习知识点。