Cómo el compilador Ark de Huawei puede mejorar el rendimiento de las aplicaciones de Android

Gran parte de la conversación reciente sobre Huawei ha girado en torno a la desafortunada situación política de la compañía debido a una Orden ejecutiva de EE. UU. que restringió a muchas empresas realizar negocios con Huawei. Las repercusiones de una decisión tan fundamental son demasiado enormes como para no prestarles atención. Pero en una realidad alternativa donde esta orden ejecutiva no existe, Huawei habría estado en el centro de atención por su Recientemente se reveló Ark Compiler, la última innovación que pretende cerrar la brecha de rendimiento de las aplicaciones entre Android y iOS.

Antes de profundizar en qué es Ark Compiler, debemos dar un paso atrás y comprender qué es un compilador y para qué sirve en el sistema Android.

Breve historia de los compiladores e intérpretes en Android

Un compilador es un programa informático que traduce código de un idioma a otro, que suele ser un lenguaje de máquina nativo. Esto puede ser ejecutado directamente por la computadora o a través de otro programa (intérprete). Esta traducción es necesaria porque escribimos código en lenguajes de programación legibles por humanos (como Java y Kotlin), mientras que la computadora sólo entiende el lenguaje de máquina nativo (código binario en forma de unos y 0). Por tanto, el compilador sirve como puente entre las instrucciones que escribe un humano y la capacidad de la máquina para comprender y luego ejecutar esas instrucciones. La rapidez y eficiencia con la que se lleva a cabo esta conversión y posterior interpretación define la eficiencia del compilador, por lo tanto introduciendo una correlación directa entre la eficiencia del compilador y el rendimiento y la eficiencia del código y, por extensión, aplicaciones.

Dalvik VM

En los primeros días de Android, el sistema operativo utilizaba lo que se llamaba Dalvik VM (el intérprete) junto con un compilador JIT (justo a tiempo). Este video anterior de Android Basics 101 de XDA TV La serie aborda la máquina virtual Dalvik y la configuración JIT, las cuales satisfacían las necesidades de los primeros sistemas Android donde las limitaciones de memoria eran abundantes. La máquina virtual Dalvik tomó el código de bytes de Java y lo convirtió en código de máquina cuando era necesario ejecutar el código (de ahí, Just-In-Time). Esto era necesario porque el espacio de almacenamiento en los teléfonos era una limitación real en aquel entonces, por lo que este enfoque permitía que las aplicaciones funcionaran con archivos de menor tamaño en el sistema.

La compilación e interpretación de aplicaciones en tiempo de ejecución tenía el inconveniente de un rendimiento general más lento de la aplicación, ya que la compilación se llevaría a cabo cuando el usuario estuviera usando la aplicación.

Dalvik también tenía limitaciones con su mecanismo de recolección de basura. Dalvik realizó un seguimiento colectivo de cada asignación de memoria. Una vez que Dalvik determina que el programa ya no utiliza una parte de la memoria, la libera al montón sin ninguna intervención del programador. Este proceso se llama recolección de basura (GC) y tiene como objetivo encontrar objetos de memoria en un programa al que ya no se accede y luego recuperar los recursos utilizados por esos objetos para liberar memoria. El sistema determina cuándo se necesita un GC de forma colectiva, por lo que los desarrolladores de aplicaciones no pueden elegir cuándo ocurren los eventos del GC [incluso en ART]. Entonces, si ocurriera un evento de GC en medio de cualquier actividad de procesamiento intensivo en la aplicación en primer plano, el sistema se detendría. la ejecución del proceso y comenzar la GC, aumentando así el tiempo de procesamiento e introduciendo un "jank" notable en el usuarios.

Estas y otras limitaciones empujaron a Google a explorar enfoques alternativos para lograr un rendimiento más rápido.

Tiempo de ejecución de Android

