Android Jetpack vor Gericht

Jetpack muss gut sein

Wenn Sie sagen, dass andere nicht gut sind, müssen Sie zuerst bestätigen, also lassen Sie uns zuerst über seine Vorteile sprechen

Gestartet und gepflegt von Google Daddy
Empfohlene Vorgehensweise
Rückwärtskompatibilität
Reduzieren Sie die Fehlerrate
Einfache Implementierung der MVVM-Architektur

Tatsächlich reicht der erste Artikel aus, um viele Leute zu beeindrucken, aber seit der Entwicklung sind diese neuen Frameworks heimischen Programmierern sowohl vertraut als auch ungewohnt.Was mich betrifft, zusätzlich zu der Vertrautheit mit und der Verwendung von Lifecycle, AppCompat, Other than Multidex, ich habe es nie benutzt. Es kann daran liegen, dass ich weniger Geschäft habe. Auch wenn ich es nicht viel benutze, habe ich immer noch eine gewisse Unzufriedenheit aus Sicht der Komponenten. Ich bin nicht gut in Jetpack. Zusammengefasst wie folgt:

komplexer Rahmen
Benutzerfreundlichkeit ebenso
Der Bibliotheksabhängigkeitsbaum ist ebenfalls erschreckend: Jedes Mal, wenn Sie sich auf eine Bibliothek verlassen, bringt dies viele Unterbibliotheken mit sich.
Die Lernkosten sind hoch. Es gibt große Jungs, die sich auf den Verkauf von Jetpack-Kursen spezialisiert haben. Es ist ersichtlich, dass die Lernkosten hoch sind.

Tatsächlich möchte ich am meisten wissen, dass es nicht eine Menge doppelten Code geben würde, wenn jede Anwendung von diesen Bibliotheken abhängt und in ihre eigene apk gepackt ist. Glaubst du nicht, dass es egal ist? Dann berechnen wir seine Größe und sehen, wie viel Platz er für uns einnimmt

Wie groß ist jetpack

Alle Bibliotheken sind hier:

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

Wir zählen nur die häufig verwendeten Bibliotheken, um zu sehen, wie groß sie sein können. Es gibt zwei Dimensionen, eine ist die Größe des JAR-Pakets und die andere die Größe der apk. Da Android das JAR-Paket während des Paketierungsprozesses in das Dex-Format verpackt und Dex einen gewissen Grad an Komprimierung für das Zusammenführen von JAR-Paketen hat, muss es Unterschiede vor und nach JAR und DEX geben, also in zwei Dimensionen, die wir zuerst erstellen ein leeres Projekt wie folgt:

Es gibt keine einzelne Codezeile, auf nichts wird verwiesen, schauen wir uns die Projektgröße an

Wie werden die Jar-Pakete gezählt, von denen das Projekt abhängt?

Nach 9981 Schwierigkeiten habe ich eine passende Methode für Sie gefunden (kompatibel mit Gradle 7.0), wie folgt:

Es kann alle JAR-Pakete und AARs finden, von denen das Projekt abhängt, und sie in die build/output/libs des Projekts einfügen.

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

Leeres Projekt – Jar-Paketstatistik

Nachdem das Skript wie oben ausgeführt wurde, beträgt das gesamte JAR-Paket 1,8 MB

Leeres Projekt - APK-Paketstatistik

Nachdem das Paket 1,2 Millionen beträgt, werden wir unten Jetpack vorstellen, eine Minute warten und plötzlich denken, dass die Apk nur das Gefühl des Benutzers beim Herunterladen ist, aber tatsächlich, wie groß ist sie, nachdem sie auf den Markt gebracht wurde? Das ist der Übeltäter, der Ihren Speicher füllt. Nach der Installation sieht es so aus:

嘿，还变小了

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：

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

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