Le jetpack doit être bon
Lorsque vous dites que les autres ne sont pas bons, vous devez d'abord donner une affirmation, alors parlons d'abord de ses avantages
- Lancé et maintenu par Google Daddy
- Les meilleures pratiques
- rétrocompatibilité
- Réduire le taux de bogues
- Implémentez facilement l'architecture MVVM
En fait, le premier article est suffisant pour impressionner beaucoup de gens, mais depuis le développement, ces nouveaux frameworks sont à la fois familiers et inconnus des programmeurs nationaux. En ce qui me concerne, en plus de connaître et d'utiliser Lifecycle, AppCompat, Other than Multidex, je ne l'ai jamais utilisé. C'est peut-être parce que j'ai moins d'activité. Même si je l'utilise peu, j'ai quand même quelques insatisfactions du point de vue des composants. Je ne suis pas doué en Jetpack. Résumé comme suit :
- cadre complexe
- Facilité d'utilisation aussi
- L'arborescence des dépendances des bibliothèques est également terrifiante : chaque fois que vous dépendez d'une bibliothèque, cela amène de nombreuses sous-bibliothèques.
- Le coût de l'apprentissage est élevé, il y a des grands qui se spécialisent dans la vente de cours Jetpack, on peut voir que le coût de l'apprentissage est élevé.
En fait, ce que je veux savoir le plus, c'est que si chaque application dépend de ces bibliothèques et est empaquetée dans son propre apk, n'y aurait-il pas beaucoup de code en double ? Ne pensez-vous pas que cela n'a pas d'importance? Calculons ensuite sa taille et voyons combien d'espace cela prend pour nous
Quelle est la taille du Jetpack
Toutes les bibliothèques sont ici :
developer.android.google.cn/jetpack/et…
Nous ne comptons que les bibliothèques couramment utilisées pour voir leur taille.Il y a deux dimensions, l'une est la taille du paquet jar et l'autre est la taille de l'apk. Étant donné qu'Android emballera le package jar au format Dex pendant le processus d'emballage, et que Dex a un certain degré de compression pour la fusion des packages jar, il doit y avoir des différences avant et après jar et dex, donc en deux dimensions, nous devons d'abord créer un projet vide comme suit :
Il n'y a pas une seule ligne de code, rien n'est référencé, regardons la taille du projet
Comment compter les packages Jar dont dépend le projet ?
Après 9981 difficultés, j'ai trouvé une méthode adaptée pour vous (compatible avec Gradle 7.0), comme suit :
Il peut trouver tous les packages jar et aars dont dépend le projet et les placer dans le fichier build/output/libs du projet.
task copyAllDependencies(type: Copy) {
configurations.implementation.setCanBeResolved(true)
configurations.api.setCanBeResolved(true)
from project.configurations.implementation
from project.configurations.api
into "${buildDir}/output/libs"
}
Projet vide - Statistiques du package Jar
Après l'exécution du script, comme ci-dessus, le package jar total est de 1,8 Mo
Projet vide - Statistiques du package APK
Une fois que le paquet aura atteint 1,2 M, nous présenterons Jetpack ci-dessous, attendrons une minute et penserons soudainement que l'Apk n'est que le sentiment de l'utilisateur lors du téléchargement, mais en fait, quelle est sa taille après sa mise sur le marché ? C'est le coupable qui remplit votre mémoire. Après installation, c'est comme suit :
嘿，还变小了
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：
这时的心情：又可以自由的玩耍了，继续猥琐发育。
我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。