Comment améliorer les performances et l'autonomie d'une appli mobile

Une notification qui arrive trois secondes trop tard, et vous avez déjà quitté l'écran. Un spinner qui tourne au moment précis où vous vouliez montrer l'app à un client. On connaît tous ces instants où une application perd la seule chose qu'elle ne récupérera jamais : l'attention.

Quand j'ai commencé à bosser sur des applis mobiles, je pensais que la performance, c'était un problème de vitesse. Réduire le temps de démarrage, fluidifier les listes, voilà tout. Puis j'ai eu un déclic un peu brutal : sur un projet e-commerce, on avait optimisé le temps de chargement jusqu'à ce qu'il soit irréprochable, et les retours négatifs continuaient d'arriver. La raison ? La batterie. Les utilisateurs se plaignaient que l'app "mangeait" leur téléphone. Une app rapide qui vide votre batterie en deux heures reste une mauvaise app.

Améliorer les performances et l'autonomie d'une appli mobile, c'est un seul chantier, pas deux. Et c'est ce que ce billet va montrer — parce que la plupart des guides traitent la vitesse et oublient la batterie. J'y reviens sur ce qui marche vraiment.

Pourquoi performance et autonomie sont le même combat (et pourquoi on les sépare à tort)

La vitesse d'une interface et la consommation d'énergie puisent dans la même ressource : le processeur, la mémoire, la radio réseau. Optimiser l'un sans regarder l'autre, c'est équilibrer son budget en regardant une seule colonne.

Le piège classique, je l'ai vu sur mon propre code. Pour afficher une liste plus vite, j'ai déplacé un traitement lourd dans un thread d'arrière-plan qui se relançait à chaque changement de filtre. Résultat : l'écran répondait instantanément, mais le téléphone chauffait dans la poche. Les retours sont passés de "lent" à "chauffe et vide la batterie en une heure".

Ce que la batterie révèle sur la performance

Un appareil qui chauffe vous dit quelque chose de précis : du travail inutile est accompli en continu. Chaque cycle processeur consomme, chaque réveil radio aussi. Quand je profile un drain anormal, je trouve presque toujours l'un de ces trois suspects :

• des localisations demandées en haute précision alors qu'un arrondi au quartier suffisait
• des synchronisations périodiques déclenchées à intervalle fixe, même quand rien n'a changé côté serveur
• des animations d'interface qui tournent alors que l'écran est éteint

Les deux premiers points partagent une logique : on consomme des ressources par habitude, pas par besoin. Et c'est exactement le défaut que masque un test de performance lancé sur un émulateur branché au secteur.

Le test qui change tout : sur appareil réel, batterie à 30 %

Voici une méthode que j'applique systématiquement maintenant. Je prends un téléphone d'entrée de gamme — pas le flagship — je le débranche, je le laisse descendre à environ 30 %, puis je lance un scénario d'usage normal pendant vingt minutes. À 30 %, la plupart des systèmes basculent en mode d'économie d'énergie, et là, deux choses apparaissent : ce qui tient malgré la contrainte, et ce qui s'écroule.

C'est souvent dans ces conditions que je découvre qu'une animation coûteuse sature un processeur bridé, ou qu'une requête réseau se bloque parce que le système a réduit les fenêtres de réveil. Des bugs invisibles sur un appareil de test nerveux.

Chasser le drain invisible : wakelocks, réveils et tâches de fond

Le plus grand mensonge des tableaux de bord classiques, c'est de croire qu'une appli qui n'est pas ouverte ne consomme rien. Le téléphone, lui, sait la vérité.

Les wakelocks, ces interrupteurs qu'on oublie de relâcher

Un wakelock, c'est une demande adressée au système : "garde le processeur éveillé, j'ai besoin de lui". Le problème n'est jamais de le demander. Le problème, c'est de l'oublier. Un wakelock non relâché maintient l'appareil hors veille, et sur une nuit, cela peut être la différence entre 8 % et 40 % de batterie perdue.

Sur un projet, on a mis des semaines à comprendre pourquoi certains utilisateurs Android perdaient beaucoup plus de batterie que d'autres. La coupable était une bibliothèque tierce qui gardait un verrou actif tant qu'une connexion en arrière-plan n'avait pas abouti. Sur les réseaux rapides, la connexion se terminait et le verrou tombait. Sur les réseaux lents, il restait accroché. Voilà une fuite qui ne se voit jamais dans un environnement de test bien connecté.

Android et iOS ne jouent pas le même match en arrière-plan

C'est l'angle que je trouve le plus souvent négligé. Les deux plateformes ont une philosophie opposée sur les tâches de fond, et si vous traitez les deux pareil, l'une des deux vous le fera payer.

Critère	Android	iOS
Principe général	Le système regroupe les réveils pour économiser l'énergie, en repoussant les tâches non prioritaires	Le système impose des fenêtres d'exécution strictes, hors desquelles rien ne tourne
Tâche de fond longue	Nécessite une déclaration explicite, sinon coupée rapidement	Durée plafonnée, avec compte à rebours système
Comportement écran éteint	Mode veille agressif qui gèle les accès réseau non essentiels	Application suspendue, réveils réseau quasi impossibles
Erreur fréquente	Confier une synchro périodique à un minuteur fixe	Attendre une exécution immédiate hors fenêtre autorisée

