Android Jetpack 辩论现场~

作者: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 相关学习知识点。

相关文章

Android性能优化——之控件的优化 前面讲了图像的优化,接下...
前言 上一篇已经讲了如何实现textView中粗字体效果,里面主要...
最近项目重构,涉及到了数据库和文件下载,发现GreenDao这个...
WebView加载页面的两种方式 一、加载网络页面 加载网络页面,...
给APP全局设置字体主要分为两个方面来介绍 一、给原生界面设...
前言 最近UI大牛出了一版新的效果图,按照IOS的效果做的,页...