Pourquoi les applications Android sont-elles plus légères que sur iOS ?

 

Nous avons constaté que, dans l’ensemble, les applications Android avaient tendance à peser moins lourd que leurs homologues sur iOS. Nous avons donc demandé à des développeurs à quoi cela pouvait être dû.

Tout a commencé au détour d’une conversation avec Romain, rédacteur en chef de FrAndroid, pendant la pause déjeuner. Ce vieux bougre utilise deux smartphones au quotidien : un OnePlus 5 et… un iPhone 7 — cet utopiste est du genre à prêcher la paix entre Android et iOS.

Alors que nous abordions la question de l’encaissement des derniers chèques envoyés par nos amis Samsung, Google, Apple, Castorama et le resto indien du coin de la rue, je l’entends pester contre Facebook. Plus précisément : sur le poids beaucoup trop volumineux de l’application iOS du réseau social : 211 Mo, rien que ça !

Les applications iOS ont tendance à peser plus lourd.

La surprise passée, je m’empresse de comparer ce nombre avec l’espace de stockage occupé par l’application Facebook sur mon propre terminal (Huawei P9). Installée, celle-ci occupe 177 Mo (sans compter les données et le cache). Même résultat sur les OnePlus 5, Samsung Galaxy S8 et Honor 9, tous sous Android Nougat. On obtient ainsi une différence significative de 34 Mo entre les versions iOS et Android de Facebook.

En poussant la comparaison avec d’autres applications, une tendance très nette se dégage : les applications iOS sont, en grande majorité, plus lourdes que leurs homologues sur Android. Notons tout de même que c’est avec les applications de Facebook (Facebook, Messenger, WhatsApp et Instagram) que la différence est la plus frappante.

iPhone 7Honor 9Huawei P9Samsung Galaxy S8
Facebook211 Mo177 Mo177 Mo177 Mo
Chrome60,6 Mo168 Mo168 Mo168 Mo
Twitter114,691,58 Mo87,81 Mo88,62 Mo
Trainline34,8 Mo19,36 Mo19,37 Mo19,32 Mo
Netflix66,7 Mo54,47 Mo51,10 Mo50,93 Mo
YouTube83,8 Mo63,29 Mo63,31 Mo72,36 Mo
WhatsApp102,6 Mo51,55 Mo50,39 Mo50,44 Mo
LeMonde.fr37,9 Mo22,04 Mo26,48 Mo22,01 Mo
Instagram73,4 Mo58,93 Mo58,07 Mo57,23 Mo

NB : Tous les nombres cités dans ce tableau font référence au poids des applications une fois installées sur les terminaux et non à leurs poids affichés sur le Play Store et l’App Store, sensiblement différents.

Au vu de ces résultats, une question se pose alors : pour quelle raison les applications Android sont-elles généralement moins volumineuses que sur iOS ? 

Avant de nous pencher sur la question, prenons le temps de clarifier quelques points qui pourraient provoquer une confusion. Tout d’abord, il est tout à fait normal d’observer des différences entre les smartphones Android puisque ces derniers n’ont pas forcément le même code natif (32 ou 64 bits), ne font pas appel aux mêmes ressources ou ne sont pas aussi bien mis à jour les uns par rapport aux autres.

L’exception Chrome

En outre, dans le tableau ci-dessus, vous avez sans doute remarqué que Chrome constitue une drôle d’exception et pèse près de trois fois plus sur Android que sur iOS. Cela s’explique essentiellement par le fait que le navigateur de Google propose moins de fonctionnalités sur les iPhone que sur Android où il n’a pas cessé de s’enrichir. Par ailleurs, sur iOS, Chrome est forcé d’utiliser le moteur de rendu HTML — qui permet de restituer de manière claire les lignes de codes et les différents formats d’images d’une page web — intégré à iOS, le même que pour Safari, WebKit.

Autrement dit, Chrome sur iOS ne propose rien de plus que Safari, mais avec une interface différente.

Attaquons-nous maintenant au vrai sujet de ce papier. Pour éclairer ma lanterne, plusieurs développeurs opérant sur les deux systèmes d’exploitation sont venus à ma rescousse. Passionnés, ils ont tous pris le temps de m’expliquer quelles étaient les raisons de ces différences dans le poids des applications.

