Comment Flutter fonctionne

Les questions « c'est quoi un BuildContext ? », « que se passe-t-il quand on appelle setState ? » ou « à quoi servent les keys ? » reviennent dans presque tous les entretiens Flutter. Elles testent une seule chose : savez-vous ce qui se passe sous les widgets. Ce chapitre décrit les trois arbres, le cycle de vie, le layout et le pipeline de rendu jusqu'à Impeller.

Architecture en couches

Flutter ne s'appuie pas sur les composants graphiques natifs de la plateforme : il dessine lui-même chaque pixel. C'est ce qui garantit un rendu identique sur Android et iOS, et c'est aussi pourquoi il doit embarquer son propre moteur de rendu.

• Le framework est entièrement en Dart et se lit comme votre propre code : on peut ouvrir la source de Column ou de setState depuis l'IDE. C'est la meilleure documentation qui soit.
• L'engine, en C++, fournit le rendu (Impeller), le runtime Dart, la mise en page du texte et expose des primitives bas niveau via dart:ui.
• L'embedder intègre l'engine dans l'application hôte : surface de rendu, boucle d'événements, entrées, cycle de vie, accessibilité, plugins.

Les trois arbres

Flutter maintient trois structures parallèles. Les confondre est l'erreur la plus fréquente en entretien.

Un widget est un plan, pas un objet à l'écran. Créer des milliers de widgets par frame est bon marché, car ce sont de petits objets immuables. Ce qui coûte cher (le layout, le paint) se trouve dans les RenderObjects, et Flutter fait tout pour les réutiliser.

À chaque rebuild, l'Element compare l'ancien widget au nouveau avec Widget.canUpdate : même runtimeType et même key. Si c'est le cas, l'Element est conservé et simplement mis à jour avec la nouvelle configuration (updateRenderObject pour la partie rendu). Sinon, l'ancien Element est démonté et un nouveau est créé, avec perte de son State.

Tous les widgets ne créent pas de RenderObject. StatelessWidget et StatefulWidget produisent des ComponentElement qui ne font que composer d'autres widgets. Seuls les RenderObjectWidget (Padding, Opacity, RichText, Flex...) créent un RenderObject. Un Text est un StatelessWidget qui construit un RichText, qui lui crée un RenderParagraph.

BuildContext, c'est l'Element

BuildContext est une interface implémentée par Element. Le context reçu dans build est donc l'Element du widget courant, c'est-à-dire sa position dans l'arbre. Toutes les méthodes « of » (Theme.of, MediaQuery.sizeOf, Navigator.of) remontent l'arbre à partir de cette position.

Conséquence : un context ne voit que ses ancêtres. Le cas classique est un Scaffold.of(context) appelé dans le même build que celui qui crée le Scaffold : le contexte est au-dessus du Scaffold, la recherche échoue.

import 'package:flutter/material.dart';

class Ecran extends StatelessWidget {
  const Ecran({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      drawer: const Drawer(),
      body: TextButton(
        // erreur : ce context est celui d'Ecran, pas un descendant du Scaffold
        onPressed: () => Scaffold.of(context).openDrawer(),
        child: const Text('Menu'),
      ),
    );
  }
}

import 'package:flutter/material.dart';

class Ecran extends StatelessWidget {
  const Ecran({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      drawer: const Drawer(),
      body: Builder(
        builder: (inner) => TextButton(
          onPressed: () => Scaffold.of(inner).openDrawer(),
          child: const Text('Menu'),
        ),
      ),
    );
  }
}

Deuxième règle : un context n'est valide que tant que son Element est monté. Après un await, l'écran a pu être fermé. Le lint use_build_context_synchronously signale ce cas.

import 'package:flutter/material.dart';

Future<void> confirmer(BuildContext context, Future<void> Function() envoyer) async {
  await envoyer();
  if (!context.mounted) return; // l'écran a peut-être été fermé
  ScaffoldMessenger.of(context).showSnackBar(
    const SnackBar(content: Text('Transfert envoyé')),
  );
}

Cycle de vie d'un StatefulWidget

Un StatefulWidget est lui-même immuable. L'état mutable vit dans un objet State, créé une fois et conservé par l'Element tant que celui-ci reste dans l'arbre. C'est pourquoi un même State peut recevoir plusieurs widgets successifs au fil des rebuilds du parent.

