Jetpack debe ser bueno
Cuando dices que los demás no son buenos, primero debes dar afirmación, así que hablemos primero de sus ventajas.
- Lanzado y mantenido por Google Daddy
- Mejores prácticas
- compatibilidad con versiones anteriores
- Reducir la tasa de errores
- Implemente fácilmente la arquitectura MVVM
De hecho, el primer artículo es suficiente para impresionar a muchas personas, pero desde el desarrollo, estos nuevos marcos son familiares y desconocidos para los programadores domésticos. En lo que a mí respecta, además de estar familiarizado y usar Lifecycle, AppCompat, Other than Multidex, nunca lo he usado. Puede ser porque tengo menos negocio. Incluso si no lo uso mucho, todavía tengo cierta insatisfacción desde la perspectiva de los componentes. No soy bueno en Jetpack. Resumido de la siguiente manera:
- marco complejo
- Facilidad de uso también
- El árbol de dependencias de la biblioteca también es aterrador. Cada vez que dependes de una biblioteca, traerá muchas subbibliotecas.
- El costo de aprender es alto, hay grandes que se especializan en vender cursos Jetpack, se puede ver que el costo de aprender es alto.
De hecho, lo que más quiero saber es que si cada aplicación depende de estas bibliotecas y está empaquetada en su propio apk, ¿no habría mucho código duplicado? ¿No crees que no importa? Luego, calculemos su tamaño y veamos cuánto espacio ocupa para nosotros.
¿Qué tan grande es Jetpack?
Todas las bibliotecas están aquí:
desarrollador.android.google.cn/jetpack/y…
Solo contamos las bibliotecas de uso común para ver qué tan grandes pueden ser. Hay dos dimensiones, una es el tamaño del paquete jar y la otra es el tamaño del apk. Debido a que Android empaquetará el paquete jar en formato Dex durante el proceso de empaquetado, y Dex tiene un cierto grado de compresión para la fusión de paquetes jar, debe haber diferencias antes y después de jar y dex, por lo que en dos dimensiones, primero creamos un proyecto vacío de la siguiente manera:
No hay una sola línea de código, no se hace referencia a nada, veamos el tamaño del proyecto
¿Cómo contar los paquetes Jar de los que depende el proyecto?
Después de 9981 dificultades, encontré un método adecuado para usted (compatible con Gradle 7.0), de la siguiente manera:
Puede encontrar todos los paquetes jar y aars de los que depende el proyecto y colocarlos en la compilación/salida/libs del proyecto.
task copyAllDependencies(type: Copy) {
configurations.implementation.setCanBeResolved(true)
configurations.api.setCanBeResolved(true)
from project.configurations.implementation
from project.configurations.api
into "${buildDir}/output/libs"
}
Proyecto vacío: estadísticas del paquete Jar
Después de que se ejecuta el script, como se indicó anteriormente, el paquete jar total es de 1,8 MB
Proyecto vacío - Estadísticas del paquete APK
Después de que el paquete sea 1.2M, presentaremos Jetpack a continuación, espere un minuto y de repente piense que el Apk es solo la sensación del usuario al descargar, pero de hecho, ¿qué tan grande es después de que se coloca en el mercado? Este es el culpable de que te llene la memoria, después de la instalación queda de la siguiente manera:
嘿，还变小了
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：
这时的心情：又可以自由的玩耍了，继续猥琐发育。
我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。