Con Android 4.4 KitKat, Google presentó ARTE (tiempo de ejecución de Android) en forma de vista previa con un compilador AOT (Ahead-Of-Time) y con Android 5.0 Lollipop, Google eliminó a Dalvik en favor de ART como el único intérprete disponible. ART con AOT convirtió el código a lenguaje de máquina en el momento de la instalación de la aplicación, en lugar de esperar a realizar dicha conversión cuando la aplicación esté en uso. Por lo tanto, este enfoque aceleró los tiempos de inicio de la aplicación, pero también introdujo inconvenientes en forma de tiempos de instalación más lentos y un mayor uso de espacio en disco. Para equilibrarlo todo, Google adoptado una combinación de AOT, JIT y compilación guiada por perfiles con ART en Android 7.0 Nougat, para garantizar que ningún factor se vea afectado drásticamente.

ART también trabajó para hacer que la recolección de basura fuera menos molesta. El proceso de GC se optimizó para que fuera más rápido en general con menos pausas (una única pausa corta frente a las dos pausas de Dalvik), menos fragmentación y menos uso de memoria. La presentación de Google en Google I/O 2014 entra en mayor detalle al explicar las limitaciones del GC de Dalvik y las mejoras de ART en ese sentido.

Incluso con estos cambios a lo largo de los años, la premisa básica del enfoque de Google implicaba interpretar el código durante la ejecución mientras se variaba el tiempo del elemento de compilación (traducción). La recolección de basura también sigue siendo un problema para los desarrolladores de aplicaciones debido a su naturaleza inherentemente disruptiva y colectiva. Podría decirse que el rendimiento de las aplicaciones de Android se ve afectado, ya que siguen existiendo gastos generales.

Compilador Ark de Huawei

Huawei ha estado trabajando para desarrollar una solución más eficiente y, en consecuencia, ha contratado a cientos de expertos en el campo. El resultado de este esfuerzo es Ark Compiler, que según Huawei es el primer compilador estático de la historia. que permite la traducción directa al lenguaje de máquina, eliminando por completo la necesidad de un intérprete. Ark Compiler también se desarrolló con el objetivo de maximizar la eficiencia de ejecución de Java y C, por lo que, en teoría, se deberían ver los mejores resultados con estos lenguajes.

Huawei presenta algunas características clave del Ark Compiler a continuación:

• Las técnicas de compilación como AOT y JIT pueden convertir algunos programas en código de máquina y ejecutarlos directamente en la CPU. pero estas técnicas no pueden liberarse completamente del intérprete y de las limitaciones que éste conlleva. Ark Compiler utiliza compilación estática, lo que le permite desconectarse del intérprete dinámico, abriendo la posibilidad de mejorar el rendimiento de la aplicación "pasos agigantados."
• La compilación estática tiene la posible desventaja de ser demasiado rígida y no poder realizar los ajustes que un compilador dinámico puede realizar durante la ejecución. Huawei afirma que la compilación estática de Ark Compiler resuelve esto "traduciendo sin problemas las características dinámicas del lenguaje de programación al código de máquina."
• Los procesos de compilación existentes tienen lugar durante o después de la instalación del paquete de la aplicación en el dispositivo móvil. Ark Compiler está diseñado para su implementación durante el desarrollo de software, lo que suponemos que ayuda a eliminar los gastos de tiempo durante la instalación y ejecución. Suponemos que los desarrolladores de aplicaciones podrían compilar directamente diferentes lenguajes en código de máquina nativo durante la ejecución de la aplicación. proceso de desarrollo y, por lo tanto, el APK resultante podría no necesitar interacción con un intérprete o una máquina virtual para función. En teoría, esto reduciría los gastos generales relacionados con JNI, por ejemplo.
• Ark Compiler también cambia la naturaleza colectiva de Garbage Collection. Permite que los eventos de GC ocurran por separado para diferentes subprocesos de Java. Este enfoque compartimentado pretende ofrecer menos basura en las aplicaciones en primer plano.

