Muy buenas, les saluda Luis y hoy les traigo otro nuevo post.
Índice
Las aplicaciones delgadas significan descargas más rápidas, lo que significa usuarios más felices
Este artículo es para los desarrolladores que han oído hablar o han estado usando Realm Database en sus aplicaciones de Android.
Este es un tutorial que tiene como objetivo ayudarlo a configurar su proyecto de Android de una manera que ocupe menos espacio del que normalmente ocuparía.
Para este artículo, tomaré mi aplicación, SilverScreener , como un caso de estudio.
Puedes encontrar el código fuente en Github aquí:
Un tiempo antes del reino …
Regresemos a una época en la que implementé una base de datos SQLite normal y aburrida en mi aplicación. El tamaño de APK de la aplicación era de 4 MB .
Pero como la mayoría de ustedes saben, escribir una base de datos SQLite es bastante aburrido y consta de una gran cantidad de código repetitivo. Cambiar el esquema de la base de datos también significó hacer muchos cambios en otras partes del código.
Entrar, Reino
Cuando escuché por primera vez sobre Realm por alguien en Reddit, quedé impresionado por lo fácil que fue configurarlo y poner en funcionamiento una base de datos, ¡una que incluso venía con funcionalidades de sincronización en la nube! Fue fácil realizar cambios en el esquema de la base de datos sin tener que cambiar gran parte del código que ya había escrito.
Fue muy fácil y rápido realizar operaciones CRUD. Cada línea del código de Realm fue fácil de leer y comprender, incluso para un novato. También fue sencillo trabajar con subprocesos. ¿Cifrado de base de datos? ¡Simplemente escriba dos líneas adicionales de código y listo!
Ahora, por supuesto, este artículo no es un anuncio de Realm ni un tutorial de Realm. Así que pasemos al problema que nos ocupa con el uso de Realm.
¿Qué le pasa a Realm?
Una vez que agregué las dependencias para Realm en mi aplicación, configuré Realm y eliminé todo el código SQLite, ¡el tamaño del APK de mi aplicación aumentó de 4 MB a 12 MB ! Ahora, para una aplicación simple como la mía, esta diferencia podría no ser mucha. Pero, ¿y si su aplicación tuviera una enorme base de datos con muchas entidades? El incremento sería mucho mayor.
La causa
Los teléfonos Android tienen procesadores que admiten las siguientes arquitecturas:
x86
x86_64
armeabi-v7a
arm64-v8a
armeabi
(Obsoleto)mips
(Obsoleto)mips64
(Obsoleto)
Cuando crea el APK de su aplicación, la biblioteca Realm se compila para todas estas arquitecturas. Por eso el tamaño del APK es tan grande.
Su APK que está siendo construido por Android Studio tiene código nativo de Realm para todas las arquitecturas mencionadas anteriormente. Pero los teléfonos de sus usuarios solo necesitan una aplicación que tenga código nativo de Realm para la arquitectura de su procesador. No necesitan una aplicación que tenga Realm compilado para todas las arquitecturas. Eso solo aumentaría el tamaño de la aplicación que tendrían que descargar de Play Store.
La solución
Esto se puede hacer de dos maneras:
- Filtros ABI (menos efectivo)
- División de APK (más efectivo)
En aras de la brevedad, en este artículo, solo cubriré la división de APK. Esto es lo que realmente significa:
La división de APK consiste en crear varios APK, específicos para cada arquitectura, para su aplicación.
Esto se puede hacer en el nivel de la aplicación. build.gradle
archivo de su proyecto de Android.
Desde el armeabi
, mips
y mips64
arquitecturas ahora son obsoletas, centrémonos en crear APK separados para x86,
x86_64
, armeabi-v7a
y arm64-v8a
arquitecturas.
Si está haciendo esto para una aplicación que necesita cargar en Play Store
Dado que se generarán varios APK, los códigos de versión para todos ellos deben ser diferentes, ya que Google Play Console no le permite cargar APK con los mismos códigos de versión.
Por lo tanto, si su código de versión actual para el único APK es 1, la siguiente versión de su aplicación con varios APK no debería ser 2 (x86
), 3 (x86_64
), 4 (armeabi-v7a
) y 5 (arm64-v8a
). Esa es una mala práctica y sería más difícil de manejar para ti.
En cambio, es mejor tener un número decimal enorme y asignar «códigos» a cada arquitectura, de la siguiente manera:
x86
: 0x86_64
: 1armeabi-v7a
: 2arm64-v8a
: 3
Entonces, los códigos de versión de su aplicación se verían como 2000 (x86
), 2001 (x86_64
), 2002 (armeabi-v7a
) y 2003 (arm64-v8a
), y los códigos de la siguiente versión serían 3000, 3001, 3002 y 3003. Ya entiendes la idea.
Ahora, vayamos a la parte práctica y profundicemos en nuestro nivel de aplicación. build.gradle
archivo
Así es como su nivel de aplicación del archivo build.gradle
, habilitado con la división de APK debería verse:
apply plugin: 'com.android.application' android { ... ... defaultConfig { ... versionCode 2000 ... } ... ... // APK splitting splits { abi { // Enable APK splitting wrt architecture enable true // Reset the architectures for which you need to build the APKs for reset() // Include the architectures for which Gradle is building APKs include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a' // Set this to false if you don't want an APK that has native code for all architectures universalApk false } } // Assign codes to each architecture project.ext.versionCodes = ['x86': 0, 'x86_64': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3] // Add the architecture-specific codes above to base version code, i.e. the version code specified in the defaultConfig{} block // Example: 2000 is the base version code -> 2000 (x86), 2001 (x86_64), 2002 (armeabi-v7a) & 2003 (arm64-v8a) would be the version codes for the generated APK files android.applicationVariants.all { variant -> variant.outputs.each { output -> output.versionCodeOverride = project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1 + android.defaultConfig.versionCode } } }
Ahora, genere sus nuevos APK y debería ver una disminución significativa en el tamaño de los APK individuales específicos de la arquitectura.
Puede cargar los 4 APK generados en Google Play Console para la misma versión de la aplicación, ya que todos tienen códigos de versión diferentes.
Los usuarios solo podrán descargar la versión del APK de Play Store que sea específica para la arquitectura de su teléfono, todo sucediendo detrás de escena, gracias a la magia de Google Play Console.
¿La mejor parte? El tamaño de APK de mi aplicación, SilverScreener, era ahora 3,1 MB!
Aquí hay una comparación de antes y después de la división de APK:
SQLite vs Realm vs Realm con división de APK: comparación de tamaño de APK:
Algo adicional
Realm es una gran base de datos, pero también aumenta significativamente el tamaño del APK.
Adelante, comience a usar la división de APK en su aplicación sin comprometer el tamaño del archivo.
Gracias por leer.
Añadir comentario