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 !
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 7 | Honor 9 | Huawei P9 | Samsung Galaxy S8 | |
|---|---|---|---|---|
| 211 Mo | 177 Mo | 177 Mo | 177 Mo | |
| Chrome | 60,6 Mo | 168 Mo | 168 Mo | 168 Mo |
| 114,6 | 91,58 Mo | 87,81 Mo | 88,62 Mo | |
| Trainline | 34,8 Mo | 19,36 Mo | 19,37 Mo | 19,32 Mo |
| Netflix | 66,7 Mo | 54,47 Mo | 51,10 Mo | 50,93 Mo |
| YouTube | 83,8 Mo | 63,29 Mo | 63,31 Mo | 72,36 Mo |
| 102,6 Mo | 51,55 Mo | 50,39 Mo | 50,44 Mo | |
| LeMonde.fr | 37,9 Mo | 22,04 Mo | 26,48 Mo | 22,01 Mo |
| 73,4 Mo | 58,93 Mo | 58,07 Mo | 57,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é.
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, à 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.
Votre café et votre dose de tech vous attendent sur WhatsApp chaque matin avec Frandroid.
Ce n'est pas Proguard qui fait ça mais le compilateur. Et c'est le cas sur toutes les plateformes.
[…] en sorte que leurs terminaux soient toujours compatibles les uns avec les autres — une aubaine pour les développeurs. Autrement dit, c’est en grande partie grâce à l’AFA qu’une application mobile peut […]
[…] en sorte que leurs terminaux soient toujours compatibles les uns avec les autres — une aubaine pour les développeurs. Autrement dit, c’est en grande partie grâce à l’AFA qu’une application mobile peut […]
[…] but est de permettre à une personne de découvrir une application sans avoir à sacrifier de l’espace de stockage et d’utiliser celle-ci pour une fonctionnalité bien précise sans avoir à s’encombrer […]
J'ai vu des applications Android super belles aussi.
Perso je sais pas developper. Je suis nul en ça !
Bravo! Cet article est très intéressant, très bien écrit, dans le style, l'orthographe, la grammaire, la ponctuation, ainsi que pour le fond . Bravo à Omar ainsi qu'aux éventuels relecteurs.
[…] 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 avo…Source […]
[…] 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 avo…Source […]
Un oubli significatif par rapport à ProGuard : il ne se contente pas de réduire les tailles des noms de classes, méthodes, etc. Il fait aussi disparaître tout le code inutile, y compris dans les librairies. Du coup, si on importe une librairie de plusieurs Mo pour n'en utiliser qu'une ou deux classes, ça n'est pas gênant : toutes les classes inutiles seront supprimées au moment de l'optimisation par ProGuard pour ne garder que les quelques ko nécessaires et pas tous les Mo de départ qui sont économisés par rapport à iOS.
Bel article !
Sur mon iPhone SE, application Message, ça ne marche pas ton "balayer l'écran" à tous les coups il faut balancer le pouce au point le plus éloigné
il doit avoir gardé son iPhone 4 avec les même arguments d'achat de l'époque
Comprends pas trop le passage de l'IA mais bon
Honor, il faut un convoyeur de fond pour tout encaisser !
Je sais parfaitement de quoi je parle.
Merci pour cet article, j'ai appris bcp de choses.
Euh la plupart des applis sont entièrement recodées pour Android, j'en connais pas qui viennent directement d'appli iOs, même si je sais que ça existe
Hélas oui, quand on met autant d'argent pour développer une compétence, statistiquement, on fini par plus s'y impliquer. Il y a aussi le facteur "Passion Apple" qui entre en compte. Mais ce n'est qu'une généralité selon moi, cela n'implique évidement pas tout le monde (moi même je code pour iOS et je n'ai jamais acheté de Mac pour autant). Sinon 10k€ pour un Mac faut pas déconner :D et puis comme c'est l'argent de ton chef, et pas le tien, ça ne marche pas ^^. Cependant je ne suis pas d'accord avec ta conclusion, elle est en partie vrai sur la prise en main plus rapide sur iOS, mais en réalité cette facilité de prise en main se paye au prix d'un code design mauvais et donc d'une évolutivité plus difficile. A l'opposé sur Android, la prise en main est bien plus difficile mais c'est pour permettre la mise en place d'un code design plus élégant et au final plus évolutif. Cependant, pour en arriver là, il faut déjà avoir affaire à un dev Android qui a quelques années d'XP.
Euh.... OK
En aucun cas l'iPhone 6 souffre d'un manque de mémoire. Au contraire,un iPhone 5s et 6 marche très bien,tu ne sais pas de quoi tu parles.
Il faut dire que chez Apple, ils sont aussi eu leur période pipi-caca, et tout en haut de l'échelle en plus. :p https://www.igen.fr/app-store/il-pete-il-pisse-mais-il-travaille-chez-apple-12601
C'est tellement vrai, les développeurs ne comprennent pas des choses simples alors que les utilisateurs finaux attendent d'eux des objets connectés et applications qu'ils fonctionnent comme une cafetière de base, et les utilisateurs finaux ne comprennent pas que les développeurs ne les comprennent pas. Du coup les développeurs aiment les intelligences artificielles car ils les maîtrisent, ils leur font faire ce qu'ils veulent et sont à leur image; chose qu'ils sont incapables de faire dans la vraie vie car ils ne comprennent pas la complexité des relations humaines.
Mais non voyons ,puisque les fanboys de steevou te le disent, ios est très simple voyons , c'est la panacée universelle. En plus on peut même changé le fond d'écran. Comme dis Lemaître ton patron est un neuneu cétou . En fait Lemaître a raison aussi a propos de ses collègues disciple pommé (paumé ?), ils sont neuneu. C'est bizzare des que ça rentre pas dans la case marketing bidon les gens sont neuneu . lol
Ta réponse aurait du sens si la mémoire n'était pas une denrée si chère chez Apple. Les seuls qui s'en "foutent" sont ceux qui ont les moyens d'acheter un 64 ou 128 go.
Pas plus stupide que la tienne dépourvue de tout raisonnement et argumentation.
"Après si tes potes sont des neuneus ça c'est autre chose!" => Ha ! La fameuse défense "c'est pas la faute de l'iPhone, c'est juste eux qui sont cons !", elle n'a rien à envier à la défense Chewbacca...
Ceci explique cela. Ceci explique aussi pourquoi j'ai viré les applications comme Facebook et YouTube parce que je me suis dit qu'on n'a pas besoin de ces applications quand on a déjà un navigateur Internet comme Chrome ou Opera qui suffit largement...
Joli résumé de tous les commentaires stupides que peuvent publier les fans d'Apple sur le sujet !
Amazing ce que peut faire le marketing! Donc pour envoyer une photo d'un smartphone à un autre il faut obligatoirement passer par un ordinateur. Et oui j'ose les comparer puisque un Galaxy S2 sous nougat marche très bien contrairement à l'iPhone 6 qui souffre du manque de mémoire vive. J'ai fait une remarque sur les problèmes de performence sur l'iPhone 6 donc il faut me répondre sur cette question.
Et surtout Honor ! Mais là, ça n'aurait pas été une blague ..
Galèrer à transférer la musique, les photos? Mdrrr Là aussi rien de plus facile ^^. Pour la photo, tu branches ton iphone Sur l'ordinateur et il est reconnu comme n'importe quel appareil photo, avec le dossier photo facilement accessible. Pour la musique, la synchronisation est aussi très simple à faire. Après si tes potes sont des neuneus ça c'est autre chose! Franchement il oser ? Comparer l'iPhone 6 a un galaxy S2, il faut le faire! T'es un champion mec ?
J'avoue je connais pas bien iOS mais je vois mes amis galérer à transférer la musique, les photos...et pour revenir en arrière il faut bien gesticulée le doigt dans tout les sens, le multitâches faut appuyer plusieurs fois. Et là quantité de RAM a un impact sur Ios et t'as pour exemple l'iPhone 6 contrairement à un Galaxy S2 sous nougat.
N'importe quoi! Ta réponse montre que tu connais pas vraiment le fonctionnement de ios. Pour retourner à la page précédente, rien de plus facile: il suffit de balayer l'écran vers la gauche. Sur ios la Ram n'a que peu d'impact sur le multitâche. Donc 1GO de Ram n'est ne aucun cas un handicap. C'est incroyable votre méconnaissance de ios. Les Apps Google illustrent mes propos concernant la qualité des Apps ios par rapport à celle d'Android. Comparé les Apps Google ios aux versions android et tu verras rapidement la différence.
Pas forcément, les apps dont l'interface utilisateur est basée sur Material Design sont magnifiques. Sinon pour l'ergonomie t'es vraiment à côté de la plaque, pour retourner à la page précédente il faut gesticulée le doigt dans tout les sens ou appuyer fort sur l'écran est c'est un désastre, et j'aimerais bien que tu m'explique comment iOS 11 va prendre l'avantage avec un iPhone 5s ou 6 et leur 1go de RAM. Et n'oublie pas que Android O est aussi en préparation, et si tu est un peu honnête tu diras que nougat est plus rapide et stable qu'ios 10.
"développer sur iOS doivent faire un investissement plus lourd et réfléchi ce qui, naturellement, pousse les développeurs à plus s'impliquer dans leur passion et donc de mieux coder au final" => ca m'a bien fait rire ... donc en gros plus l'investissement coute cher, plus le développeur code bien ? je devrais proposé à mon chef de me prendre un nouvel ordi a 10 000€ et lui donner ton commentaire comme argument :P Je suis certain qu'il va me dire qu'il a jamais vu un argument aussi nul ;p Bon le reste de ton argumentation n'est pas fausse le chef veut un truc simple et cher => il prend un iphone... les clients iOS sont moins "pauvre" il n'est donc pas rare de faire une appli payante sous iOS et seulement une fois que le projet a remboursé une part importante des couts de sortir une version android (moins cher ou pire gratuite avec pub) sous iOS il n'y a pas autant de fragmentation, tu gère quelques appareils, alors que sous android ... le SDK sous iOS est aussi plus facile à prendre en main, tu peux faire une appli pro bien plus facilement, sous android tu dois prendre bien plus de temps (mais ce temps est aussi gagné car tu code en java et que tout les étudiants ont deja codé du java :P )
https://uploads.disquscdn.com/images/a17863761794ae8ede1a47e3fdb1cd51a6dd4e4185f282990374e4b94b0ee173.jpg
Les Apps ios sont meilleures, graphiquement avec des interfaces plus jolies, plus ergonomiques, techniquement mieux codées. En multitâche, ios11 va clairement prendre l'avantage.
Très bon sujet
Un autre article qui constate la même chose ( sans aller aussi loin niveau l'explication ) : https://trevore.com/blog/posts/app-sizes-are-out-of-control/
Les applications iOS sont mieux finies que celle sur android, laisses moi ? J'utilise les deux systèmes et je trouve les apps sur mon S7 plus rapides, reactives, faciles d'utilisation et surtout sur Android on a un vrai multitâches qui ne met pas les applications en pause dès qu'on les quitte.
C'est très intéressant comme article ; il répond à une question que je me posais depuis longtemps. Vous devriez faire des dossiers de ce genre plus souvent, bravo !
C'est plus rentable pour Apple que les applications prennent plus de place. Si tu en veux beaucoup il faudra passer à la caisse pour avoir un iPhone de grande capacité. Bien sur le prix est en fonction vu que l'on ne peut pas mettre de micro SD.
J'ai aussi trouvé ça tordant. Il manquait évidemment OnePlus dans la liste :D
"Alors que nous abordions la question de l’encaissement des derniers chèques envoyés par nos amis Samsung, Google, Apple" hahaha bravo blague de l'année.
Je vais te donner une réponse simple, quand on bosse en SSII coder sur iOS fait plus "vendeur" vis-a-vis des clients. Ensuite quand tu bosse dans une boite qui fait son propre produit, souvent les boss utilisent des iPhones du coup, instinctivement, c'est pas là que l'on commence. Pour terminer, une application n'est pas mieux fini sur iOS que sur Android c'est une fausse impression dû à la combinaison de 2 facteurs. Pour commencer, développer sur Android est plus compliqué que sur iOS car Google pondu un SDK bien plus évolué et élégant dans son design. Parfois c'est une bonne idée comme les RecyclerView ou Dagger2, parfois c'est complètement incompréhensible comme les Loaders. La 2ème raison est que n'importe qui peut développer sur Android, Android Studio est compatible Mac, Linux, Windows et tout le monde peut avoir un Android sous la main. A l’opposé ceux qui veulent développer sur iOS doivent faire un investissement plus lourd et réfléchi ce qui, naturellement, pousse les développeurs à plus s'impliquer dans leur passion et donc de mieux coder au final. Cependant ces 2 facteurs s'annulent dès que les années d'expérience s'accumulent.
Oui, tu as raison. Pour être tout à fait exact, "la JVM" d'Oracle (anciennement Sun), c'est HotSpot. En ce sens, DVM et ART sont bien des JVM.
"la plupart des développeurs privilégient de coder leur appli d'abord sur iOS" c'est typiquement le genre de généralité sortie de nulle part et fondée sur aucune statistiques viables. En plus t'as l'air coincé 5 ans dans le passé la. wake up.
Cependant tu as raison, la phrase porte a confusion sans pour autant être fausse. Pour être exact, on devrait parler de "précompiliation" quand on passe de JAVA/Kotlin en Bytecode. Ensuite quand le code arrive sur la machine ART, il est compilé contrairement à la JVM qui l’interprète à la volé, a moins que ca ait changé les dernière années, j'ai pas suivit.
Désolé, mais dès que je vois écrit WinDev quelque part, je peux pas m'empêcher d'avoir des pensées érotiques :-° . Plus sérieusement, détrompe-moi, mais je ne crois pas que le passage de GCC à LLVM a une incidence tellement significative sur la taille des binaires. D'après cet article, ça a même tendance à diminuer légèrement leur taille (mais ça ne semble pas significatif) : https://retro-freedom.nz/clang-vs-gcc-binary-size.html .
Pour moi ART et Dalvik sont des JVMs. Par contre j'avais oublié que le code intermédiaire Android était différent de celui d'un classique .class obtenu avec la commande javac par exemple. Merci pour votre commentaire en tout cas.
Désolé, ça va être un peu technique, mais sous Android, ce n'est pas la JVM qui tourne mais ART (anciennement la DVM). ART et la DVM n'interprêtent pas le même bytecode que la JVM (.class), mais un autre bytecode, le DEX (avec une petite subtilité pas intéressante pour ART, qui précompile le DEX en OAT pour des raisons d'optimisation ; c'est notamment pour cette raison que les développeurs n'ont pas eu besoin de recompiler toutes les applications au moment de la migration de Dalvik à ART). Dans le .class comme dans le DEX, on peut retrouver effectivement des références au nom des classes, des variables, des ressources originales. On peut s'en rendre compte simplement en ouvrant un dex avec un éditeur hexadécimal. Proguard obfusque tout ça, ce qui a effectivement pour effet de diminuer la taille des fichiers.
Tous les commentaires sur ce sujet sont vraiment intéressants...sauf le tien ? PS : je suis d'accord pour l'appli
Concernant Swift, il faut aussi préciser que c'est un choix délibéré d'Apple. Comme le langage change encore beaucoup et souvent, ils auraient dû inclure dans l'OS un grand nombre de versions du runtime. Pour éviter cela, ils ont choisi donc d'inclure le runtime avec l'app, ce qui garantit qu'elle fonctionnera dans le futur. Le runtime ne sera donc inclut dans l'OS que le jour où Apple considérera Switch comme stable. Swift est clairement le langage du futur pour Apple, mais Obj-C n'est de loin pas mort. A son sujet d'ailleurs, on pourrait aussi parler du passage de gcc à LLVM. Un point est par contre oublié dans l'article, ce sont les environnements permettant aux devs de limiter le travail de portage (type Xamarin ou WinDev pour n'en citer que 2). Ces environnements utilisent aussi un tas de librairies, qui n'ont pas nécessairement la même taille sur les deux OS.
Malgré cela, il n'empêche qu'un constat reste à expliquer : pourquoi la plupart des développeurs privilégient de coder leur appli d'abord sur iOS et se contentent de la porter sur Android sans tout recoder ? Il n'empêche qu'au final les applis iOS restent mieux finies que leur équivalent sur Android. Et peu importe la quantité de mémoire que l'appli occupe, le plus important c'est le résultat final, et je préfère de loin que l'appli occupe plus de mémoire si ça lui permet d'être plus réactive, plus intuitive et plus belle ! Enfin, la pub gratuite pour une appli de canasson ça n'a rien à faire ici.
> Or, l’avantage de Kotlin c’est qu’il est compilé dans le même langage que Java Je n'aime pas trop la tournure de cette phrase. Java est un langage compilé puis interprété c'est-à-dire que le fichier .java est d'abord compilé et réduit à un code intermédiaire le .class. C'est ensuite le .class, qui contient des instructions compréhensibles par une Java Virtual Machine (JVM), qui est interprété par une JVM. La JVM va, à la volée, transformer les instructions contenu dans le .class en instruction que la machine sur laquelle s'exécute la JVM comprend. Kotlin est donc compilable en un .class qui peut être interpreté par une JVM (c'est aussi le cas de Jython, le "côté Java" de Python). > réduire leur nom aussi court que possible Je ne comprend pas ce passage. Est-ce que le code source (le .java) d'une application est contenu dans un apk ? Si oui alors je comprend que réduire la taille des noms des variables, fonctions, etc. permet de réduire la taille du fichier .java et donc de l'apk. Après le .class doit aussi contenir une table des symboles (tableau listant notamment toutes les variables rencontrées ainsi que leurs adresses, leur portées, leurs types, etc.) donc dans ce cas si on a des petits symboles (i.e. nom de variable court) alors la table des symboles sera un peu plus petite.
Ce contenu est bloqué car vous n'avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Disqus.
Pour pouvoir le visualiser, vous devez accepter l'usage étant opéré par Disqus avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l'amélioration des produits d'Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l'audience de ce site (en savoir plus)
En cliquant sur « J’accepte tout », vous consentez aux finalités susmentionnées pour l’ensemble des cookies et autres traceurs déposés par Humanoid et ses partenaires.
Vous gardez la possibilité de retirer votre consentement à tout moment. Pour plus d’informations, nous vous invitons à prendre connaissance de notre Politique cookies.
Gérer mes choix