iOS 9 : Apple met les apps au régime
L’un des principaux freins à l’adoption d’iOS 8 n’était autre que le poids de sa mise à jour — 4,6 Go — empêchant son installation over the air sur les appareils encombrés. Mais les possesseurs d’iPhone dotés de seulement 8 ou 16 Go de stockage peuvent se réjouir : non seulement la mise à jour over the air d’iOS 9 ne pèsera que 1,3 Go, mais Apple a conçu de nouvelles technologies pour alléger considérablement les applications.
Les développeurs doivent prendre en compte la variété des appareils iOS : certains ont des processeurs 32 bits et d’autres des processeurs 64 bits, certains ont des puces graphiques compatibles avec Metal et d’autres pas, certains ont des écrans Retina et d’autres des écrans Retina HD, certains sont des iPhone et d’autres des iPad. Leurs apps contiennent donc des ressources qui ne sont pas utiles à tous les appareils… mais qui prennent de la place sur tous les appareils.
L’app slicing résout le problème : l’App Store d’iOS 9 est capable de « découper » les applications de manière à créer des « variantes » précisément adaptées à chaque appareil. Un iPhone 4S ne téléchargera plus les ressources réservées à l’iPhone 6 Plus, et inversement l’iPhone 6 Plus ne téléchargera plus les ressources réservées à l’iPhone 4S. Les applications prendront ainsi de 20 à 40 % d’espace en moins, un gain qui sera d’autant plus sensible sur les anciens appareils.
Les développeurs n’ont pas grand-chose à faire pour que leurs applications bénéficient de l’app slicing, mais ils devront prendre un peu de temps pour les adapter au système d’on-demand resources. Les ressources les plus lourdes, comme les images ou les sons, peuvent désormais être « marquées » comme « ressources à la demande ». Dès lors, elles ne seront pas chargées avant que l’application en ait besoin, et supprimées dès que cela ne sera plus le cas.
Ce système s’adresse en priorité aux jeux, même s’il peut être utilisé par toutes les applications. L’utilisateur ne téléchargera que les ressources essentielles au lancement de l’application ; l’App Store lui transmettra ensuite les ressources dont il a besoin (par exemple quand il passe à un nouveau niveau), en supprimant progressivement les anciennes (par exemple le niveau précédent). Le système est censé être invisible… mais Apple n’explique pas ce qui se passe en cas de coupure de la connexion ou de panne de l’App Store.
Ces deux nouveautés reposent sur le fait que les développeurs n’envoient plus des binaires compilés, mais uniquement du bytecode. Un code intermédiaire qu’Apple peut recompiler à la volée pour créer les variantes et envoyer les ressources à la demande, mais aussi pour faire profiter les applications des avancées de son compilateur, sans que le développeur n’ait rien à faire. Ce mécanisme est tellement important qu’il est obligatoire pour les applications watchOS, et activé par défaut (quoiqu’encore facultatif) pour les applications iOS.
Et pou les sauvegardes des applications sur iTunes ça va se passer comment?
itunes pourra sans doute retélécharger la version complète :)
Bonne Nouvelle pour la gestion du stockage et des ressources du téléphone !
Excellente initiative.
C'est un truc génial. Mais ça fait peur quand on n'a pas encore tous les détails.
Ça va charger des trucs en plus sur mon iPhone 6? Seulement en wifi ? Seulement au premier téléchargement ?
Vous parlez des chargements de niveaux. Ça fait comment si j'ai pas d'Internet...
Etc.
je pense effectivement que ca necessitera une mise à jour d'iTunes pour qu'il télécharge les versions completes des applications et ne synchronise sur les appareils QUE les ressources necessaires à l'appareil connecté
Quoi qu'il en soit rien que le régime de iOS 9 est déjà une bonne nouvelle !
J'imagine que c'est même principe pour iOS9. Il ne charge que ce qui est strictement nécessaire à l'appareil sur lequel il s'installe.
Génial pour jouer a un jeu dans un avion sans accès wifi si on a vite fini les quelques niveaux chargés au préalable...
très certainement, vous aurez la possibilité de contrôler ça.
Ce qu'Apple a dit était à destination des développeurs, du genre "ça pourrait vous permettre de faire ça, ou ceci ou cela ou pourquoi pas autre chose"
aux développeurs ensuite de pas être des Ouf Malades.
Amusant, Android propose un truc du genre depuis des années...
Android propose la chose selon la résolution de l'appareil. Parce qu'Android fait cela depuis le début de son existence. Pas Apple.
C'est devenu une nécessité maintenant. Apple y apporte une solution car ses tel se sont diversifier. ;)
@Lemmings :
Et ?
et l'argument Fragmentation et bytecode qu'on entend souvent comme un "défaut" quand il s'agit d'Android devient comme par miracle une réponse intelligente à un besoin quand c'est Apple qui adopte les mêmes techniques...
Pour le bytecode c'est différent d'Android. Au départ d'Android il y avait qu'un interpreteur, puis il y a eu un JIT (compilateur Just In Time) sur des morceaux de code, puis récemment est arrivé ART. Là on compile tout mais ça se passe sur le device de l'utilisateur à l'installation. Jusqu'à ART le pb c'est les perfs, avec ART l'inconvénient c'est le temps d'install et potentiellement la place vu que si mes souvenirs sont bons le bytecode et la forme compilée est stockée (par ailleurs la compilation est moins optimisée pour éviter de prendre trop de temps à l'installation).
Pour Apple le bytecode n'arrive pas à l'utilisateur la compilation se passe chez Apple. Pour l'utilisateur il n'y a que du gain, la place diminue et il a forcément une forme bien optimisée pour son device. Pour le développeur par contre c'est pas si simple.
(mon post n'a pas du tout pour but de défendre Apple ou critiquer Google, personnellement la guerre Android Apple je m'en fous complètement, mais juste d'expliquer la différence)
Cela va pas faire les affaires de Cydia, par contre...
Merci pour ce commentaire constructif.
@byte_order
Le problème de la fragmentation d'Android n'est pas tellement une question de taille d'écran mais de version de l'OS, même si c'est de moins en moins problématique à l'usage, mais juste frustrant pour l'utilisateur qui aime bien avoir les dernières nouveautés logicielles et cosmétiques.
Pour le bytecode si j'ai bien compris ça ne fonctionne pas du tout de la même manière sur iOS et Android. En effet sur Android c'était l'appareil qui compilait (ça a changé je crois) et sur iOS c'est Apple qui se charge de compiler pour le périphérique. Y a pas de machine virtuelle dans iOS.
"Cela va pas faire les affaires de Cydia, par contre..."
D'autant plus qu'on peut désormais compiler n'importe quelle app pour son appareil avec xCode sans compte dev.
Avant de crier "belle initiative", en ce qui concerne là gestions des images, sachez qu'Android le fait depuis quelques années. Avec les nombreuses variantes d'écran - mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi, ... - il fallait bien géré le téléchargement de ces ressources. Donc un téléphone mdpi ne téléchargera que les ressources associé à sa résolution.
En ce qui concerne Apple, il s'agissait d'une feature demandé par les développeurs depuis longtemps, car le téléchargement d'applications Android s'est nettement amélioré après cette spécification. Pas de quoi applaudir Apple, ce n'était qu'une question de temps.
Oui, iOS est un peu rustique :-) Mais cela n'est devenu une nécessité qu'avec la multiplication des écrans, des processeurs, des possibilités etc... Android a très vire géré le cas des APK multiples (entre autres) car les développeurs ont été très vite confrontés à cette problématique.
@Ast2001
"Oui, iOS est un peu rustique :-)"
Tu fais de la botanique ? ^_^
C'est certain qu'iOS n'a pas eu besoin d'évoluer de ce point de vue là avant l'arrivée des résolutions multiples. Mais c'est devenu une nécessité avec les nouveaux iPhones. À mon sens ça arrive au bon moment.
@nova313 :
@Lemmings :
Wé mais bon en contrepartie on se farci les surcouches constructeurs avec les apps constructeurs en doublon !
@ nova313
Avant, Apple n'en avait pas besoin. Donc il n'y avait pas de nécessité à avoir ce genre de gestionnaire de résolution.
Maintenant que Apple possède plusieurs résolution/définition/taille d'écran etc etc. Ils se sont peut-être dit qu'il pourrait mettre en place ce genre de service, ce qui ont fait.
Donc oui, c'est une bonne initiative car cela suit l'évolution des iDevices d'Apple.
Android la depuis des années car Android est comme cela depuis sa création. Donc encore heureux qu'ils l'ont depuis le début...
ben c'est une "belle initiative" d'Apple envers les clients Apple :)
Il était temps qu'Apple rende + sophistiqué le chargement d'apps.
Surtout que LLVM, utilisé depuis des années par Apple, EST entre autre conçu pour permettre un bytecode intermédiaire, idéal pour supporter à la fois les appareils 32b et 64b.
Mais comme toujours Apple est leEEeeenteuh.
ha, par "initiative" vous aviez compris "youhou on est les premiers AU MONDE à faire cela, tu l'as sens mon innovation hein hein ? tu as la trouille hein google, viens viens te battre " ?
@nova313 tu as un lien sur le chargement dynamique des ressources pour android ? car elles sont inclues dans le packagen c'est différent.
Le dernier paragraphe n'est pas correct, les 2 premiers aspects sont indépendants du dernier point. Et d'ailleurs il sera tout à fait possible d'utiliser les App Slicing et ODR sans utiliser le mode "bitcode".
Le mode bitcode s'il devient obligatoire (et vu la formulation utilisée à la WWDC ça sera le cas à termes) sera une avancée importante pour Apple (et pas mal de contraintes pour les développeurs) qui aura bcp plus de liberté pour faire évoluer ses plateformes matérielles. Exemple Apple sort le A9 avec des nouvelles instructions, ils peuvent sans rien demander aux développeurs recompiler toutes les applis pour en tirer partie et ils peuvent même casser la rétro compatibilité au niveau matériel.
C'est un peu un paradoxe pour une application dite "native ". Et puis des jeux a niveaux c'est très rares sur le store.
ce n'est qu'un exemple
Il était temps.
Bonne Nouvelle. Surtout quand on annonce avoir dépassé les 100.000.000.000 de téléchargements, ça fait d'autant d'économie en bande passante.
Il est possible de limiter fortement le poids d'une application en "calculant" les images dynamiquement. Un outil comme PaintCode permet de faire cela en transformant une image vectorielle en code exécutable.
Mes applications sont très légères par l'utilisation de ce procédé qui permet de plus de s'affranchir des contraintes de résolution et de dimensions des écrans.
C'est très bien ! Et maintenant : la batterie. La finesse, on s'en fiche maintenant.
Quand il disent que la mise a jour d iOS 9 fait que 1,4Go, ça veut dire que ca ne prendra in fine que 1,4Go de place sur l iPhone a la fin (un iPhone de 16Go aura 14,4Go pour l utilisateur) ou bien c est juste le firmware a télécharger qui fait 1,4Go mais une fois installer ca prendra beaucoup plus?
Si c est le cas, on pourrait avoir une ordre d idée de l espace vraiment gagné pour l utilisateur entre ios8 et ios9 :-)
Merci d avance macg !!! ;-)
C'est tellement évident qu'on se demande pourquoi ils n'y avaient pas pensé avant...
La batterie me fait 2/3h sur iOS 9 avec iPhone 6 , l horreur
J'ai regardé pas mal de test comparatifs d'iOS 8.3 vs iOS 9 sur des iPhones (4s, 5, 5s et 6) et franchement, je ne vois pas où sont les fameuses optimisations, il n'y a que sur le 6 que ça ne rame quasiment pas, sur tous les autres c'est flagrant.
Un test comparatif ne vaut rien, c'est l'utilisation au quotidien par millions qui compte...
Pour une version beta, c'est très largement au niveau.
Mon 4s sous iOS 9 est a peine plus lent que sous iOS 8. D'ici une beta on sera au même niveau, puis nous serons dans le plus rapide à partir de la beta 3-4 je pense.
Mais en tout cas, sur un 4s je n'ai pas de souci, la beta est très très satisfaisante
Ce n'est que la première bêta normal qu'on ne voit pas les optimisations, c'est tellement évident pourtant