Como resultado de estos cambios, Ark Compiler puede aparentemente mejora la fluidez de operación del sistema Android hasta en un 24%, la velocidad de respuesta hasta en un 44% y la fluidez de las aplicaciones de terceros hasta en un 60%, afirmando llevar el rendimiento de la aplicación de Android al mismo nivel que el de iOS.

El compilador Ark está actualmente compilado y optimizado para la arquitectura de chip ARM. Huawei espera que en el futuro, el diseño colaborativo de hardware y software contribuya a maximizar las capacidades del chip Kirin.

Ark Compiler admite el uso estándar de Java, lo que permite la compilación directa de aplicaciones de terceros sin necesidad de que el desarrollador de la aplicación realice ninguna modificación en el código. Ark Compiler también permite "ajustes a la estructura del código" para mejorar aún más el rendimiento y la memoria. Huawei ha optado por hacer de Ark Compiler un sistema de código abierto, lo que permitiría a desarrolladores externos adoptarlo. y adaptar la tecnología a sus necesidades, fomentando su adopción entre los desarrolladores de aplicaciones y teléfonos móviles. fabricantes.

Si bien Huawei no menciona ninguna desventaja del Ark Compiler, se pueden esperar aplicaciones de gran tamaño al mismo tiempo. al menos, pero esto no debería plantear ningún problema en los dispositivos de la generación actual que vienen con amplia almacenamiento. También esperamos que Ark Compiler no esté disponible para todas las arquitecturas de CPU, ya que los problemas de compatibilidad de Google no son el dolor de cabeza de Huawei. Ark Compiler está diseñado para usarse durante el desarrollo y no durante la instalación; Esto presenta una indicación de que Huawei posiblemente haya modificado la forma en que se implementan e instalan las aplicaciones en dispositivos Android, y también puede haber trabajado en su propio diseño de APK. Si es correcto, esto podría plantear un importante problema de compatibilidad en el ecosistema, y ​​pasaría mucho tiempo antes de que se convierta en una característica estándar de Android, si es que alguna vez se convierte en una característica estándar.

No compilar en el dispositivo de un usuario también plantea una gran pregunta sobre la optimización. ART actualmente optimiza por microarquitectura, lo que significa que el binario resultante sería diferente para un dispositivo Snapdragon versus un dispositivo Exynos, o incluso para un Snapdragon 845 versus un Snapdragon 625. Este enfoque tiene sentido para los fabricantes que tienen control total del SoC, como Apple y Huawei. Sin embargo, dado que el resto del mundo Android utiliza muchos SoC diferentes, forzar el uso de una optimización genérica en todos los dispositivos será un obstáculo para la estandarización de Ark Compiler, nuevamente. En consecuencia, no espere que Ark Compiler llegue pronto a su ROM personalizada favorita.

Para aclarar, Ark Compiler está desarrollado para funcionar con Android y Huawei no ha mencionado nada en relación con su supuesto sistema operativo casero y su compatibilidad con Ark Compiler, por lo que no hacemos presunciones al respecto.

Huawei planea celebrar dos conferencias importantes dedicadas a los desarrolladores y al ecosistema en general. Se trata de la Conferencia de Desarrolladores de Dispositivos Huawei de China y la Conferencia de Desarrolladores de China de la Alianza Verde. Ambos eventos abordarán cuestiones específicas de código abierto relacionadas con Ark Compiler de Huawei, en un esfuerzo por hacer que los beneficios de esta tecnología sean lo más accesibles posible.

---

Un agradecimiento especial al colaborador senior reconocido de XDA Dees_Troy y desarrollador reconocido arte97 por su ayuda y aportes.

Nota: Huawei/Honor ha dejado de proporcionar códigos de desbloqueo oficiales del gestor de arranque para sus dispositivos. Por lo tanto, los gestores de arranque de sus dispositivos no se pueden desbloquear, lo que significa que los usuarios no pueden rootear ni instalar ROM personalizadas.