La philosophie Android

Ce qui ressort particulièrement de ces échanges, c’est qu’il y a tout un tas de raisons qui, mises bout à bout, expliquent pourquoi les applications Android ont tendance à être plus légères que sur iOS. Par conséquent, même si l’objectif ici est de vulgariser le sujet, on évitera de ne citer qu’un seul et unique facteur.

Comme le rappelle l’un de mes contacts, Edouard Marquez — qui collabore régulièrement avec FrAndroid — « Android est culturellement ancré dans l’idée d’être accessible au plus grand monde ». Il cite notamment l’exemple d’Android Go, la version allégée d’Android, pour appuyer son propos.

Et cette volonté de minimisation ne date pas d’hier puisque des optimisations et des API sont mises à disposition des développeurs depuis au moins 2013, avec Android 4.4 KitKat, pour aller dans ce sens. Et comment fait-on pour alléger une application alors ?

Le langage de programmation d’Apple a encore du chemin à faire

Avant sur iOS, le langage de programmation était Objective-C. Mais celui-ci est remplacé depuis quelques années par Swift, un nouveau langage introduit par Apple, plus moderne et plus adapté aux besoins des développeurs, d’autant plus qu’il est open source et donc très plébiscité. Bref, ça leur simplifie grandement la vie. Néanmoins, Swift pèche pour l’instant par son manque de maturité.

Swift remplace Objective-C.

Un de mes contacts, RxVincent, précise qu’Apple ne considère pas encore Swift comme étant « stable ». Un autre développeur, Antoine Kuhn, ajoute que le langage étant très récent, il a encore tendance à changer régulièrement. De ce fait, les systèmes iOS n’embarquent pas encore le logiciel adapté : ils n’ont pas d’environnement d’exécution (appelé « runtime ») compatible avec Swift. Autrement dit, un iPhone n’a pas la bonne boîte à outils pour exécuter ce langage de programmation, alors qu’il est correctement paré pour exécuter du Objective-C.

Ainsi, pour que le système puisse l’exécuter, une application iOS codée en Swift doit elle-même embarquer le runtime idoine sous forme de bibliothèque.  Or, ce surplus pèse entre 10 et 15 Mo et peut monter jusqu’à 30 Mo selon mes sources. Il n’est pas rare d’ailleurs de trouver des discussions à ce sujet sur les forums de développeurs comme ici, ou ici. Notons tout de même qu’Apple prévoit de fournir un runtime natif pour les prochaines versions de Swift (actuellement on en est à la v.3).

Android mise sur Kotlin

De son côté, Android Studio, l’environnement de développement intégré (IDE) d’Android, supporte, depuis 2016, lui-aussi un nouveau langage de programmation : Kotlin. Jusqu’ici, toutes les applications sur cet OS étaient en Java, un langage plus mature, certes, mais très obsolète sur de nombreux aspects.

Kotlin est également un langage apprécié des développeurs.

Kotlin, à l’instar de Swift, est lui aussi un langage très apprécié par les développeurs, car il est beaucoup plus moderne. Or, l’avantage de Kotlin c’est qu’il est compilé dans le même langage que Java quand il s’agit d’exécuter le code et, par conséquent, il était donc compatible dès le début avec les systèmes Android. Enfin, presque…

Kotlin propose davantage d’options que Java et nécessite donc aussi un runtime supplémentaire embarqué par l’application pour exécuter certaines fonctions bien spécifiques. Mais celui-ci ne pèse presque rien, seulement une centaine de kilooctets. On est loin des nombreux Mo de Swift !

Optimiser le code

Edouard Marquez revient sur la minimisation voulue par Google et affirme que la firme de Mountain View « martèle depuis des années que la taille des applications est très importante ». Et ce ne sont pas que des paroles en l’air. Plusieurs solutions sont en effet mises à disposition pour économiser de l’espace.

