Vers des apps toujours plus rapides

Ecrit par le Mercredi 27 Novembre 2013

Vers des apps toujours plus rapides

cc jkbrooks85 / Flickr

Depuis que nous avons commencé à poser les premières bases de GoodBarber, notre objectif a toujours été de proposer des apps à la meilleure expérience utilisateur possible.
Au delà de l'intérêt qu'elles peuvent présenter pour l'utilisateur final, notre approche — et elle est largement partagée dans l'industrie — consiste à évaluer l'expérience utilisateur d'une app à travers l'esthétique (design) et la fluidité (rapidité) de son interface.
 
L'autre objectif principal est de vous permettre une souplesse maximale dans la gestion de votre application. Concrètement, cela passe par la diversité des paramétrages proposés, et par la facilité de déploiement des modifications que vous y apportez.
C'est ce qui nous a amené à concevoir un système de mise à jour des apps à distance, aussi immédiat que possible, pour vous permettre de mettre à jour toute la base installée de votre app sans pour autant passer par une re-soumission sur les stores.
 
La combinaison de ces différentes contraintes a créé une équation relativement complexe à résoudre, car plus la souplesse de paramétrage est grande, plus il est complexe de conserver la rapidité et la fluidité de l'interface, et inversement, plus on recherche la rapidité, moins nous pouvons vous proposer de paramétrages.
 
Nous consacrons une grande partie de nos efforts à faire évoluer GoodBarber pour en faire le générateur d'applications le plus avancé au monde (notamment à travers la mise à jour 2.5 Salavdor). En parallèle, l'équipe se concentre sur l'optimisation des apps après chaque release.

Comment se passe le processus de lancement d'une app ?

Concrètement, il n'est pas envisageable de télécharger les différents éléments du design de votre app au fur et à mesure de son fonctionnement. Il y a deux raisons à cela : cela ralentirait considérablement l'affichage de l'interface (qui à l'instar d'une page web devrait charger ses éléments graphiques avant de les afficher), et cela pourrait créer une incohérence d'affichage des applications en ne leur permettant pas de fonctionner hors connexion.
 
Lorsque votre app est lancée, elle va donc interroger les serveurs de GoodBarber pour télécharger les éléments de son design, et tout ce dont elle aura besoin pour fonctionner de manière parfaitement autonome — à l'exception de son contenu, qui lui peut être amené à évoluer beaucoup plus souvent que le design.
Pour les plus experts d'entre vous : c'est à ce moment là que l'application va interroger la Settings API, pour vérifier que tous les assets qu'elle possède dans son cache sont à jour.
 
Ce processus de mise à jour ne se produit que si votre app n'était pas lancée dans le multi-tâche du système, pour éviter de ralentir son lancement en utilisation normale.
De même, tous les éléments de votre application sont embarqués dans son cache local au moment de la compilation, pour permettre d'une part son fonctionnement hors connexion, et d'autre part faire en sorte qu'elle soit la plus rapide possible après sa publication.

Comment la durée de la mise à jour peut varier ?

Lorsque l'application interroge la Settings API pour se mettre à jour, elle parcourt l'ensemble des assets qui lui sont renvoyés et les compare un par un avec son cache local.
Cela veut donc dire que si aucune modification n'a été publiée depuis la mise à jour précédente, ce processus sera quasi transparent. La Settings API répondra qu'aucune modification n'a été apportée, et l'application reviendra à son fonctionnement normal.
 
En revanche, plus les modifications sont importantes (nouvelles images, etc.), plus le temps nécessaire pour télécharger la mise à jour va être important.
 
Il peut exister deux cas dans lesquels la mise à jour peut s'avérer compliquée : le cas d'un changement complet de maquette (qui peut entraîner plusieurs mégas de données à télécharger), et le cas où l'utilisateur se trouve dans une zone où la couverture réseau est très faible.
 
Dans ces deux cas, l'application peut décider d'arrêter prématurément sa mise à jour, si certains éléments téléchargés ont été corrompus, ou si la durée de la mise à jour est trop longue.
 
Tout ce processus se produit au moment du lancement de votre app, lors de l'affichage du splashscreen. Vous pouvez constater la progression de la mise à jour grâce à l'apparition d'une barre de progression blanche en haut de l'écran.
 
Il est à noter que le téléchargement des publicités se produit juste après le processus de mise à jour. Il vous faut donc faire attention à ce qu'il ne ralentisse pas inutilement le lancement de l'app.

Monitoring et optimisations

Pour optimiser le temps de chargement des nouveaux éléments, notre équipe a mis en place un certain nombre d'outils de monitoring dans les applications. Nous voulions comprendre quelles étaient les pistes d'optimisation possibles, tout en sachant que nous ne pouvons pas influer sur la connectivité réseau, dont le temps de chargement est pourtant très dépendant.
 
Contrairement à ce que l'on pourrait penser, il est apparu que ce n'est pas la quantité de données à télécharger qui influe sur le temps de chargement, et ce sensiblement quelle que soit la connectivité du terminal (Edge, 3G, 4G ou WiFi). Evidemment, plus le volume de données est important, plus il faut du temps. Mais les réseaux mobiles d'aujourd'hui proposent des débits suffisants pour que ce ne soit pas franchement un problème (car au final, même un chargement de maquette complet ne pèse que 2 à 3 mégas).
 
En revanche, c'est le ping, c'est à dire le temps d'aller/retour entre le terminal et le serveur, qui peut faire exploser le temps de chargement. Concrètement, cela veut dire que plus il y a de fichiers à télécharger, plus le nombre de requêtes au serveur est grand, plus le téléphone va patienter inutilement le temps des aller/retour.
 
Après la publication de GoodBarber 2.5 Salvador, notre équipe a donc cherché un moyen d'optimiser ces différents points.
Depuis le mois d'Octobre, nous avons mis en place un système qui permet de réduire de près de 60% le temps de mise à jour de l'app.
 
Notre souhaitons que le temps de mise à jour soit encore plus restreint, et nous poursuivons plusieurs pistes dans cet objectif. Notre équipe d'administration système travaille notamment à la mise en place d'un CDN (Content Delivery Network), qui devrait faire en sorte que l'application se lance aussi rapidement quelque soit l'endroit du globe.
Ce système sera également étendu aux flux de contenus des applications.
 
L'équipe de développement natif se consacre quant à elle à fluidifier l'interface de l'application.
Peut-être que vous n'avez pas encore découvert les petites nouveautés que vous a préparé Alex :) On en reparle dans quelques jours !



Entrez votre adresse email