Performance et batterie : ce qui fait désinstaller une application

Une application peut être parfaitement fonctionnelle et se faire désinstaller en une semaine. Les motifs sont presque toujours les mêmes, et aucun ne concerne les fonctionnalités.

Voici ce que j’observe, dans l’ordre de fréquence, avec ce qui les corrige.

Le démarrage

C’est le premier contact, à chaque usage. Un utilisateur ouvre une application métier quinze fois par jour ; trois secondes d’attente à chaque fois, ce sont des minutes perdues et une irritation qui s’accumule.

Le repère que j’utilise : moins d’une seconde jusqu’à un écran utile, sur un appareil de milieu de gamme âgé de trois ans. Pas sur le téléphone du développeur, qui est toujours le plus récent du projet.

Ce qui ralentit un démarrage, dans l’ordre :

Tout ce qu’on fait « pendant qu’on y est ». Charger la configuration, initialiser cinq bibliothèques, vérifier les mises à jour, envoyer les statistiques. Chacune prend cent millisecondes ; ensemble, elles font une seconde. La correction consiste à ne garder au démarrage que ce qui est indispensable à l’affichage du premier écran, et à décaler le reste.

Attendre le réseau avant d’afficher. Un écran qui attend une réponse serveur pour apparaître est à la merci de la qualité de connexion. Afficher immédiatement les données locales, puis compléter à l’arrivée de la réponse, change complètement la sensation.

Une base locale ouverte et migrée au démarrage. Une migration de schéma sur plusieurs milliers d’enregistrements peut prendre plusieurs secondes, et elle tombe précisément après une mise à jour — le pire moment.

Les saccades

Un défilement fluide, c’est une image affichée toutes les seize millisecondes. Tout ce qui dépasse ce budget produit une image sautée, et l’œil le remarque immédiatement.

La cause est presque toujours la même : du travail exécuté sur le fil d’affichage. Un accès disque, un décodage d’image, un calcul un peu lourd, une lecture en base — chacun bloque l’affichage le temps de s’exécuter.

Les trois corrections qui rapportent le plus :

Redimensionner les images avant de les afficher. Décoder une photo de quatre mille pixels de large pour la montrer dans une vignette de cent est le gaspillage le plus courant que je rencontre. Il consomme de la mémoire, du processeur et de la batterie, pour un résultat identique.

Ne rien recalculer pendant le défilement. Formatage de dates, tri, filtrage, agrégation : tout cela se prépare avant l’affichage, pas à chaque ligne qui passe.

Ne redessiner que ce qui a changé. Une liste dont l’intégralité se reconstruit à chaque modification d’un élément saccade dès quelques dizaines de lignes.

Une remarque utile : les saccades apparaissent avec les données réelles. Une liste de vingt éléments de test est toujours fluide ; la même à huit cents ne l’est plus. Il faut tester avec des volumes réalistes, sinon on ne voit rien.

La batterie

C’est le motif de désinstallation le plus définitif, parce que le système désigne le coupable nommément dans ses réglages. Une application qui apparaît en tête de la consommation est supprimée sans discussion.

Trois causes, dans l’ordre :

La position en continu. Suivre la position avec une précision maximale et sans interruption est ce qui consomme le plus, de très loin. Dans la plupart des cas métier, une précision moindre et une mise à jour à intervalle raisonnable — ou déclenchée par un déplacement significatif — suffisent largement, pour une fraction de la consommation.

Une synchronisation trop fréquente. Interroger le serveur toutes les trente secondes réveille la radio en permanence, et c’est la radio qui coûte cher, pas les données échangées. Mieux vaut regrouper les échanges et laisser le serveur signaler ce qui a changé plutôt que de demander sans arrêt.

Un travail en arrière-plan mal borné. Une tâche qui ne se termine jamais, un minuteur qui continue quand l’application n’est plus affichée. Ce sont des oublis, pas des choix, et ils se voient immédiatement dans les mesures.

