He estado leyendo sobre el rendimiento del código y los parámetros de ajuste durante mucho tiempo. De hecho, los programas de Android son uno de mis enfoques.
Vamos a introducir al principio los conceptos básicos o más importantes en los que nos ayudan a llegar a una solución.
Como ha declarado el desarrollador de Android
El módulo se puede construir, probar y depurar independientemente
Por lo tanto, los módulos tienen sus propias dependencias y dependencias . Y puede explorarlo en el proyecto Hierarchy Viewer.
De hecho, el énfasis de la modularización en el mantenimiento es importante. A diferencia de Performance Matters, porque la modularización tiene este importante impacto:
- Aumentar la profundidad de la herencia
Aquí hay un diagrama que tracé para aclararlo. Como puede ver, mientras usa un módulo discreto, para invocar el Método A, se 2N micro secscompara con un N micro secsmódulo discreto.
Esta pregunta me viene a la mente de que los métodos referenciados cuentan lo que se relaciona con la profundidad de la herencia.
La respuesta es: aunque el uso de la modularización aumenta los métodos de referencia, pero en realidad no afecta el rendimiento de la aplicación y el principal problema posible es la profundidad de la herencia, que en la mayoría de los casos es ignorable .
Hago hincapié en que el aumento de los métodos de referencia en la modularización se debe a cada módulo Gradle y dependencias
¿Cómo la modularización de la aplicación puede aumentar el recuento de métodos referenciados tan drásticamente?
Condiciones en las que el analizador de APK de impacto es importante Métodos de referencia
También tenga en cuenta que la minificación y la reducción del código también pueden cambiar considerablemente el contenido de un archivo DEX después de compilar el código fuente.
Además de la declaración oficial anterior, quiero agregar otra condición en la que impacta el analizador APK que es:
¿Cuánto tiene experiencia el desarrollador en modularización?
La modularización es como un hogar en el que la arquitectura (desarrollador) define dónde debería estar la cocina y dónde debería estar el baño y dónde debería estar el WC.
¿Qué pasa si la arquitectura decide combinar WC y cocina? Sí, esto es un desastre.
Esto puede suceder durante la modularización si el desarrollador no tiene mucha experiencia.
Respondiendo a preguntas de OP Además de información adicional
Aquí respondo a las preguntas frecuentes en los comentarios
¿Por qué separar Gradle agregar al recuento de método referenciado? Y para una dependencia separada, si el resultado final es un APK único, entonces no creo que las dependencias duplicadas en la 'aplicación' y el módulo de características se agreguen al recuento de métodos referenciados.
Debido a que los módulos se pueden construir, probar y depurar, DEBEN tener sus propios Gradle & Dependencies.
Mientras se cumple el proyecto de varios módulos, el compilador genera varios .dexarchivos que incluyen:
- un
.dexarchivo para dependencias totalmente integradas
- módulos
.dexm
El .dexarchivo de dependencias es una integración de todos los módulos graduados
¡Veamos cómo un módulo gradle impacta el conteo final de Mothods referenciado!
hay 2 APK s con el mismo resultado pero diferencia en los recuentos de métodos referenciados.
Ambas son actividades vacías que tienen una 1.7kdiferencia en el recuento de métodos referenciados que es muy alta dependiendo de su funcionalidad. La diferencia clave está en Gradle de su módulo, uno de ellos fue configurado para
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
}
Otro configurado para
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.2.0-alpha01'
implementation 'androidx.constraintlayout:constraintlayout:2.0.0-beta4'
}
Aunque son solo actividades vacías, pero una diferencia mínima en Gradle causó una 1.7kdiferencia en los recuentos de métodos referenciados.
Y App Gradle es
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'androidx.appcompat:appcompat:1.1.0'
implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
implementation project(path: ':module')
}
La principal preocupación es ¿por qué la adición del recuento de métodos referenciados individualmente es diferente del recuento total de métodos referenciados en Apk Analyzer?
Esto es solo un filtro IDE, nada más. seguro, si solo selecciona un .dexarchivo, el método de referencia cuenta es igual a la SUMA de cada fila del método de referencia cuenta, pero si selecciona varios .dexarchivos, verá la diferencia en SUMA y el conteo real debido a la igualdad en las referencias que el analizador prefirió filtrarlos
en sus capturas de pantalla seleccionó varios .dexarchivos y luego la igualdad de filtro del analizador.
en nuestro proyecto estamos usando un archivo centralizado dependencies.gradle, por lo que no hay posibilidad de una versión diferente. Entonces, ¿cree que incluso si tenemos el mismo / exacto conjunto de dependencias y sus versiones en módulos de características, aumentará el recuento de métodos referenciados?
Teóricamente NO debería aumentar los recuentos de métodos referenciados. PERO , como lo expliqué, Developer Experience tiene un gran impacto en el resultado final.
Team Analyzer debe verificar y corregir los problemas de rendimiento antes del lanzamiento como
- reglas de vigilancia
- recursos reducidos y minificados
- androidManifest.xml
- ajustes de gradle
Ahora quiero aclarar cómo la experiencia del desarrollador y el mantenimiento del código afectan el resultado final. INCLUSO si su APK utiliza dependencias centralizadas
en el ejemplo anterior, he aumentado 5.1ken el recuento de métodos referenciados ¡¡¡ INCLUSO SI tuviera dependencias centralizadas !!!!!
Como es posible ?
La respuesta es: acabo de agregar un .jararchivo inútil y oculto en el libsdirectorio del proyecto. tan fácil como puedes ver, afecté el resultado final.
Como puede ver, la experiencia del desarrollador afecta el resultado final. Como resultado, prácticamente es posible que los métodos referenciados aumenten aunque, en teoría, NO deberían .
¿Y por qué no hay diferencia en el recuento de métodos referenciados cuando compilo solo el módulo 'aplicación' desactivando la compilación paralela? Debería haber disminuido ya que solo se habrían utilizado las dependencias del módulo 'app', ¿verdad?
La compilación no tiene ninguna relación con los métodos referenciados. Cumple con lo que el desarrollador quiere cumplir.
Conclusión
He cubierto todas las posibilidades en torno al tema. De hecho, puede surgir de diferentes situaciones y un desarrollador al usar esta guía puede solucionar el problema.
- Espero que haya encontrado por qué los métodos de referencia aumentaron y por qué en algunos casos podría aumentar drásticamente.
- Los módulos tienen sus módulos de aumento de Gradle & Dependencies y modularización. por lo tanto, estas referencias a métodos.
- La modularización en realidad impacta el rendimiento de la aplicación ignorable pero hace que el mantenimiento de su aplicación sea mucho mejor.
- La experiencia del desarrollador en modularización también tiene un gran impacto en el resultado final.
NOTA IMPORTANTE: casi todas las declaraciones son mi investigación e investigaciones. de hecho, puede haber errores y fallas y se actualizarán para agregar mucha más información en el futuro.