Ils sont deux — Edouard Marquez et RxVincent — à m’avoir parlé de l’outil Proguard fourni par Android Studio. Celui-ci est très pratique, car il permet de transformer le code d’une application avant qu’elle ne soit livrée dans le Play Store. Proguard est notamment utilisé pour chiffrer le code, mais la modification qui nous intéresse le plus est la « minification ».

Pendant ce processus, Proguard va traiter chaque élément du code (méthodes, variables, objets, packages…) et réduire leur nom aussi court que possible. « Cela peut paraître bête, mais ça permet de gagner énormément sur l’occupation mémoire du code source », explique RxVincent. À titre d’exemple, l’application — baptisée Equisense — sur laquelle il travaille, fait 11,4 Mo et 7,9 Mo avant et après la compilation avec Proguard.

Par ailleurs, XCode, l’environnement de développement intégré d’iOS, ne propose pas d’équivalent à Proguard. On a donc ici, une autre raison potentielle de la différence de poids entre les applications Android et iOS.

En plus de cela, le Play Store permet de déployer différentes versions d’une même application afin de s’adapter à la résolution de l’écran, à l’architecture et à la version Android des différents terminaux sur laquelle elle sera téléchargée.

Limiter le poids des icônes

Abordons maintenant la question des images dans les applications ou, plus précisément, des icônes. Que ce soit sur iOS ou sur Android, il faut prévoir diverses tailles pour les icônes au format PNG. Sauf que, comme vous pouvez l’imaginer, l’ensemble de ces fichiers peut peser sacrément lourd. Or, depuis un moment déjà, Android prend en charge les VectorDrawable — un format assez proche du SVG (Graphique Vectoriel Adaptable) et spécialement adapté à cet écosystème.

Si ce que je viens d’écrire vous parait incompréhensible, ne vous inquiétez pas, c’est, en réalité, très simple à comprendre. Grosso modo, un fichier VectorDrawable est une image qui peut être agrandie ou rapetissée sans perdre d’informations. Ainsi, avec un seul fichier, on a toutes les tailles d’icônes dont on a besoin. Autrement dit, au lieu d’avoir, par exemple, cinq fichiers différents pour cinq tailles d’icônes, vous les réunissez toutes en un seul endroit.

Attention, il existe un mécanisme similaire sur iOS, mais plusieurs sources m’ont indiqué que celui-ci était moins bien pensé et intégré que le VectorDrawable.

Les bibliothèques

Ludovic Roland, développeur Android ayant « une connaissance théorique » d’iOS, souligne l’influence des bibliothèques embarquées par une application sur son poids. Ces dernières permettent d’ajouter de nombreuses fonctions : indiquer le taux d’audience aux développeurs, envoyer des pushs, afficher de la publicité…etc.

Des bibliothèques, il en existe sur les applications Android comme sur iOS. Mais, il suffit que le poids de chacune d’entre elles varie d’une petite centaine de kilooctets pour, qu’au final, par addition, on obtienne des volumes très différents entre iOS et Android. Au vu des résultats que nous avons observés dans le tableau plus haut, on peut supposer que les applications installées sur l’iPhone 7 ont des bibliothèques un peu plus lourdes que sur celles des autres terminaux.

Ce qu’il faut retenir

Il existe très certainement tout un tas d’autres raisons qui expliquent les différences de poids entre les applications Android et iOS et nous n’avons sans doute pas pu toutes les citer.  Par ailleurs, il ne s’agit pas d’une science exacte — parfois des applications sont plus lourdes sur l’OS de Google. Ce qu’il faut retenir, c’est qu’en plus d’utiliser un langage de programmation bien adapté, l’environnement de développement sur Android propose plusieurs combinaisons qui, intelligemment exploitées, peuvent réduire drastiquement le poids d’une application.

En contrepartie, la gestion d’une application Android est globalement plus complexe que sur iOS ce qui rend le suivi plus difficile. Par ailleurs, le système d’exploitation d’Apple est réputé pour être plus sécurisé, mais en attendant, Romain est toujours contrarié par le volume imposant de son application Facebook…

Merci à tous les développeurs qui ont accepté de me répondre, et tout particulièrement à Edouard Marquez, RxVincent, Antoine Kuhn et Ludovic Roland.