Photo : Markus Spiske — licence CC0.

Comment mesurer, concrètement

Sans mesure, on optimise au hasard — et on optimise généralement ce qui n’est pas le problème.

Les deux plateformes fournissent l’outillage nécessaire, gratuitement, et il est excellent : on peut visualiser où passe chaque milliseconde du démarrage, quelles images saturent, quelle part de l’énergie va au réseau, au processeur ou à la position.

Une règle que j’applique sans exception : mesurer sur un appareil ancien. Un modèle de milieu de gamme de trois ou quatre ans, celui que les utilisateurs ont réellement. Le téléphone du développeur masque tous les problèmes de performance, et c’est exactement ce qui explique l’écart entre « ça marche très bien chez nous » et les commentaires dans les magasins.

Et une fois en production : les rapports de plantage et de performance des magasins donnent la répartition réelle des temps de démarrage sur le parc, par modèle. C’est la seule mesure qui compte vraiment, parce qu’elle porte sur les vrais appareils des vrais utilisateurs.

Photo : domaine public (CC0).

Le poids de l’application

Sujet secondaire en apparence, réel en pratique.

Une application volumineuse se télécharge moins, surtout sur données mobiles où certains réseaux limitent le téléchargement. Et elle se désinstalle en premier quand l’utilisateur cherche de la place.

Les deux plateformes proposent des mécanismes de distribution qui n’envoient à chaque appareil que ce qui le concerne — la bonne résolution d’images, la bonne architecture de processeur, la bonne langue. Les activer réduit typiquement la taille de moitié, sans aucun travail sur le code.

Le reste vient presque toujours des ressources graphiques : des images non compressées, ou livrées dans une résolution supérieure à tout ce que l’écran peut afficher.

Le cas particulier des applications multiplateformes

Une question revient souvent : est-ce que le multiplateforme est plus lent ?

Sur une application métier, non — pas de façon perceptible. Ce qui produit des saccades, c’est du travail mal placé, et cela arrive exactement de la même manière en natif.

Il existe cependant deux points d’attention propres à ces cadres.

Le passage de données entre le code de l’application et le système. Selon les technologies, chaque échange a un coût. Il devient sensible quand il se produit à chaque image affichée — par exemple sur une animation pilotée par la position du doigt. La correction consiste à déporter l’animation du côté natif plutôt qu’à la piloter image par image.

Le temps de démarrage. Certains cadres doivent initialiser leur environnement d’exécution avant d’afficher quoi que ce soit. Cela ajoute quelques centaines de millisecondes au premier lancement, et c’est mesurable. Les versions récentes ont beaucoup réduit cet écart, mais il faut le vérifier sur appareil ancien plutôt que le supposer.

Dans les deux cas, l’écart avec le natif reste très inférieur à ce que coûte une image redimensionnée au mauvais moment. Autrement dit : la technologie choisie explique rarement les problèmes de performance ; ce qu’on fait avec elle, presque toujours.

Ce que je regarde en premier sur une application existante

Quand on me demande de reprendre une application dont les utilisateurs se plaignent, je suis toujours le même ordre, parce que c’est celui du meilleur rendement.

D’abord le temps de démarrage mesuré sur appareil ancien : c’est le plus visible et le plus souvent corrigeable rapidement.

Ensuite le comportement des listes avec des données réelles : c’est là que se trouvent les saccades, et la correction est presque toujours locale.

Puis la consommation d’énergie sur une heure d’usage typique : elle révèle immédiatement une position mal configurée ou une synchronisation trop bavarde.

Enfin le poids de l’application et le détail de ce qui la compose : c’est souvent le gain le plus facile de tous.

Ces quatre points couvrent l’essentiel des plaintes utilisateur, et ils se traitent en général en quelques jours. C’est rarement une question de réécriture — presque toujours une question de travail fait au mauvais moment ou au mauvais endroit.