Facebook, clairement obsédé par l’optimisation du code de ses produits, propose désormais aux développeurs qui le souhaitent un nouvel outil pour leurs applications Android. ReDex a ainsi pour mission d’optimiser le bytecode à la volée, proposant des améliorations de performances allant de 15 à 25 %.

Facebook a profité de sa série d’annonces pour aborder un point qui lui tient à cœur : les performances. Que l’on parle de celles de son site principal ou des applications mobiles, l’éditeur a à cœur de chercher les goulets d’étranglement. Un point intéressant car Facebook n’est pas connu pour proposer les applications les plus légères, qu’il s’agisse de leur poids ou de leur consommation générale.

Accélérer le chargement et la réactivité générale

Parmi sa batterie d’outils utilisés en interne pour optimiser le code, Facebook en possède un dédié au bytecode des applications Android, quand elles sont développées en Java. Le bytecode est pour rappel un code intermédiaire, prenant place entre la source en Java et le langage machine. Il s’agit d’un code précompilé, nécessitant donc moins de travail pour l’appareil mobile. Pour Facebook, il restait nettement de quoi améliorer les performances dans ce domaine, puisque personne n’avait jamais vraiment cherché à optimiser cette partie.

C’est donc ce que fait ReDex : accélérer le bytecode pour le reste notamment plus rapide à lire par l’appareil Android. Selon Facebook, l’ouverture d’une application se fait plus vite à hauteur de 15 % sur un smartphone de 2015, et jusqu’à 25 % sur un modèle de 2011. Facebook indique que le code est « reconfiguré à la volée », la meilleure partie selon l’éditeur étant que l’outil ne réclame aucun travail supplémentaire.

Réduire un effet comparable à la fragmentation

Les développeurs peuvent en effet utiliser ReDex sans rien changer à leur application, ni Google à Android. Il s’agit d’une étape supplémentaire après la précompilation du code. Les mesures prises par ReDex sont donc automatiques. Selon l’ingénieur logiciel Bert Maher, qui présentait la conférence à ce sujet, il suffit littéralement de « lâcher » l’outil dans l’application pour qu’elle y accomplisse son travail.

Plus précisément, le travail se fait sur l’organisation des classes dans les fichiers dex. Sur son billet, l’éditeur explique qu’elles ne sont pas placées dans un ordre optimal, mais littéralement « balancées » de cette manière par la toolchain de compilation. De la même manière qu’un disque dur fragmenté oblige le système à en chercher les différents morceaux, la mémoire du smartphone s’affole alors pour chercher les classes dont l’application a besoin dans sa séquence de démarrage, provoquant des lenteurs, allongeant le temps de lancement, réclamant plus de cycles CPU et donc consommant plus de batterie.

Ce que fait exactement ReDex

Facebook indique par ailleurs que son approche est assez commune pour qui connait l’optimisation classique du code natif. Le concept global se nomme FDO (feedback-directed optimization) et se base sur un ensemble de retours et d’informations récoltés durant des tests se concentrant sur le lancement à froid. L’analyse permet de repérer toutes les classes et d’en définir l’ordre optimal pour accélérer leur enchainement et donc de réduire les opérations réalisées dans la mémoire flash de l’appareil.

L’analyse du bytecode permet à ReDex de voir l’application dans son ensemble. L’outil peut notamment y repérer les interfaces superflues, à savoir toutes celles qui n’ont qu’une seule implémentation, en remontant à travers la hiérarchie des classes. Les interfaces trouvées sont remplacées par des méthodes d’implémentation et les restes sont supprimés. ReDex s’occupe aussi de trouver les éventuelles métadonnées en trop, pour les supprimer.

Transformer « le bytecode en meilleur bytecode »

Cette phase d’optimisation – qui « transforme le bytecode en meilleur bytecode » selon Maher – rejaillit alors de plusieurs manières différentes. Le principal changement est le temps de lancement de l’application, les instructions étant placées dans un ordre plus logique. Autre impact, la réactivité générale de l’application, pouvant grimper de 25 % selon Facebook, qui n’indique pas non plus comment ce score est calculé exactement. Notez par ailleurs que le chiffre sera plus élevé sur les appareils plus anciens.

Enfin, et c’est un point qui devrait intéresser de nombreux développeurs, le passage de ReDex provoque une baisse du poids de l’application. Cette fois par contre, Facebook ne donne aucun chiffre. Sans doute ne vaut mieux-t-il pas : le poids d’une application dépend d’un très grand nombre de facteurs, notamment de la somme des ressources graphiques qui y est présente. L’optimisation agit sur le code fonctionnel de l’application. Dans le cas de sa propre application pour Android, Facebook indique cependant que le poids avait été réduit en novembre de 25 % et qu’elle se lançait jusqu’à 30 % plus rapidement.

Un code open source sous licence BSD

L’outil se trouve désormais sur le dépôt Github de Facebook, en open source et sous licence BSD, relativement souple. ReDex a cependant un certain nombre de dépendances (folly, glog, double-conversion, boost et zlib) et se sert d’autoconf et automake pour la compilation. Des instructions sont données pour aider les développeurs à mettre l’outil en place, mais seulement sous OS X et Ubuntu 14.04 à titre d’exemples.