Comment le compilateur Ark de Huawei peut améliorer les performances des applications Android

Une grande partie des discussions récentes autour de Huawei a tourné autour de la situation politique malheureuse de l'entreprise en raison d'un Décret américain interdisant à de nombreuses entreprises de faire des affaires avec Huawei. Les répercussions d’une décision aussi cruciale sont bien trop énormes pour ne pas y prêter attention. Mais dans une réalité alternative où ce décret n’existe pas, Huawei aurait été sous le feu des projecteurs pour son a récemment révélé Ark Compiler, la dernière innovation qui prétend combler l'écart de performances des applications entre Android et iOS.

Avant de plonger dans ce qu'est Ark Compiler, nous devons prendre du recul et comprendre ce qu'est un compilateur et à quoi il sert dans le système Android.

Bref historique des compilateurs et interprètes sur Android

Un compilateur est un programme informatique qui traduit le code d’un langage vers un autre langage, souvent un langage machine natif. Celui-ci peut alors soit être exécuté directement par l'ordinateur, soit être exécuté via un autre programme (interprète). Cette traduction est nécessaire car nous écrivons du code dans des langages de programmation lisibles par l'homme (comme Java et Kotlin), alors que l'ordinateur ne comprend que le langage machine natif (code binaire sous forme de 1 et des 0). Le compilateur sert ainsi de pont entre les instructions écrites par un humain et la capacité de la machine à comprendre puis à exécuter ces instructions. La rapidité et l'efficacité avec lesquelles cette conversion et cette interprétation ultérieure ont lieu définissent l'efficacité du compilateur, donc introduisant une corrélation directe entre l'efficacité du compilateur et les performances et l'efficacité du code, et par extension, applications.

Machine virtuelle Dalvik

Au début d'Android, le système d'exploitation utilisait ce qu'on appelait la machine virtuelle Dalvik (l'interpréteur) ainsi qu'un compilateur JIT (juste à temps). Cette ancienne vidéo d'Android Basics 101 de XDA TV La série aborde la machine virtuelle Dalvik et la configuration JIT, qui répondaient toutes deux aux besoins des premiers systèmes Android où les contraintes de mémoire étaient abondantes. La VM Dalvik a pris le bytecode Java et l'a converti en code machine au fur et à mesure que le code devait être exécuté (d'où Just-In-Time). Cela était nécessaire car l’espace de stockage dans les téléphones était à l’époque une véritable contrainte. Cette approche permettait donc aux applications de fonctionner avec des fichiers de plus petite taille dans le système.

La compilation et l'interprétation des applications au moment de l'exécution présentaient l'inconvénient de ralentir globalement les performances de l'application, car la compilation aurait lieu lorsque l'utilisateur utilisait l'application.

Dalvik avait également des limites avec son mécanisme de collecte des déchets. Dalvik a gardé une trace de chaque allocation de mémoire collectivement. Une fois que Dalvik détermine qu'un morceau de mémoire n'est plus utilisé par le programme, il libère cette mémoire dans le tas sans aucune intervention du programmeur. Ce processus s'appelle Garbage Collection (GC) et vise à trouver des objets de mémoire dans un programme auquel on n'accède plus, puis à récupérer les ressources utilisées par ces objets pour libérer de la mémoire. Le système détermine quand un GC est nécessaire sur une base collective, de sorte que les développeurs d'applications ne peuvent pas choisir quand les événements GC se produisent [même dans ART]. Ainsi, si un événement GC se produisait au milieu d'une activité de traitement intensive sur l'application de premier plan, le système se mettrait en pause. l'exécution du processus et commencer la GC, augmentant ainsi le temps de traitement et introduisant un « jank » notable dans le utilisateurs.

Ces contraintes et d'autres ont poussé Google à explorer des approches alternatives pour des performances plus rapides.

Exécution Android

