Une excellente nouvelle si vous ne voulez pas passer des heures à télécharger des mises à jour en pagaille ou si vous êtes obligé d’en effectuer sur votre réseau 3G/4G au lieu de les effectuer en Wifi. Avec une telle baisse de taille de données à télécharger, les mises à jour devraient être beaucoup moins gourmandes en bande passante.
Elle ne seront par contre pas forcément plus rapides… Et pourraient même consommer plus de batterie. Car pour arriver à ce résultat, Google utilise un processus de compression assez lourd qui demandera à votre machine un gros travail de décompression. Cela dit rien de spécialement alarmant, les SoC récents sont tout à fait capables de gérer ce genre de travail sans problèmes. Google indique que pour les machines récentes, c’est à dire sorties en 2015 et après, on parle de 1 seconde de travail par Mo de données. La plupart du temps cela se fait sans trop de soucis même si certains jeux peuvent demander beaucoup plus. On comprend également pourquoi il est important d’avoir un système de stockage rapide au sein de son appareil Android.
Qu’est-ce qui change dans la méthode employée par Google ? Comment parviennent t-il à ce résultat ? Google utilise un système qui s’appelle File by File Patching. C’est à dire un système qui ne remplace dans l’application présente sur votre tablette ou votre smartphone que les fichiers qui ont effectivement changé dans la nouvelle version. Cette méthode est bien entendu plus économes en téléchargement qu’un remplacement en bloc de l’ensemble des données. Si les images, vidéos, sons et autres éléments d’un jeu ne changent pas, pas de raison de les télécharger à nouveau.
Mais jusque là google se heurtait à un gros problème lié à la méthode de compression. En effet, avec les algorithmes employés, un simple changement de fichier modifiait considérablement le fichier compressé. Un problème qui rendait difficile l’identification des éléments a extraire et a remplacer.
Google montre cette image qui présente à gauche un texte et à droite son résultat compressé. Le simple changement d’un caractère à gauche entraîne une modification complète de sa représentation compressée à droite.
Difficile donc de détecter les changements dans du contenu compressé. Donc pour générer une mise à jour il faut décompresser les éléments les applications à patcher et l’ancienne et ensuite générer une mise à jour qui soit adaptée en compilant les différences. Ensuite, pour appliquer le patch, il faut décompresser le fichier installé, appliquer la mise à jour puis recompresser le tout. Enfin vérifier bit par bit que l’image de votre application correspond exactement à celle stockée sur le Play Store.
Au moment de décompresser le nouveau fichier, le système rencontre plusieurs problèmes et en particulier le fait que les bibliothèques de décompression d’Android peuvent varier suivant les machines employées. Ce qui ne provoquera pas la même résultat d’un smartphone à l’autre par exemple. Pire, suivant les éditeurs, différents paramètres de décompression peuvent être employés ce qui demande un travail différent de la part du système pour les mises à jour.
Après analyse, Google est parvenu à trouver un scénario commun pour le Play Store. D’abord parce que la plupart des applications utilisent désormais des versions récentes de Deflate, la bibliothèque de décompression la plus courante pour gérer ces contenus compressés. Mais surtout que les réglages de ce Deflate semblent désormais être identiques chez tous les éditeurs qui choisissent tous les niveaux de compression maximum.
Fort de ce scénario de base, il est désormais possible pour Google d’exploiter parfaitement sa technique de mises à jour File By File et donc de limiter les données à télécharger. Pour le moment, seules les mises à jour automatiques1 pourront utiliser cette technique lorsque votre machine est au repos et en charge, typiquement la nuit par exemple.
Le résultat de cette modification est impressionnant, Google dresse un tableau de son intérêt face au système classique. On peut y voir des réductions de taille très importantes avec par exemple une mise à jour de Netflix qui passe de 16.2 Mo en tant qu’application de base à 1.2 Mo en mise à jour. L’ancienne méthode forçait à télécharger 7.7 Mo de données. Cela représente une baisse de 92% de données à rapatrier.
Notes :
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |
Sympa !
En fait tout le monde se met à la page, de mémoire Microsoft fait pareil pour ses mises à jour d’OS https://blogs.windows.com/windowsexperience/2016/11/03/introducing-unified-update-platform-uup/
Ici on parle d’appli mais je suppose que le principe reste le même non ?
En effet, une belle nouvelle.
Sur un principe différent, les tels à la pomme ont réduit la taille des mises à jour via une autre méthode.
Désormais la mise à jour est personnalisée en fonction du tel et de l’OS en activité.
Au lieu d’avoir à télécharger toutes les résolutions d’écrans ou options pour rendre l’app compatible avec d’anciens OS, on ne télécharge que le principal.
Bien sûr c’est beaucoup plus simple puisque la gamme actuelle Apple représente une dizaine de tels et en terme d’OS, 3 ou 4 toujours en activité.
Cette méthode serait impossible à appliquer avec Android :-(
Il ne manque plus que Steam… Je n’en peux plus des Go et des Go de mise à jour !!!
Effectivement, ça raccourcira les mises à jour pour les jeux pantagruéliques !
Et du coup, ça ne remet pas en cause le format APK ? Tant mieux ! J’aurais bien vu un moyen détourné de google pour empêcher l’utilisation de ce format, pourtant bien pratique, puisqu’il permet les stores alternatifs et surtout un rollback d’une appli vers une version antérieure.
Ce que j’aimerais, moi, c’est surtout que l’on puisse geler la mise à jour d’une appli dans une version précise, pour ne plus faire de mise à jour à partir du jour tout à coup, l’éditeur décide de pomper toutes mes data privées pour les revendre parce que c’est devenu son business model ».