L’évolution des applications mobiles passe par celle de leur poids. Bien que cette valeur ait désormais moins d’importance, elle atteint chez certains éditeurs des chiffres qui interpellent. Accompagnés de développeurs, revenons sur ce phénomène et les contraintes du monde mobile.
Vous êtes-vous déjà demandé pourquoi le poids des applications avait tendance à augmenter, voire à s’envoler ? Avez-vous pesté contre des mises à jour qui, du coup, amenaient l'appareil à réclamer une connexion Wi-Fi ? Nous aussi.
Depuis plusieurs mois, nous suivons en particulier l’évolution de quelques applications mobiles, dont le poids ne cesse de grandir, sans que l’on sache vraiment pourquoi. Nous nous sommes penchés sur ce mystère, pour comprendre s’il s’agissait d’une tendance inéluctable, ce qui pouvait bien amener cet embonpoint et ce qu’en pensent les développeurs.
La question du poids renvoie vers celle du paradigme des applications mobiles, de ce qu’elles sont aujourd’hui et de ce qu’elles pourraient être demain. Des entretiens avec des développeurs nous ont permis de comprendre ces choix.
Facebook, par qui le scandale arrive
L’application mobile Facebook a servi de point de départ. Au cours des six derniers mois, nous nous sommes rendus compte que son poids avait augmenté de manière particulièrement importante. Sur iOS, elle dépasse ainsi les 200 Mo depuis longtemps, et se situe aujourd’hui autour des 230 Mo sur un iPhone 7. La précision de l’appareil est importante car, comme nous le verrons plus tard, la taille change en fonction des caractéristiques techniques. Sur Android, le fonctionnement est similaire.
Ces observations soulèvent des questions, dont la principale est évidente : qu’est-ce qui peut bien justifier une telle envolée ? Après tout, on ne parle pas d’un jeu, il n’y aucune problématique de textures et l’application n’a pas vocation à fonctionner hors-ligne. Pourquoi réclamer tant d’espace quand l’objectif est essentiellement d’afficher un flux constitué de texte, photos et vidéos ?
Début avril, un développeur s’est justement posé la question. Alexandre Colucci, qui travaille chez Elgato à Munich, s’est ainsi penché sur le paquet IPA (format des applications iOS) de l’application Facebook, alors en version 87 (nous en sommes à la 94). Il a publié un billet de blog pour expliquer ses trouvailles, effectuées via le logiciel Mac GrandPerspective.
Après analyse, il est surtout ressorti que la taille du binaire (la partie exécutable) n’avait cessé de se réduire avec le temps. Dans la version 87, elle ne comptait plus que pour 19 Mo, sur un total d’alors 253 Mo. D’où vient le reste dans ce cas ? Des frameworks et autres SDK (Software Development Kit). Par exemple, le SharedFramework compte à lui seul pour 136 Mo, soit plus de la moitié.
L’analyse révélait également que nombre d’éléments étaient en double ou en triple. On trouvait ainsi de nombreuses ressources dupliquées, parfois même jusqu’à six fois, comme le fichier sent.m4a. Il ne pèse seul que 150 ko, mais répété à ce point, on atteint presque le mégaoctet. Le fichier modelMetaData.bin pèse pour sa part 1 Mo, et est répété quatre fois. On atteint donc vite plusieurs dizaines de mégaoctets.
Colucci indiquait d’ailleurs que le ménage pouvait être fait rapidement, Facebook ayant moyen d’économiser ainsi 40 Mo sur le poids de son application. Le développeur notait toutefois qu'il avait grimpé de 90 Mo entre les versions 66 et 87, ce qui s’explique en partie par un manque criant de « ménage ». Notez toutefois que l’entreprise a manifestement eu vent de ce billet de blog, largement été repris par la presse. La version 88 a fondu de 24 Mo, pour s’établir à 229 Mo, presque autant que l'actuelle version 94.
De la valeur d’un mégaoctet
Nous nous sommes entretenus avec Alexandre Colucci au sujet de cette application, et plus globalement du problème de taille. Développeur Mac depuis 2001 et iOS depuis la première version du système mobile, il nous a donné quelques pistes pour comprendre les contraintes auxquelles font face les développeurs aujourd’hui, ou les choix qui peuvent parfois être effectués.
« La taille d’une application peut rapidement grandir, surtout sur iOS. Rien que les ressources graphiques peuvent déjà consommer beaucoup de place » nous explique-t-il. Un point souligné également par Jean-Baptiste Kempf, président de VideoLAN et développeur principal de VLC. Il faut ainsi prévoir des images en PNG en trois tailles différentes pour chaque élément, pour s’adapter à la définition des appareils mobiles. Kempf ajoute à ce sujet que l’absence de support du SVG (images vectorielles) par Apple « est un vrai problème ».
D’autres points sont à prendre en compte. « Par exemple, les binaires 32 et 64 bits sont réunis au sein du même IPA, ce qui donne parfois de grosses répétitions de code. Certains éditeurs vont aussi intégrer des frameworks dont ils n’utilisent que quelques fonctions, sans pouvoir s’en passer. Il faut également savoir que si une application doit prendre en compte de vieilles versions du système, les développeurs doivent tout créer par eux-mêmes car les API ont peut-être disparu. Le souci est le même sur Android et iOS » nous explique ainsi Alexandre Colucci.
Frameworks et contraintes multiplateformes
Se pencher sur le poids des applications revient immanquablement à analyser les choix techniques, qui eux-mêmes découlent de nombreux critères. Les décisions prises dépendent en effet des contraintes liées au développeur. La taille de l’entreprise, les dates de publication et le type d’informations à diffuser sont également des variables.
La taille de l’entreprise, par exemple, peut ainsi aboutir à la répartition du travail sur plusieurs équipes. Ici, Jean-Baptiste Kempf jette un regard critique : « Il arrive souvent que les équipes ne communiquent pas vraiment entre elles. Pour moi, c’est de la désorganisation, avec l’utilisation d’éléments en plusieurs exemplaires. Du coup, tout est réuni dans un framework et voilà » nous indique ainsi le président de VideoLAN.
Il compare la situation avec le travail mené sur VLC. « La version 2.0.6 pesait 23 Mo. Quatre ans plus tard, on en est à 28 Mo. On a une croissance en termes de poids qui reste assez légère ». Pourquoi une telle différence de taille avec d’autres applications ? « Parce que souvent, chaque équipe y va de son framework et ajoute des packet managers de type Node.js. Il y a beaucoup aujourd’hui d’applications qui utilisent React Native [proposé par Facebook, ndlr] et autres technologies du web. Il faut interpréter tout ça, donc on ajoute un moteur JavaScript et d’autres composants, donc ça consomme énormément » nous précise-t-il, avant d’asséner : « Chacun fait son travail dans son coin. Mais si tout le monde fonctionne comme ça, on ne s’en sort jamais ».
Le développement multiplateforme semble être la plupart du temps à l’origine de certains choix technologiques, comme l’utilisation de frameworks qui évitent de réécrire du code pour chacune d'elles. Le prix à payer est le poids de l’application, mais leur utilisation fluidifie nettement le travail des développeurs.
L’espace de stockage n’est plus une contrainte, mais…
Le coût des frameworks et les spécificités de chaque plateforme sont bien présents dans l'équation, mais ils ne provoquent pas partout un haussement d’épaules pour autant.
Florent Santin, développeur et directeur technique chez Infinite Square, nous explique ainsi comment le poids des applications a suivi la tendance des espaces de stockage et de l’accélération des débits via les connexions 3G/4G. Ils nous confirment que les frameworks sont devenus une clé de simplification du développement, mais que « tout dépend de ce que l’on veut faire ».
« Nous sommes des enfants gâtés de l’espace de stockage » résume-t-il, réaliste. « Avant, on apprenait à optimiser le poids des images pour réduire la bande passante, mais beaucoup ne le font plus, sans parler des contraintes liées à chaque plateforme. Parce que oui, aujourd’hui on fait majoritairement du développement multiplateforme, mais ça ne veut pas dire qu’on ne contrôle pas le poids » lance-t-il en avertissement.
Il nous pointe en effet une importante barrière qui peut avoir un impact très lourd sur le succès d’une application : le plafond autorisé de téléchargement depuis une connexion cellulaire. Tant Android qu’iOS imposent une limite de 100 Mo au poids des applications. Passé ce nombre, le système réclame une connexion Wi-Fi.
… le poids d’une application peut devenir un argument de vente
Or, comme nous l’indique Florent Santin, cette frontière a un impact direct sur le succès d’une application. Il ajoute ainsi que des efforts spécifiques sont consentis pour laisser les applications sous la barre des 100 Mo, même si en pratique ce plafond n’est pas aussi strict. iOS par exemple laisse quand même se télécharger une application de 150 Mo sur une connexion 3G/4G. Aller plus haut cependant peut avoir des conséquences lourdes.
Un point sur lequel Guillaume André, développeur indépendant et consultant, abonde particulièrement : « J’ai un client dont le nombre de téléchargements a chuté de 50 % en passant cette barrière ». Une illustration concrète du type de problème que peut provoquer un poids trop important.
D’ailleurs, si le poids ne comptait plus, Facebook n’aurait pas lancé un Messenger Lite sur Android. Une application qui ne pèse que 10 Mo au téléchargement, et 16 Mo une fois installée. Pourquoi ? Parce que tous les pays ne disposent pas d’un environnement mobile aussi sûr que celui du monde occidental. Les smartphones n’y ont pas forcément de grandes quantités de stockage, les connexions n’y sont toujours pas rapides, et les forfaits data ne permettant pas nécessairement de télécharger toutes les applications.
Une question délicate d’équilibre
Il serait simple d’affirmer que plus le poids est faible, mieux l’utilisateur se porte. Il faut cependant tenir compte de certains aspects, car le poids indiqué d’’une application n’est pas forcément la seule donnée à prendre en compte.
Il est tout à fait possible que cette taille soit rapidement augmentée par la suite par les données téléchargées après l’installation. Il y a alors principalement deux chiffres à prendre en compte : celui de l’application, et celui du cache. Ce dernier contient toutes les données enregistrées notamment pour accélérer le chargement au prochain accès, comme les photos dans les messageries.
Mais un éditeur peut aussi choisir de rapatrier de cette manière des données obligatoires supplémentaires. Par exemple, un jeu qui récupèrerait des textures pour les niveaux suivants. Mais dans ce cas, comme nous le précise Philippe Desgranges, cofondateur et PDG de Mana Cube, les frais de distribution sont à sa charge (via ses propres serveurs). Les boutiques prennent en effet 20 à 30 % des gains générés par les ventes (applications et achats in-app), mais assurent en contrepartie tous les frais liés à l’infrastructure de distribution, tant pour le téléchargement initial que pour les mises à jour.
Il ajoute qu’il existe en fait tout un travail préparatoire pour bien mesurer les besoins. On retrouve ainsi un curseur qui se déplace entre une installation directe via 3G/4G et les frais de diffusion quand les données ne proviennent plus de la boutique. En clair, vaut-il mieux par exemple proposer un jeu de 500 Mo contenant tout, ou un titre de 90 Mo qui aura besoin de récupérer régulièrement des données supplémentaires ?
Comme l’ajoute Philippe Desgranges, il y a d’autres points à prendre en compte. « On peut proposer un jeu qui contient déjà tout et ainsi réduire les frictions par la suite. Mais selon la quantité de stockage sur l’appareil, l’utilisateur va peut-être chercher ce qui consomme le plus de place et supprimer le jeu s’il ne l’utilise pas assez » nous explique-t-il.
Se faire une place au soleil
Même en tenant compte des contraintes, il semble dans tous les cas que chercher à réduire autant que possible le poids des applications soit une quête nécessaire. Tous les éditeurs n’en perçoivent pas forcément l’importance. Pourquoi les grosses entreprises semblent elles ainsi particulièrement négligentes sur ce point ?
« Quand on possède quatre applications dans le top 10 et qu’on est déjà considéré comme incontournable, c’est qu’on joue dans une autre division et qu’on n’a clairement pas les mêmes problématiques » affirme Guillaume André. L’exemple désigne Facebook, qui en plus d’avoir une application du même nom, propose Messenger, Instagram et WhatsApp. Un quatuor utilisé par des centaines de millions de personnes.
Il insiste : « Il y a de vraies problématiques de visibilité pour les nouveaux arrivants », qui auraient donc de nombreux efforts supplémentaires à fournir pour espérer rencontrer le succès. De là à dire que les gros éditeurs deviennent feignants avec le temps, il n’y a qu’un pas… que nous ne franchirons pas, mais certains chiffres parlent d’eux-mêmes.
Le client officiel Twitter pèse ainsi 120 Mo sur un iPhone 7, quand le client tiers Tweetbot, dont les fonctionnalités ne sont limitées que par l’API officielle, se limite à… 7,5 Mo. Le tout avec une réactivité et une fluidité d’interface largement supérieures. OneDrive fait lui aussi 120 Mo, Snapchat 115 Mo, Dropbox 112 Mo, Outlook 105 Mo, Google Photos 100 Mo, WhatsApp 90 Mo… Il s'agit bien des tailles des applications installées, et non celles des IPA qui peuvent être beaucoup plus conséquentes, puisqu'ils contiennent toutes les versions (32/64 bits, tailles d'écrans...).
Et si ces tailles sont séparément importantes, il ne faut pas oublier que l'utilisateur en a plusieurs sur son smartphone, souvent d'ailleurs plusieurs dizaines. De fait, le problème ne fait que prendre de l'ampleur lors d'une session de mises à jour, quand plusieurs reçoivent une nouvelle version. Le téléchargement complet peut alors dépasser 1 ou 2 Go, un comportement qui semble être devenu habituel, comme une fatalité. On peut ainsi récupérer des données bien plus volumineuses sur un smartphone que sur un PC pour rester à jour.
Il n’existe bien entendu aucune taille de référence, mais si l’on compare les champs fonctionnels de ces applications, certaines nous paraissent clairement tirer un peu sur la corde. Dans le seul domaine des messageries, les 90 Mo de WhatsApp peuvent paraître importants, mais sont loin derrière les 156 Mo de Messenger. À titre de comparaison, Telegram ne pèse que 42,6 Mo, et Signal tout juste 30 Mo. Ces applications ne permettent-elles pas pourtant elles aussi des discussions texte et des appels audio ?
Pour Guillaume André, dans le cas de Facebook, le poids peut même devenir une arme : « Si des utilisateurs considèrent ces applications comme essentielles, ils ne se tourneront pas vers elles quand il faudra faire du ménage sur le smartphone ». Ce sont donc d’autres applications, moins utilisées, qui subiront le ménage.
Les technologies du web à la rescousse ?
Ces technologies sont connues et n’ont rien dans l’absolu de très nouveau. Le HTML5, le JavaScript, les CSS et autres peuvent déjà être utilisées pour la conception des applications. Cependant, et comme on l’a déjà vu, elles sont nécessairement accompagnées de frameworks et moteurs afin qu’elles puissent fonctionner une fois l’application installée.
C’est l’une des approches suivies par exemple par Florent Santin : « On utilise principalement Cordova, qui va nous permettre de générer 95 % de code identique pour toutes les plateformes. Les 5 % restants, ce sont des plugins natifs pour servir de passerelles ».
Et si ces technologies étaient interprétées directement par le système comme des applications web ? C’est bien ce que pousse Google avec ses Progressive Web Apps : leur donner les mêmes capacités que les applications natives, notamment au niveau des interactions avec le smartphone et le matériel.
La vision du développeur dans ce domaine est très claire : « D’ici les deux prochaines années, la notion d’application va évoluer, voire disparaître. Elle n’a plus aujourd’hui beaucoup de sens ». Pourquoi ? « Parce que les besoins d’offline ont beaucoup diminué avec les connexions 3G et 4G » nous répond-il. « Ça nous autorise une hyperconnectivité qui change la donne, et l’application classique n’apporte plus rien » renchérit-t-il.
Cela étant, s’il s’agit d’un mouvement largement poussé par Google, le monde mobile ne se limite pas à Android. Apple aura nécessairement son mot à dire, et on ne peut pas dire qu’iOS ait fait un pas dans cette direction jusqu’à présent. Pour Guillaume André, il est évident qu’Apple finira par réagir, « sinon Android risque de prendre de l’avance ».
Oui il existe bien un souci de taille des applications
Le problème existe, ne serait-ce qu’à cause des conséquences si les développeurs ne surveillent pas l’embonpoint de leurs créations.
L’augmentation des espaces de stockage et les meilleures performances des connexions permettent très clairement une amélioration qualitative de l’expérience utilisateur. Elles ne doivent cependant pas devenir des prétextes au manque d’optimisation qui semble concerner le plus souvent les plus gros éditeurs, qui ont moins à prouver.
Dans le cas de Facebook, il n’existe que des pistes de compréhension. Tous les développeurs interrogés se sont dit « impressionnés » par le poids et la composition massive de l’application, et s’accordent sur l’idée d’un régime qui serait bienvenu. Le problème se pose d’ailleurs d’autant plus que Facebook publie des mises à jour très régulières, qui nécessitent du coup une connexion Wi-Fi puisque dépassant allégrement le plafond autorisé.
Nous avons également posé ces questions à l’éditeur, mais nos requêtes sont restées sans réponse. Le problème aurait sans doute été le même avec toutes les autres grosses entreprises, puisque réagir sur cette thématique reviendrait à se justifier. Pourtant, il serait justement intéressant qu’ils expliquent les 100 à 250 Mo de leurs applications qui, pour la plupart, ne sont que des structures pour afficher des informations distantes.
Des centaines de mégaoctets sans dire pourquoi
Le manque d’optimisation est parfois flagrant et nous parait d’autant plus dommageable qu’il peut rejaillir de manière très négative sur l’expérience utilisateur. La puissance des appareils haut de gamme se retrouve alors en partie absorbée pour compenser. Quant à celle des appareils moins performants, elle est parfois insuffisante selon les applications pour fournir une expérience fluide.
Sans parler alors de nivellement par le bas, le cas Messenger Lite nous parait intéressant à plus d’un titre. Que l’un des plus gros éditeurs de la planète dédie une version de son service aux faibles connexions nous parait un signe engageant que rien n’est perdu pour autant. Il sera d’ailleurs particulièrement intéressant de voir la réaction de Facebook si cette version Lite devait avoir plus de succès que la version classique.
En attendant, les connexions Wi-Fi resteront obligatoires pour une partie des applications. Certains continueront de pester contre la limite imposée par les Store, mais au vu de l’état des lieux, ce plafond aurait-il intérêt à être augmenté ? Les éditeurs pourraient dans tous les cas commencer par indiquer pour chaque version ce qui a changé. Dans le cas de Facebook, proposer jusqu'à une fois par semaine un téléchargement de plusieurs centaines de mégaoctets sans dire pourquoi nous semble assez ubuesque.
Commentaires (60)
#1
Quand je pense qu’on arrivait à faire tourner la caisse d’épargne de Toulouse et ses 80 agences en ligne avec 512mo de mémoire et je ne sais plus trop combien de meg de disques !
" />
#2
Dans le même genre sur PC, on a les pilotes Nvidia avec leurs gentils 500Mo…
#3
en plus j’ai dit une connerie par habitude " />
c’était 512ko
#4
insère sa x-ème disquette pour installer Dune " />
#5
J’ai oublié : excellent article !
#6
Bel article, bravo !
Pour info, l’appli telegram du f-droid fait 29 mégas chez moi, et une petite trentaine une fois installée
#7
très bon article " />
en plus pour Facebook, s’ils pouvaient arrêter de balancer une mise à jour tous les 15j ou tous les mois " />
toutes les modifs sont à faire côté serveur, on veut juste une webview un peu réactive " />
bon au final on peut la virer et avec la version web s’en sortir, mais c’est moins clean qu’un app.
Autre piste : que l’OS permette un nettoyage global des caches (sur iOS, Android j’en sais rien), jusqu’ici il faut supprimer et réinstaller pour faire un peu de place. Pas que celle ci soit très très critique (64Go, souvent dans les 20Go dispos), mais par principe " />
#8
Merci de mettre en avant ce sujet trop peu souvent abordé dans la presse " />
#9
FirefoxOS trop en avance sur son temps ?
#10
On en parle de HP et de ses pilotes d’imprimantes ou de carte réseau ? " />
#11
Moi pour facebook, je ne tourne qu’avec lite sinon je ne l’aurais même pas installé. J’ai un vieux smartphone avec seulement 8Go de ram et je dois choisir mes applications.
#12
Tu me l’enlèves de la bouche. J’avaid comparé avec mon Android. L’appli mail de Firefox OS pesait (de mémoire) environ 400ko, contre 50 Mo pour Android. Plus de 100 fois plus. Seulement, ce n’était pas un argument de vente qui percutait chez les acheteurs. Ca intéresse les gens ayant des petits forfaits, mais ils ne représentent qu’une petite partie des acheteurs, qui sont de moins en moins nombreux vu les prix des forfaits aujourd’hui (en France).
D’autant plus que l’espace de stockage est un vrai problème pour les appareils bas de gamme. Sur Android j’ai très souvent eu le message “libérez de la place pour installer cette appli” alors que j’en avais assez en interne, et que j’avais une SD de 32 Go quasiment vide ! Mais l’appli s’installe forcément sur la ROM interne, donc j’étais obligé d’en supprimer une appli pour télécharger la mise à jour d’une autre. A force cela m’a décidé à changer de téléphone… (sans SD, ce que je trouve aberrant " />)
#13
En gros tel que je comprend le problème, chaque application est pour ainsi dire un container qui embarque la totalité de ses prérequis pour pouvoir fonctionner.
Un peu comme les logiciels qui viennent avec embarqué leur moteur d’exécution (Visual Truc, Java, etc)… Remarque, quand je vois que la suite Oracle Enterprise Manager qui fait télécharger des trouzaines de Go, ou encore rien que SQL Developper et ses 400Mo, je pense qu’ils ont encore du taff. " />
Ca montre quand même un gros manque du point de vue de l’OS…
#14
Je viens justement d’installer Lite en remplacement de Messenger sur mon Nexus 5X. On perd les bulles mais on a le système de réponse depuis les notifications natif d’Android à la place…
Facebook est une vraie plaie, l’application a effectivement un poids énorme pour faire, en gros, ce que le site mobile propose en étant plus léger. Pourtant, même avec ce poids on est loin d’un truc ultra stable. Rien que l’exploration des galeries photos ne décharge pas la mémoire au fil du scroll et entraîne des lags et des freezes quand on regarde un album un peu lourd, ce que je n’ai jamais eu en parcourant mon flux Google Photos.
Je peux le comprendre sur une application quelconque, mais c’est honteux de la part d’un éditeur aussi important et dont l’application correspond sûrement aujourd’hui à plus de 80% de son trafic. Honteux face aux exigences qu’on porte aux développeurs web sur la fluidité et la vitesse de chargement.
Aujourd’hui, mon téléphone passe pratiquement 1Go/mois de DATA à faire des mises à jour (sachant qu’Android ne permet toujours pas d’appliquer les mises à jour uniquement en charge), heureusement que la France est bien fournie en quota car je n’active jamais le WiFi. Et surtout, on ne sait effectivement pas pourquoi on fait la mise à jour, certaines applis affichent un changelog quand il y a des nouveautés intéressantes, ce n’est pas le cas de Facebook qui nous laisse juste nous débrouiller face à un changement d’interface, quand le glisser vers la gauche sort désormais l’appareil photo au lieu d’un menu par exemple.
Mais il faut croire que les nouveautés en matière de publicités, d’IA pour les marques et de réorganisation du flux pour nous faire bouffer toujours plus de contenu “hors amis” sont plus importants aujourd’hui pour Facebook, puisque de toute façon on a déjà fidélisé l’audience et qu’on se repose sur des acquis, qui ne le sont pourtant jamais vraiment dans le numérique.
#15
#16
Il faudrait un projet de développement qui aboutisse sur des aplications qui “autodétruisent” toutes parties de l’application ne correspondant pas au périphérique sur lequel elle a été installée (tailles d’écran, plateforme, drivers…). Après son installation l’application fait toute seule un régime afin de n’être optimisée plus que pour le téléphone sur lequel elle est installée.
#17
Il ferait bien de faire travailler ces développeurs sur des appareils entrée de gamme avec 32Go pour savoir ce que cela fait de se retrouver à court de place.
Et oui, Apple IIc quand on tapait un texte dans le word de l’époque, il y avait dans la barre en bas, le nombre de caractères qui diminuait car la disquette faisait 256ko et le logiciel ne savait pas enregistrer sur plusieurs disquettes.
Ha, ça sent bon l’imprimante à aiguille tout ça.
#18
Sur Windows Mobile, on peut rajouter 80Mo pour Osmeta qui sert de wrapper à l’application Facebook d’iOS " />
#19
La non gestion des formats SVG par Apple ne pourrait pas être contourné par une étape de conversion en pjeg ou autre à la taille de l’écran lors de la première utilisation ?
#20
#21
#22
il devait parler du stockage " />
#23
« Avant, on apprenait à optimiser le poids des images pour réduire la bande passante, mais beaucoup ne le font plus »
Un peu comme NXI qui affiche la photo des rédacteurs en 50x50 alors que la source est en 200x200 ou 400x400.
" />
#24
L’appli Facebook est une vrai plaie. Je déteste quand on lit un article puis qu’on revient sur le fil. Il te remet en haut en actualisant la suite alors que tu voulais continuait à descendre…
J’ai utilisé la version lite mais côté performance c’est moyen et il me manque deux fonctionnalités pour qu’elle devienne par défaut. L’affichage des gif et l’option sauvegarde pour lire plus tard. Sinon messenger lite est parfaite. On enlève tout le superflu. Qui redevient une simple appli de messagerie.
Par contre sous android les maj tournent dans les 55mo.
#25
aaaah, oui, bien sûr
(lundi, fatigue, toussa toussa)
2 gigas, c’est effectivement affreux. J’ai le souvenir du galaxy ace où il fallait supprimer des données dans tous les sens juste pour utiliser 3 pauvres applis :/
#26
https://github.com/NextINpact/nxiv6
au cas où tu voudrais signaler le truc (je ne suis pas super au fait de l’affichage…)
#27
S’il n’y avait que le stockage, le vrai problème est que els programmeurs sont devenus fainéants. donc on se retrouve avec des applications simples qui se mettent à consommer énromément en matière de stockage / cpu / ram / gpu car c’est plus simple que de faire de l’optimisation.
On est encore en période de croissance (elle n’est plus exponentielle mais on croit toujours) mais un jour l’augmentation des ressources demandés dépasseront la croisance hardware, et la ben faudra commencer à écouter les gens qui disaient que non 20% d’overhead du à “insérer nom du framework à la mode” ce n’est pas rien.
#28
#29
C’était simplement pour mettre en relief la remarque citée dans la news.
Sur PC ADSL/FTTH on n’est pas à 260 Ko près.
#30
8 Go de stockage pardon… et c’est vraiment léger.
#31
perso j’ai trouvé un “glitch” pour gagner du stockage : virer tous les google play machintrucbidule et remplacer par F-DROID+yalp store. Mine de rien, ça économise vachement.
#32
Perso, j’ai désinstallé énormément d’appli en me demandant ce qu’elles apportaient vraiment par rapport à la version web dans le navigateur. Du coup, j’ai créé des raccourcis qui lancent le navigateur, j’ai fait ça pour facebook par exemple, beaucoup trop lourd et qui finalement ne méritait pas un tel espace sur mon téléphone.
#33
10 euros l’app Tweetbot Oo Je note qu’il n’y plus de version d’essai sur appstore.. A son lancement on avait les app lite ce qui permettait d’utiliser le produit avant achat.
C’est dommage
#34
L’app est souvent en promo à moitié prix pour info
#35
Merci Vincent :)
dis moi pourquoi n’avons nous plutôt de version lite sur appstore ? l’essai me semble être un bon moyen avant d’acheter
#36
Tu parles de Messenger Lite ? C’est une bonne question. Ça faisait partie de celles que j’ai posées et pour lesquelles je n’ai eu évidemment aucune réponse :)
#37
#38
#39
oui, je n’ai vu qu’après " />
#40
#41
#42
Sur Amstrad CPC on avait de supers petits jeux pour 64ko !!!!
#43
L’entrée de gamme est toujours à 8 Go (cf Samsung Galaxy J1 Mini Prime par exemple, décembre 2016/Janvier 2017, qui n’est pas OTG en plus et fourni avec un câble prévu que pour charger. Pratique pour la gestion de données……).
Même en 2017, les daubes existent toujours. Mon vieux S4 a encore de l’avenir.
#44
D’autant que c’est autant de quantité d’information à échanger avec les serveurs et les utilisateurs finaux.. Pas très écologique tout ça (si tant est que l’on puisse l’être sur internet)..
Je trouve la démarche même contreproductive : on ne met plus à jour car on ne voit pas très bien quelles fonctionnalités il y a à gagner ET parce que ça prend trop de place/temps/contraintes (wifi)..
#45
La derniere fois que j’ai parle avec quelqu’un qui avait decompiler l’app (java powaaa), il en avait conclut que c’etait une catastrophe -> En gros comment ca se passe chez eux:
Facebook c’est un peu un cas d’ecole de comment ne pas faire une app.
#46
Si seulement, on avait un moyen de “liker” cet article, je le ferais. Vincent a très bien expliqué toute la connerie que cela représente. Au moment de lire l’article, j’avais justement 2 maj à faire sur mon iphone 6S+, une de twitter et l’autre de messenger, évidemment + de 100Mo chaque. Quand tu as une limite mensuel de 6Go et que les maj sont quasiment hebdomadaire, t’as intérêt à utiliser le WiFi plutôt que la 4G.
Quand je pense que le Moto G premier du nom de ma mère avec ses pauvres 5Go utilisables sur les 8Go et qui lui reste que 100 à 200 Mo de libre parce que tout les reste c’est quasiment pris que par les apps Google et que la moindre maj exige de désinstaller une app qui a aussi besoin d’une maj. Rendu là, je me dis que c’en est devenu ridicule.
Bref, encore un très bon article de Vincent.
#47
J’avais cherché avant de poster et les différents comparatifs “à moins de 200€” (pas trouvé en dessous) évoquaient plus ou moins les mêmes carac.
#48
Euh oui, perso je n’en ai qu’une, je ne peux pas détailler plus " />
#49
Ca dépend ce qu’on entend par entrée de gamme. Pour 130€, j’ai 16 Go d’espace interne, 3 Go de RAM, un écran 720p, une batterie de 4100 mAh. Pour moi c’est de l’entrée de gamme, mais c’est sûr qu’on n’a pas ça pour 80€ (là où on a encore de l’Android 4 " />).
#50
#51
très bon article, et également " />:
RIP FFOS " />
#52
Super dossier, merci beaucoup pour toutes ces explications !
Je trouve le silence radio de Facebook sur ce sujet assez décevant… Pas que j’avais une grande opinion de cette boite avant, mais quand même.
#53
#54
Ce n’est pas seulement une question de place, il y a aussi des tonnes de petits fichiers, entre les scripts, les ressources, les centaines d’images pour les animations, les sons. Je ne sais pas si c’est pareil sur mobile que sur PC, mais une " /> de framework comme NodeJs, c’est facile 22 000 fichiers dans 3 000 dossiers pour 200Mo " />, si t’as pas un SSD t’es mort " />
#55
On peut aussi parler des téléphones ou a la vente c’est 16 go de mémoire interne et au moment de le deballer tu te rends compte que il y a 1-2go pour les application qui peuvent être installé et 15-14go pour le reste (et considéré comme une carte SD donc si ajout de carte sd réel il ne servira que de stockage de musique, video, document ….)
#56
se situe aujourd’hui autour des 230 Mo sur un iPhone 7. La précision de l’appareil est importante car, comme nous le verrons plus tard, la taille change en fonction des caractéristiques techniques.
Sauf erreur de ma part je n’ai pas lu dans la suite l’impact des caractéristiques de l’appareil sur la taille de l’application. A moins que je n’ai pas bien lu.
#57
T’es sacrément en avance avec tes 8Go de ram…
#58
Depuis quand on utilise “glitch” pour autre chose qu’une défaillance ?
C’est une défaillance d’avoir une consommation d’espace de stockage non identique en remplaçant des logiciels ?
#59
#60