import 'dart:async';

import 'package:flutter/material.dart';

class Minuteur extends StatefulWidget {
  const Minuteur({super.key, required this.secondes});
  final int secondes;

  @override
  State<Minuteur> createState() => _MinuteurState(); // 1. une seule fois
}

class _MinuteurState extends State<Minuteur> {
  late int _restant;
  Timer? _timer;

  @override
  void initState() {
    super.initState();                  // 2. une fois : init, abonnements
    _restant = widget.secondes;
    _timer = Timer.periodic(const Duration(seconds: 1), (_) {
      if (_restant == 0) return;
      setState(() => _restant--);
    });
  }

  @override
  void didChangeDependencies() {
    super.didChangeDependencies();      // 3. après initState, puis quand un
    // InheritedWidget dont on dépend change (Theme, MediaQuery, Locale...)
  }

  @override
  void didUpdateWidget(Minuteur oldWidget) {
    super.didUpdateWidget(oldWidget);   // le parent a fourni un nouveau widget
    if (oldWidget.secondes != widget.secondes) {
      _restant = widget.secondes;       // resynchroniser l'état dérivé
    }
  }

  @override
  Widget build(BuildContext context) => Text('$_restant s'); // 4. souvent

  @override
  void deactivate() {
    super.deactivate();                 // retiré de l'arbre, peut être réinséré
  }

  @override
  void dispose() {
    _timer?.cancel();                   // 5. définitif : libérer les ressources
    super.dispose();
  }
}

mounted vaut true entre l'insertion du State et dispose. On le teste avant un setState qui suit un await, car appeler setState après dispose déclenche une erreur.

setState et quand build est appelé

setState ne reconstruit rien immédiatement. Il exécute la fonction passée (synchrone, qui ne doit pas renvoyer de Future), puis appelle markNeedsBuild() sur l'Element. Celui-ci est marqué « dirty » et ajouté à la liste des éléments à reconstruire du BuildOwner, et une frame est planifiée. Au prochain vsync, le framework reconstruit les éléments sales, du plus haut au plus bas. Dix setState dans le même événement donnent donc un seul rebuild.

build est appelé :

• après initState et didChangeDependencies ;
• après didUpdateWidget, quand le parent se reconstruit ;
• après un setState ;
• quand un InheritedWidget dont il dépend notifie un changement ;
• après une réactivation (deactivate puis réinsertion).

Puisque build peut être appelé à chaque frame, il doit être pur et rapide : pas de requête réseau, pas de création de controller, pas de calcul lourd.

Const widgets et réutilisation

Quand un parent se reconstruit, tout son sous-arbre est reconstruit par défaut. Sauf pour un widget const : l'instance est canonicalisée (chapitre 01), donc identique à la précédente. L'Element constate que identical(ancien, nouveau) est vrai et ne reconstruit pas ce sous-arbre. Deux techniques en découlent : mettre const partout où c'est possible, et extraire les parties qui changent dans de petits widgets pour limiter la zone reconstruite par un setState.

// setState dans l'écran entier pour mettre à jour une horloge :
// l'en-tête, la liste et le pied de page sont reconstruits aussi.

import 'package:flutter/material.dart';

class Accueil extends StatelessWidget {
  const Accueil({super.key});

  @override
  Widget build(BuildContext context) {
    return const Column(
      children: [
        EnTete(),    // const : jamais reconstruit par l'horloge
        Horloge(),   // StatefulWidget isolé, il porte son propre setState
      ],
    );
  }
}

class EnTete extends StatelessWidget {
  const EnTete({super.key});
  @override
  Widget build(BuildContext context) => const Text('Wallet');
}

class Horloge extends StatefulWidget {
  const Horloge({super.key});
  @override
  State<Horloge> createState() => _HorlogeState();
}

class _HorlogeState extends State<Horloge> {
  @override
  Widget build(BuildContext context) => Text('${DateTime.now()}');
}

Keys

Par défaut, quand une liste d'enfants change, Flutter apparie anciens et nouveaux widgets par position et par type. Pour des widgets sans état, c'est sans conséquence. Pour des StatefulWidget, c'est un bug : le State reste attaché à la position, pas à la donnée.

import 'package:flutter/material.dart';

class Tuile extends StatefulWidget {
  const Tuile({super.key, required this.nom});
  final String nom;

