Facebook ouvre les sources de ReDex, son outil d'optimisation des applications Android

Facebook ouvre les sources de ReDex, son outil d’optimisation des applications Android

En ligne, et en ordre

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

14/04/2016 5 minutes
14

Facebook ouvre les sources de ReDex, son outil d'optimisation des applications Android

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.

redex

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.

redex

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.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

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

Réduire un effet comparable à la fragmentation

Ce que fait exactement ReDex

Transformer « le bytecode en meilleur bytecode »

Un code open source sous licence BSD

Commentaires (14)


Pas mal. Mais une partie de l’optimisation c’est “faite du code crade, on le purifie” (exemple pour l’interface) <img data-src=" />


Une espace de mashup entre “C’est du propre” et “Maison à vendre”, du nettoyage et du home staging.


Tout ce qu’il faut pas faire pour pallier la lourdeur de Java…


+1

&nbsp;

C’est bizarre que google ne propose pas déjà un système d’optimisation similaire <img data-src=" />


L’exemple de l’interface ne précise pas s’il existe une seconde implémentation de l’interface dans un autre projet, par exemple de test unitaire et qui n’est donc pas embarqué dans l’appli déployé. Auquel cas, l’interface est utile en temps de debug mais pas dans l’appli final ^^


Oui :)



Après tu peut aussi avoir comme raison la réduction du périmètre fonctionnel en cours de dev. Si le code est déjà testé et validé, peut de chance que tu puisses repasser sur ce code là.



C’était pour plaisanter sur le “chiffrage” des possible optimisation.<img data-src=" />


Java, Java, c’est vite dit. Il ne faut pas oublier que le bytecode généré n’a rien à voir avec celui de Java tel qu’on le connaît et que la VM est également totalement différente. Java, c’est juste le langage manipulé par le développeur, et ce n’est pas le seul qui soit disponible.



Sinon, ProGuard, l’outil de Google ne fait-il pas exactement la même chose ?








Vekin a écrit :



Java, Java, c’est vite dit. Il ne faut pas oublier que le bytecode généré n’a rien à voir avec celui de Java tel qu’on le connaît et que la VM est également totalement différente. Java, c’est juste le langage manipulé par le développeur, et ce n’est pas le seul qui soit disponible.



Sinon, ProGuard, l’outil de Google ne fait-il pas exactement la même chose ?







Et puis de l’optimisation “hors code” ca existe aussi en C/C++ … le inlining, déroulement de boucle etc. réalisée par le compilo.



Quand tu vois l’application Android Facebook et qu’ils te proposent leur outils d’optimisation… Hum…


C’est une blague ? Vu leurs applications Android… Seigneur.








MrVaykadji a écrit :



C’est une blague ? Vu leurs applications Android… Seigneur.





imaginez seulement s’ils ne l’avaient pas utilisé… <img data-src=" />



As-tu déjà décompilé leur application ? Je pense que tu devrais y jeter un oeuil avant même de songer remettre en question l’écosystème Android/Java…

C’est tellement mal foutu qu’il y a eu des patchs pour eux dans la VM de l’AOSP !

https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-…








MrVaykadji a écrit :



C’est une blague ? Vu leurs applications Android… Seigneur.





En fait ils ont fait un “Facebook Lite”, c’est l’app que les connaisseurs utilisent, le grand public utilise par contre l’usine à gaz.









CryoGen a écrit :



Et puis de l’optimisation “hors code” ca existe aussi en C/C++ … le inlining, déroulement de boucle etc. réalisée par le compilo.





C est clair ils reinventent la roue… ils feraient mieux de faire du code natif directement