android - dog - dalvik vm dex2oat xmx
Desventajas en Multidexing la aplicación de Android (4)
Recientemente he leído sobre el límite del método Dalvik 65K. He entendido que la lista de invocación de métodos solo puede invocar las primeras 65536 referencias de métodos. Para hacer frente a esto tenemos varias soluciones. Uno de ellos es el multidexing donde dividimos los archivos .dex en varias clases [classes.dex, classes1.dex ...] usando la biblioteca de soporte de Android.
Lo que no he entendido es qué inconveniente sufre una aplicación de Android debido a este multidexing y por qué deberíamos poner mucho esfuerzo en minimizar el número de métodos a los que se hace referencia.
Básicamente, a mi entender, para reducir el conteo de métodos, tengo que reducir la modularización, lo que hace que mi código sea menos legible, dejando aparte el número de horas quemadas al resumir los códigos de bibliotecas de terceros. ¿Es la reducción de la cuenta método vale la pena?
El principal inconveniente es un mayor tamaño dex / apk. Los archivos Dex tienen grupos de constantes que se comparten entre todas las clases en ese archivo dex. Cuando las clases se dividen en varios archivos dex, estas constantes compartidas deben duplicarse en cada archivo dex en el que se utilizan.
En términos generales, las desventajas de multidex son: mayor tamaño de APK, posible inicio más lento de la aplicación y mayor huella de memoria.
El motivo es que algunos datos (por ejemplo, StringData) no se pueden compartir y, por lo tanto, deben almacenarse parcialmente en varios archivos DEX al mismo tiempo. StringData consta de cadenas literales cargadas desde el código, así como los nombres de clase, método y campo, y comúnmente representan hasta el 20% del total del archivo DEX.
Pero las desventajas reales (además del tamaño de APK) dependen en gran medida de la versión de Android en la que esté ejecutando la aplicación.
Google optimizó el Android Runtime (ART) para eliminar estos inconvenientes. Android O (API 26) introdujo el contenedor VDEX para almacenar archivos DEX pre-validados. Con Android P, Google optimizó aún más el precompilador (nombre en código CompactDex) y agregó una sección de datos compartidos al contenedor VDEX para deduplicar los datos utilizados en varios archivos DEX. Por lo tanto, existen pocas desventajas al ejecutar aplicaciones multidex en el tiempo de ejecución de Android P.
Multidexing en sí mismo es un término que no funciona, si la aplicación es multidex, significa que hay una carga sobre el proceso interno de Android que ejecuta la aplicación.
Cada aplicación de Android se ejecuta dentro de un solo proceso (tarea), cuando está multidex, significa que el proceso se divide en partes que crearán problemas de rendimiento con el pequeño procesador de Android, sin importar cómo escriba el código.
Estoy de acuerdo con aakash kava en que casi todas las aplicaciones son multidexed porque hoy en día los procesadores android tienen muy buen rendimiento y la memoria RAM de android es excelente, pero no es así, lo que significa que debemos ignorar el multidexing.
Usted está pensando demasiado en multidex, en lugar de eso, debe observar e identificar si hay algún problema de rendimiento con su aplicación al perfilar su aplicación.
Multidexing no aumenta el tamaño del código, el tamaño mayor y los problemas de rendimiento son con los recursos de animación / imagen / audio / video, son los que aumentan el tamaño y reducen el rendimiento.
La inclusión de muchas bibliotecas de terceros eventualmente superará el límite de 64k y casi todas las aplicaciones de hoy en día son multidexed. Los usuarios demandan aplicaciones de múltiples funciones hoy en día, lo que requiere integración con muchas bibliotecas de terceros.
Solo cuando se realiza la animación / programación de juegos, donde la velocidad es lo más importante, más llamadas a métodos pueden ser perjudiciales, pero esto no tiene nada que ver con el multidexing, incluso las aplicaciones pequeñas no multidexing mal escritas funcionarán mal en cualquier dispositivo.
El tiempo de inicio afectará al multidexing, pero ciertamente puede mejorarse cambiando la lógica de la aplicación para retrasar la carga de otras bibliotecas y recursos costosos.
¿Es la reducción de la cuenta método vale la pena ?
NO
Lo ideal sería utilizar más métodos y modularizar su código, ya que probar y cambiar las aplicaciones móviles es un gran desafío después de su publicación. Depurar y eliminar errores es más costoso que el tamaño de multidex y su impacto en el rendimiento. Debido a las pantallas pequeñas, las diferentes marcas, la IU diferente, los usuarios se enojan más con las aplicaciones en el teléfono en comparación con las computadoras. Mantenerse al tanto de la demanda de los usuarios será más fácil si el código se divide en varias bibliotecas probadas individuales.