  @override
  State<Tuile> createState() => _TuileState();
}

class _TuileState extends State<Tuile> {
  bool _favori = false; // état local à la tuile

  @override
  Widget build(BuildContext context) {
    return ListTile(
      title: Text(widget.nom),
      trailing: IconButton(
        icon: Icon(_favori ? Icons.star : Icons.star_border),
        onPressed: () => setState(() => _favori = !_favori),
      ),
    );
  }
}

// Liste [Amina, Karim, Sara], Amina marquée favori.
// On supprime Amina : Karim s'affiche... avec l'étoile pleine.
// Le premier State a été réutilisé pour le premier widget, quel qu'il soit.
Widget liste(List<String> noms) => Column(
      children: [for (final n in noms) Tuile(nom: n)],
    );

import 'package:flutter/material.dart';

class Beneficiaire {
  const Beneficiaire(this.id, this.nom);
  final String id;
  final String nom;
}

class Tuile extends StatelessWidget {
  const Tuile({super.key, required this.nom});
  final String nom;
  @override
  Widget build(BuildContext context) => ListTile(title: Text(nom));
}

Widget liste(List<Beneficiaire> items) => Column(
      children: [
        for (final b in items) Tuile(key: ValueKey(b.id), nom: b.nom),
      ],
    );

Les keys locales ne doivent être uniques qu'entre frères (siblings) d'un même parent. Elles se placent sur le widget le plus haut de l'élément de liste, celui qui est enfant direct de la collection. Une GlobalKey coûte plus cher (registre global, recherche) et doit rester stable : la créer dans build recrée l'état à chaque frame.

InheritedWidget

Un InheritedWidget rend une donnée accessible à tout son sous-arbre, en O(1), sans la passer de constructeur en constructeur. C'est la fondation de Theme, MediaQuery, Localizations, de Provider, et du ProviderScope de Riverpod, qui expose son conteneur à l'arbre par un InheritedWidget interne.

import 'package:flutter/widgets.dart';

class SessionScope extends InheritedWidget {
  const SessionScope({super.key, required this.nomClient, required super.child});

  final String nomClient;

  static SessionScope of(BuildContext context) {
    // enregistre une dépendance : ce context sera reconstruit si la donnée change
    final scope = context.dependOnInheritedWidgetOfExactType<SessionScope>();
    assert(scope != null, 'Aucun SessionScope au-dessus de ce context');
    return scope!;
  }

  @override
  bool updateShouldNotify(SessionScope oldWidget) =>
      nomClient != oldWidget.nomClient; // notifier seulement si utile
}

dependOnInheritedWidgetOfExactType fait deux choses : il trouve l'ancêtre le plus proche du type demandé (chaque Element garde une table des InheritedElements au-dessus de lui, d'où le coût constant), et il inscrit le contexte appelant comme dépendant. Quand l'InheritedWidget est reconstruit avec une nouvelle valeur et que updateShouldNotify renvoie true, tous les dépendants reçoivent didChangeDependencies puis un rebuild. getInheritedWidgetOfExactType lit sans s'abonner.

Une limite : tout dépendant est reconstruit, quelle que soit la partie de la donnée qu'il utilise. D'où InheritedModel et les accesseurs ciblés de MediaQuery : MediaQuery.sizeOf(context) ne reconstruit que si la taille change, alors que MediaQuery.of(context) reconstruit aussi à l'ouverture du clavier ou à un changement de luminosité. C'est le même principe que select en Riverpod.

Layout : constraints go down, sizes go up

La règle tient en une phrase : les contraintes descendent, les tailles remontent, le parent fixe la position. Un parent transmet à chaque enfant des BoxConstraints (largeur et hauteur minimales et maximales). L'enfant choisit sa taille dans ces bornes et la renvoie. Le parent positionne ensuite l'enfant. Un widget ne connaît pas sa position à l'écran et ne peut pas choisir une taille hors de ses contraintes.

Les erreurs de layout se comprennent toutes avec cette règle.

Unbounded height : Column et ListView

Une Column donne à ses enfants non flexibles une hauteur maximale infinie (elle veut connaître leur taille naturelle). Une ListView veut occuper toute la hauteur disponible dans son axe de défilement. Infini contre « tout » : Flutter lève Vertical viewport was given unbounded height.

import 'package:flutter/material.dart';