La leçon pratique : sur Android, on conçoit des tâches qui acceptent d'être reportées. Sur iOS, on conçoit des tâches qui supposent qu'elles pourraient ne jamais s'exécuter. Cette différence n'est pas un détail de plateforme, c'est une contrainte de conception qui remonte jusqu'à l'architecture réseau.

Les optimisations qui comptent vraiment (et celles qui font joli)

Il existe deux familles d'optimisations : celles qui se mesurent et celles qui se racontent. Beaucoup de ce qu'on lit sur la performance relève de la seconde catégorie.

Ce qui se mesure réellement

Une bonne optimisation de performance a un chiffre avant et un chiffre après. Pas une impression. Voici ce que je surveille en priorité, dans l'ordre :

1. Le temps de démarrage à froid — le premier écran affiché, celui qu'on ne peut pas cacher. Il conditionne tout le reste.
2. La consommation par session d'usage, mesurée sur un scénario identique répété.
3. La fréquence des réveils réseau, qui est presque toujours plus élevée qu'on ne le croit.
4. Le temps passé en rendu d'interface lors des défilements, surtout sur les appareils modestes.

Un point que j'ai mis du temps à intégrer : le gain de batterie se ressent plus fort que le gain de vitesse. Un utilisateur qui gagne 200 millisecondes sur un écran ne le remarque pas consciemment. Il remarque, en revanche, qu'il finit la journée avec 20 % de batterie en plus. Ce sont deux leviers de satisfaction qui n'ont pas la même puissance.

Les fausses bonnes idées qui accélèrent l'app et vident la batterie

Il y a des optimisations qui paraissent malignes jusqu'au moment où on branche un ampèremètre (ou, plus réaliste, jusqu'à ce qu'un utilisateur se plaigne).

• Précharger tout, tout le temps : anticiper les données de l'utilisateur est séduisant, mais précharger des écrans qu'il n'ouvrira jamais, c'est payer en batterie pour un confort imaginaire.
• Interroger le serveur à intervalle court pour "avoir le contenu frais" : souvent remplaçable par une synchronisation poussée déclenchée par le serveur, qui réveille l'appareil uniquement quand il y a réellement du nouveau.
• Animer en permanence des éléments invisibles : une animation qui tourne derrière un écran éteint ne se voit pas, mais elle se paie.

Je vais être direct sur un point : dans mon expérience, l'attente active — faire tourner une boucle en attendant que quelque chose se produise — est la pratique la plus coûteuse que l'on puisse laisser traîner. Elle ne coûte rien sur un appareil branché en test, et beaucoup sur un téléphone en fin de journée.

Profilage batterie : l'outil que personne ne sort de sa boîte

On profile volontiers le temps de rendu, la mémoire, les requêtes réseau. Le profil énergétique, lui, reste souvent un angle mort. C'est dommage, parce que c'est peut-être le profil le plus révélateur de tous : il fait apparaître le travail inutile.

Comment j'organise un profilage qui sert à quelque chose

Ma méthode, sans ordinateur savant :

1. Je pars d'un scénario d'usage écrit noir sur blanc — ouvrir l'app, consulter un écran, la laisser en arrière-plan dix minutes, la rouvrir.
2. Je mesure la consommation sur ce scénario répété trois fois, appareil débranché, luminosité fixe.
3. Je note les moments où le processeur est sollicité, les moments où la radio réseau s'active.
4. Je coupe une fonctionnalité à la fois et je regarde ce qui bouge.

Un détail qui change tout : je teste sur deux appareils, un récent et un modeste d'entrée de gamme. Les écarts entre les deux disent souvent plus que les chiffres absolus. Une appli dont la consommation double sur matériel modeste a un problème structurel, pas un problème d'optimisation de code.

Le piège du commerce : accélérer en vidant

L'erreur que je vois le plus régulièrement, chez des équipes qui cherchent avant tout à améliorer la performance, c'est la recherche du gain visible immédiat au prix du gain énergétique invisible. On descend le temps de chargement d'un écran en multipliant les requêtes en parallèle. Sur la balance de test, on braque à 2 secondes de moins. Sur le terrain, on a multiplié les réveils radio, et la batterie en fait les frais.

Le vrai arbitrage n'est donc pas "performance contre autonomie". C'est "quel travail est réellement utile à l'utilisateur, et lequel est seulement utile à notre tableau de bord". Une fois qu'on pose la question comme ça, beaucoup d'optimisations se retirent d'elles-mêmes.

Par où commencer, concrètement

Si vous ne deviez retenir qu'une seule chose de ce billet, ce serait ceci : mesurez d'abord, optimisez ensuite, et ne mesurez jamais sur un appareil branché au secteur. C'est la dépense la plus rentable de tout un cycle de développement.

Le reste suit une logique simple. Réduire ce qu'on fait en arrière-plan. Faire accepter aux tâches d'être reportées. Précharger moins, mais mieux. Et toujours garder en tête que le geste le plus fréquent de l'utilisateur, c'est de verrouiller son écran — pas d'admirer le spinner.

Il reste une question ouverte, et je n'ai pas de réponse définitive : à mesure que les systèmes deviennent plus intelligents dans la gestion de l'énergie, est-ce que ce sont les applis qui devront s'adapter, ou les systèmes qui finiront par exiger des applis qu'elles déclarent, comme un contrat, ce qu'elles consomment et pourquoi ? J'aurais tendance à parier sur la seconde option. Et si cela arrive, les applis qui auront pris l'habitude de mesurer leur consommation aujourd'hui seront celles qui souffriront le moins demain.