Une application Flutter qui perd des images parait bon marche peu importe sa beaute. Le framework est rapide par defaut, mais il est facile d annuler cela avec quelques habitudes negligentes. J ai passe assez de temps dans le profileur pour savoir ou le temps part, et la plupart des gains viennent d une courte liste de corrections plutot que d astuces malines. Voici ce que je verifie d abord.
Mesurer avant de changer quoi que ce soit
N optimisez jamais sur une intuition. Lancez l application en mode profile, pas en mode debug, car les builds de debug sont volontairement lents et vous mentiront. La vue de performance de DevTools vous montre la chronologie des images, et tout ce qui pousse une image au dela de seize millisecondes est votre probleme. Trouvez la vraie image lente avant de toucher au code, sinon vous passerez un apres midi a accelerer quelque chose que personne n a remarque.
flutter run --profile
# puis ouvrez DevTools et enregistrez la chronologie de performance
Utilisez const partout ou vous le pouvez
Un widget const est construit une fois et reutilise, donc le framework saute sa reconstruction. C est le gain de performance le moins cher de Flutter et la plupart des applications le laissent de cote. Si un widget et ses entrees ne changent jamais, marquez le const. L analyseur peut meme signaler les endroits pour vous si vous activez le bon lint.
// reconstruit a chaque fois que le parent se reconstruit
Padding(padding: EdgeInsets.all(8), child: Text('Salut'))
// construit une fois et mis en cache
const Padding(padding: EdgeInsets.all(8), child: Text('Salut'))
Cela compte surtout dans les widgets qui se reconstruisent souvent, ce qui boucle vers le choix de la bonne approche dans la gestion d etat Flutter. Une portee de reconstruction serree plus des widgets const garde petit le travail que le framework fait a chaque image.
Construisez les longues listes paresseusement
L erreur la plus courante que je vois est de construire une longue liste avec une Column dans une vue defilante. Cela construit chaque element d avance, meme les milliers hors ecran. ListView.builder ne construit que ce qui est visible plus un petit tampon, donc la memoire et le temps de construction restent plats peu importe la longueur de la liste. Pour toute liste qui peut grandir, utilisez le builder.
ListView.builder(
itemCount: items.length,
itemBuilder: (context, index) {
return ListTile(title: Text(items[index]));
},
)
Gardez le travail hors du thread principal
L interface tourne sur un seul thread, et tout ce que vous y faites de lourd vole du temps au rendu. Analyser un gros payload JSON, redimensionner une image ou lancer un calcul lent gelera l interface. Deplacez ce travail vers un isolate en arriere plan avec l aide compute pour que le thread d interface reste libre de dessiner les images.
import 'package:flutter/foundation.dart';
Future<List<Item>> parseItems(String json) {
return compute(decodeItems, json);
}
- Profilez en mode profile, jamais en mode debug
- Marquez const les widgets qui ne changent pas
- Utilisez les constructeurs builder pour les listes longues ou croissantes
- Poussez l analyse et les maths lourds vers un isolate
- Mettez en cache et dimensionnez les images au lieu de charger la pleine resolution
Les images sont souvent le cout cache
Les images mangent la memoire plus vite que tout le reste. Une photo chargee en pleine resolution dans une petite vignette gaspille la plupart de cette memoire. Reglez une largeur de cache qui correspond a la taille d affichage pour que le framework decode un bitmap plus petit. Pour les images reseau, utilisez un package de cache pour les recuperer une fois plutot qu a chaque defilement.
Surveillez vos shaders au premier lancement
La premiere fois qu une animation tourne, Flutter peut compiler des shaders, ce qui cause une saccade ponctuelle que les utilisateurs remarquent sur une installation fraiche. Vous pouvez prechauffer les shaders pendant un ecran de demarrage pour que la saccade arrive avant que l utilisateur regarde. C est un petit detail, mais les premieres impressions collent. Les chemins de code natif peuvent aussi affecter le demarrage, c est pourquoi je garde le travail de plateforme leger comme decrit dans les canaux de plateforme Flutter. La performance est rarement une grosse correction. C est une douzaine de petites, chacune mesuree, chacune gardee.
