Android Jetpack no tribunal

Jetpack deve ser bom

Quando você diz que os outros não são bons, você deve primeiro dar uma afirmação, então vamos falar sobre suas vantagens primeiro

Lançado e mantido pelo Google Daddy
Melhores Práticas
compatibilidade com versões anteriores
Reduza a taxa de bugs
Implemente facilmente a arquitetura MVVM

Na verdade, o primeiro artigo é suficiente para impressionar muitas pessoas, mas desde o desenvolvimento, esses novos frameworks são familiares e desconhecidos para programadores domésticos. No que me diz respeito, além de estar familiarizado e usar Lifecycle, AppCompat, Other than Multidex, nunca usei. Pode ser porque tenho menos negócios. Mesmo que não use muito, ainda tenho alguma insatisfação do ponto de vista dos componentes. Não sou bom em Jetpack. Resumido da seguinte forma:

estrutura complexa
Facilidade de uso também
A árvore de dependências de bibliotecas também é assustadora, toda vez que você depender de uma biblioteca, ela trará muitas sub-bibliotecas.
O custo do aprendizado é alto, existem caras grandes que se especializam em vender cursos Jetpack, pode-se ver que o custo do aprendizado é alto.

Na verdade, o que eu mais quero saber é que se cada aplicativo dependesse dessas bibliotecas e fosse empacotado em seu próprio apk, não haveria muito código duplicado? Você não acha que isso não importa? Então vamos calcular seu tamanho e ver quanto espaço ele ocupa para nós

Qual o tamanho do Jetpack

Todas as bibliotecas estão aqui:

developer.android.google.cn/jetpack/and…

Nós apenas contamos as bibliotecas comumente usadas para ver o quão grande elas podem ser.Existem duas dimensões, uma é o tamanho do pacote jar e a outra é o tamanho do apk. Como o Android empacotará o pacote jar no formato Dex durante o processo de empacotamento, e o Dex tem um certo grau de compactação para a mesclagem de pacotes jar, deve haver diferenças antes e depois de jar e dex, portanto, em duas dimensões, primeiro criamos um projeto vazio da seguinte forma:

Não há uma linha de código, nada é referenciado, vamos ver o tamanho do projeto

Como contar os pacotes Jar dos quais o projeto depende?

Após 9981 dificuldades, encontrei um método adequado para você (compatível com Gradle 7.0), como segue:

Ele pode descobrir todos os pacotes jar e aars dos quais o projeto depende e colocá-los no arquivo build/output/libs do projeto.

task copyAllDependencies(type: Copy) {
    configurations.implementation.setCanBeResolved(true)
    configurations.api.setCanBeResolved(true)
    from project.configurations.implementation
    from project.configurations.api
    into "${buildDir}/output/libs"
}

Projeto Vazio - Estatísticas do Pacote Jar

Após a execução do script, como acima, o pacote jar total é de 1,8 MB

Projeto vazio - Estatísticas do pacote APK

Depois que o pacote tiver 1,2M, vamos apresentar o Jetpack abaixo, espere um minuto, e de repente pense que o Apk é apenas a sensação do usuário ao baixar, mas na verdade, qual o tamanho dele depois de colocado no mercado? Este é o culpado que enche sua memória. Após a instalação, é o seguinte:

嘿，还变小了

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：

这时的心情：又可以自由的玩耍了，继续猥琐发育。

我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。