Play Store : Google exploite un nouvel algorithme de compression

Play Store : Google exploite un nouvel algorithme de compression

Bsdiff au rapport

Avatar de l'auteur
Sébastien Gavois

Publié dans

Société numérique

25/07/2016 2 minutes
22

Play Store : Google exploite un nouvel algorithme de compression

Afin de réduire la quantité de données utilisée lors de l'installation ou de la mise à jour d'une application Android, Google a déployé un nouvel algorithme. Le géant du Net a également revu la manière d'indiquer la « taille » indiquée sur la fiche produit du Play Store.

L'année dernière, Google revendiquait que pas moins de 65 milliards d'applications ont été installées par les utilisateurs d'Android en passant par le Play Store. Cela fait de grosses quantités de données à envoyer vers les smartphones et tablettes, d'autant plus lorsqu'on ajoute les mises à jour plus ou moins régulières suivant les cas. Afin d'améliorer un peu les choses, le géant du Net vient d'annoncer qu'il utilisait un nouvel algorithme.

Pour commencer, Google explique que pour environ 98% des mises à jour, seules les modifications des fichiers APK déjà téléchargés sont récupérées et fusionnées avec les données existantes, ce qui réduit déjà considérablement la taille de celles-ci. Afin d'améliorer encore un peu les choses, Google a décidé d'utiliser l'algorithme bsdiff qui réduit encore la taille des patchs, avec un ratio pouvant aller « jusqu'à 50% ou plus par rapport à l'algorithme précédent ».

Pour plus d'efficacité, Google recommande que les bibliothèques exploitées par l'application soient stockées sans compression. Dans le cas contraire, une amélioration serait tout de même de la partie, mais avec un gain de seulement 5 %, selon la société de Mountain View.

Certaines applications (notamment les jeux) ont besoin d'utiliser des fichiers supplémentaires qui peuvent être relativement gros (jusqu'à 2 Go), disponibles via les APK Expansion Files. Des modifications ont également été apportées pour ces derniers, réduisant ainsi la taille de 12 % environ lors du premier téléchargement et de 65 % lors des mises à jour.

Dans le même temps, le Play Store affiche désormais « la taille réelle du téléchargement » d'une application et pas celle du fichier APK. Si vous avez déjà l'application installée, c'est la taille de la mise à jour qui sera indiquée. Ces changements sont progressivement déployés précise Google :

Google Play Store algorithmeGoogle Play Store algorithme

22

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (22)


Enfin! Des mises à jour qui sont réellement des mises à jour, et non le chargement complet de l’app. 

C’est un pas important :)


Apple devait pas un système similaire à un moment ?


Il me semble avoir compris que c’était déjà le cas, et qu’ils sont juste passé à un algo qui génère des patchs plus petits.


Faut lire la news


Je viens de relire, effectivement, mais je ne m’en étais jamais rendu compte… même sur mes propres applications&nbsp;<img data-src=" />

Cela doit être surtout valable sur les grosses appli, les petites n’ont peut-être pas besoin de cela (ou cela passe complètement inaperçu avec une différence minime).


4mo pour une appli téléchargée 50,000 fois = une paille

Une appli comme comme celle de la news de 400mo téléchargée 10 millions = ça vaut le coup <img data-src=" />








gokudomatic a écrit :



À qui il devait ça?





Il eut dû.









gokudomatic a écrit :



À qui il devait ça?





Petit erreur de ma part , je refais :&nbsp;Apple ne devait pas mettre un système similaire à un moment ?



Si, le AppThinning, mais il faut que l’appli soit un poil adaptée je crois


Google a pris son temps sur ce coup, vu que bsdiff date de 2003.



Et son auteur, Colin Percival, est surtout connu pour sa fonction de dérivation de clé scrypt.


C’est pas faux.








manu0086 a écrit :



Enfin! Des mises à jour qui sont réellement des mises à jour, et non le chargement complet de l’app.&nbsp;

C’est un pas important :)





Honnêtement, vu le temps que ça met à faire les MAJ, moi j’ai vraiment l’impression que dans la majorité des cas, il retélécharge l’APP complète



Le “Smart app update” dans le PlayStore qui calcule le différentiel à télécharger a été introduit en 2012 en même temps que Android 4.1 (Jelly Bean) et concerne Android 2.3+

http://android-developers.blogspot.fr/2012/06/introducing-android-41-jelly-bean.html

A l’époque les mise à jour de Chrome sur PC utilisaient déjà ce genre de différentiel.


Le problème n’est pas forcément le téléchargement, mais il y a le “merge” (vu qu’il ne télécharge que le différentiel, il faut tout réintégrer dans le programme) et éventuellement la “compilation” de l’application, depuis Android 5+ (depuis le passage à ART en remplacement de Dalvik)

https://source.android.com/devices/tech/dalvik/


Oui effectivement! Moi ce qui prend le plus de temps ce n’est pas le téléchargement mais l’installation… Et le PIRE élève en la matière c’est l’appli facebook! Ca prend une plombe à chaque fois (la partie “installation” et non “téléchargement” ^^)


Bien la taille du diff, c’est vrai que ca porte à confusion à chaque fois.


Moi c’est bien les deux partie téléchargement et installation qui prennent une plombe. Et pourtant j’ai pas un mauvaise connect (15Mb/s)


cool,je ne pensais pas que google play existait encore!

du coup snap ca va me servir encore un peu.


vampire7 a écrit :Google a pris son temps sur ce coup, vu que bsdiff date de 2003.&nbsp;Et son auteur, Colin Percival, est surtout connu pour sa fonction de dérivation de clé scrypt.



BSDIFF de 2003, on est en 2016… Bravo !

Y a pas d’autre algo plus performant ?

&nbsp;


Vas y, au boulot, on attend ton algo !








fred42 a écrit :



Vas y, au boulot, on attend ton algo !





Y a plein de monde que feront ça bien mieux que moi ! Et puis y a les algos utilisés pour le prix Hutter.