Widget ecran(List<String> items) => Column(
      children: [
        const Text('Dernières transactions'),
        ListView(children: [for (final i in items) Text(i)]),
      ],
    );

import 'package:flutter/material.dart';

Widget ecran(List<String> items) => Column(
      children: [
        const Text('Dernières transactions'),
        Expanded(
          child: ListView.builder(
            itemCount: items.length,
            itemBuilder: (context, i) => Text(items[i]),
          ),
        ),
      ],
    );

shrinkWrap: true « corrige » aussi l'erreur, mais force la liste à mesurer tous ses enfants et supprime la virtualisation : à éviter sur une longue liste. Pour mélanger en-têtes et listes dans un seul défilement, la bonne réponse est CustomScrollView et les slivers (chapitre 04).

Expanded hors d'un Flex

Expanded et Flexible ne font que poser des parent data lues par un parent Flex (Row, Column). Placés sous un Container, un Stack ou un Padding, ils produisent Incorrect use of ParentDataWidget. Ils doivent être enfants directs du Row ou de la Column.

Autres classiques

• RenderFlex overflowed : un Text long dans une Row reçoit une largeur infinie. Enveloppez-le dans Expanded ou Flexible et définissez overflow.
• Container qui ignore sa taille : Container(width: 100) enfant direct de l'écran reçoit des contraintes serrées (tight) et prend tout l'écran. Un Center ou un Align relâche les contraintes.
• Hauteur infinie dans un ListView horizontal : un ListView horizontal dans une Column doit recevoir une hauteur explicite (SizedBox(height: ...)).

Pipeline d'une frame

Pour tenir 60 images par seconde, chaque frame dispose d'environ 16,7 ms (8,3 ms à 120 Hz). Le travail est réparti entre deux threads principaux.

1. Animate : les Ticker avancent les animations.
2. Build : les éléments dirty reconstruisent leurs widgets.
3. Layout : les RenderObjects marqués needsLayout calculent tailles et positions.
4. Paint : les RenderObjects enregistrent des commandes de dessin dans des layers.
5. Compositing : l'arbre de layers est assemblé en une scène et envoyé à l'engine.
6. Rasterization : sur le raster thread, Impeller transforme la scène en commandes GPU (Metal, Vulkan, OpenGL ES).

Le jank apparaît quand l'une des deux colonnes dépasse le budget : un build trop lourd ou un parsing sur l'UI thread côté Dart ; trop de saveLayer, d'opacités ou de flous côté raster. L'overlay de performance et DevTools affichent les deux graphes séparément, ce qui permet de savoir où chercher.

Impeller

Avec Skia, les shaders étaient compilés à la volée, la première fois qu'un effet apparaissait à l'écran. Cette compilation pouvait prendre des dizaines de millisecondes : c'est le shader compilation jank, une saccade à la première animation, impossible à corriger proprement (le préchauffage par SkSL était fragile et propre à chaque appareil). Impeller a été conçu pour supprimer ce problème : un ensemble fini de shaders est compilé au moment du build de l'engine, et les pipelines sont préparés à l'avance. Le coût de rendu devient prévisible.

Hot reload et hot restart

En mode debug, le code Dart tourne sur une VM avec compilation JIT. Le hot reload injecte les bibliothèques modifiées dans la VM en cours d'exécution, puis le framework reconstruit l'arbre. L'état est préservé : les objets State, les variables globales déjà initialisées, la navigation.

• Ce qui n'est pas réexécuté : main(), initState(), les initialiseurs de variables globales et statiques déjà évalués. Modifier l'un d'eux semble « sans effet ».
• Ce qui exige un hot restart : changement d'un enum en classe ou inversement, modification de types génériques, certains changements de signature, modification du code natif.

Le hot restart recompile et relance l'application Dart depuis main() : tout l'état Dart est perdu, mais le processus natif continue. Un changement natif (Kotlin, Swift, AndroidManifest.xml, ajout d'un plugin) exige une recompilation complète.

Modes debug, profile et release

Questions d'entretien

Exercices

Quiz

12 questions. Corrigez, relisez les explications, refaites-le 48 h plus tard.

Pour aller plus loin

• Flutter architectural overview
• Understanding constraints
• Impeller rendering engine
• Hot reload
• Flutter's build modes
• Rendering performance
• Key (API) et InheritedWidget (API)