Avec Android 4.4 KitKat, Google a introduit ART (environnement d'exécution Android) sous forme d'aperçu avec un compilateur AOT (Ahead-Of-Time) et avec Android 5.0 Lollipop, Google a abandonné Dalvik au profit d'ART comme seul interprète disponible. ART avec AOT a converti le code en langage machine au moment de l'installation de l'application, plutôt que d'attendre d'effectuer une telle conversion lorsque l'application est utilisée. Cette approche accélérait ainsi les temps de lancement des applications, mais introduisait également des inconvénients sous la forme de temps d'installation plus lents et d'une utilisation accrue de l'espace disque. Pour équilibrer le tout, Google adopté une combinaison d'AOT, JIT et de compilation guidée par profil avec ART sur Android 7.0 Nougat, pour garantir qu'aucun facteur n'est radicalement affecté.

ART a également travaillé à rendre la collecte des déchets moins intrusive. Le processus GC a été optimisé pour être globalement plus rapide avec moins de pauses (une seule pause courte contre les deux pauses de Dalvik), moins de fragmentation et moins d'utilisation de la mémoire. La présentation de Google à Google I/O 2014 explique plus en détail les limites du GC de Dalvik et des améliorations apportées par ART à cet égard.

Même avec ces changements au fil des années, le principe de base de l'approche de Google impliquait l'interprétation du code pendant l'exécution tout en faisant varier le timing de l'élément de compilation (traduction). Le Garbage Collection continue également d’être un problème pour les développeurs d’applications en raison de sa nature disruptive et collective inhérente. On peut soutenir que les performances des applications Android en souffrent, car des frais généraux continuent d'être impliqués.

Compilateur Ark par Huawei

Huawei s'efforce de développer une solution plus efficace et a par conséquent embauché des centaines d'experts dans le domaine. Le résultat de cet effort est le compilateur Ark, qui, selon Huawei, est le tout premier compilateur statique. qui permet une traduction directe en langage machine, éliminant complètement le besoin d'un interprète. Ark Compiler a également été développé dans le but de maximiser l'efficacité d'exécution pour Java et C, on devrait donc théoriquement voir les meilleurs résultats avec ces langages.

Huawei présente quelques fonctionnalités clés du compilateur Ark comme ci-dessous :

• Les techniques de compilation telles que AOT et JIT permettent de convertir certains programmes en code machine et de les exécuter directement sur le CPU, mais ces techniques sont incapables de se détacher complètement de l'interprète et des limitations qui y sont attachées. Le compilateur Ark utilise une compilation statique, ce qui lui permet de se détacher de l'interpréteur dynamique, ouvrant ainsi la possibilité d'améliorer les performances de l'application en "pas de géant."
• La compilation statique présente l'inconvénient potentiel d'être trop rigide et de ne pas pouvoir effectuer les ajustements qu'un compilateur dynamique peut effectuer pendant l'exécution. Huawei affirme que la compilation statique d'Ark Compiler résout ce problème "en traduisant de manière transparente les fonctionnalités dynamiques du langage de programmation en code machine."
• Les processus de compilation existants ont lieu pendant ou après l'installation du package d'application sur l'appareil mobile. Ark Compiler est conçu pour être déployé pendant le développement de logiciels, ce qui, nous le pensons, permet de réduire les coûts de temps lors de l'installation et de l'exécution. Nous supposons que les développeurs d'applications seraient capables de compiler directement différents langages en code machine natif pendant l'application. processus de développement, et l’APK résultant ne pourrait donc pas avoir besoin d’interaction avec un interprète ou une machine virtuelle pour fonction. Cela réduirait théoriquement les frais généraux liés à JNI, par exemple.
• Ark Compiler modifie également la nature collective du Garbage Collection. Il permet aux événements GC de se produire séparément pour différents threads Java. Cette approche compartimentée prétend offrir moins de parasites sur les applications de premier plan.

Grâce à ces changements, Ark Compiler peut améliore apparemment la fluidité du fonctionnement du système Android jusqu'à 24 %, la vitesse de réponse jusqu'à 44 % et la fluidité des applications tierces jusqu'à 60 %, prétendant amener les performances des applications Android au même niveau que celles sur iOS.

Le compilateur Ark est actuellement compilé et optimisé pour l'architecture de puce ARM. Huawei espère qu'à l'avenir, la conception collaborative de matériel et de logiciels contribuera à maximiser les capacités de la puce Kirin.

Le compilateur Ark prend en charge l'utilisation standard de Java, permettant la compilation directe d'applications tierces sans que le développeur de l'application ait besoin de modifier le code. Ark Compiler permet également des « ajustements de la structure du code » pour de nouvelles améliorations des performances et de la mémoire. Huawei a choisi de faire d'Ark Compiler un système open source, ce qui permettrait aux développeurs tiers d'adopter et adapter la technologie à leurs besoins, en favorisant son adoption auprès des développeurs d'applications et de téléphonie mobile fabricants.

Bien que Huawei ne mentionne aucun inconvénient au compilateur Ark, on peut s'attendre à de grandes tailles d'applications au tout début. du moins, mais cela ne devrait poser aucun problème sur les appareils de la génération actuelle qui sont dotés de nombreux stockage. Nous prévoyons également qu'Ark Compiler ne sera pas disponible pour toutes les architectures de processeur, car les problèmes de compatibilité de Google ne sont pas un casse-tête pour Huawei. Ark Compiler est conçu pour être utilisé pendant le développement et non pendant l'installation; cela indique que Huawei a peut-être modifié la façon dont les applications sont déployées et installées sur les appareils Android, et a peut-être également travaillé sur sa propre conception APK. Si cela est correct, cela pourrait poser un problème de compatibilité majeur dans l’écosystème, et il faudrait beaucoup de temps avant que cela devienne une fonctionnalité Android standard, voire jamais.

Ne pas compiler sur l'appareil d'un utilisateur soulève également une grande question d'optimisation. ART optimise actuellement sur une base par micro-architecture, ce qui signifie que le binaire résultant serait différent pour un appareil Snapdragon par rapport à un appareil Exynos, ou même pour un Snapdragon 845 par rapport à un Snapdragon 625. Cette approche est logique pour les fabricants qui ont le contrôle total du SoC, comme Apple et Huawei. Cependant, comme le reste du monde Android utilise de nombreux SoC différents, forcer l’utilisation d’une optimisation générique sur tous les appareils constituera encore une fois un obstacle à la standardisation du compilateur Ark. Par conséquent, ne vous attendez pas à ce qu'Ark Compiler arrive bientôt sur votre ROM personnalisée préférée.

Pour plus de précision, le compilateur Ark est développé pour fonctionner avec Android, et Huawei n'a rien mentionné concernant son prétendu système d'exploitation homebrew et sa compatibilité avec Ark Compiler, nous ne faisons donc aucune présomption à ce sujet.

Huawei prévoit d'organiser deux conférences majeures dédiées aux développeurs et à l'écosystème dans son ensemble. Il s'agit de la conférence des développeurs Huawei Device China et de la conférence des développeurs Green Alliance China. Les deux événements aborderont des problèmes open source spécifiques liés au compilateur Ark de Huawei, dans le but de rendre les avantages de cette technologie aussi largement accessibles que possible.

---

Un merci spécial au contributeur senior reconnu de XDA Dees_Troy et développeur reconnu arter97 pour leur aide et leurs contributions.

Remarque: Huawei/Honor ont cessé de fournir les codes de déverrouillage officiels du chargeur de démarrage pour leurs appareils. Par conséquent, les chargeurs de démarrage de leurs appareils ne peuvent pas être déverrouillés, ce qui signifie que les utilisateurs ne peuvent pas rooter ou installer de ROM personnalisées.