In Flutter add-to-app, how does FlutterEngineGroup reduce the memory and startup cost of several Flutter screens, and what stays separate between its engines?

## When you need several engines On mobile, add-to-app is **multi-engine**: every simultaneously alive Flutter UI has its own `FlutterEngine`. That happens when: - the navigation stack mixes frameworks — native → Flutter → native → Flutter — and the earlier Flutter screen must keep its state; - one native screen shows several partial Flutter views at once, for example a loyalty card and a trip summary. Each engine is an independent Dart program with its own navigation stack, UI and state. That independence is useful for modularity, but constructing every engine directly costs full memory and start-up time each time. ## What FlutterEngineGroup shares Engines **spawned from the same `FlutterEngineGroup`** share reusable resources: - the GPU context; - font metrics; - the isolate group snapshot (the loaded Dart program). The Flutter docs describe the result as a low incremental memory cost of **about 180 kB** per additional Flutter instance, and a faster initial rendering latency. ## Lifetime rules | Situation | Cost of the next engine | |---|---| | First engine created from the group | Same as constructing a `FlutterEngine` directly | | At least one spawned engine still alive | Cheap: shares resources with the living ones | | All spawned engines destroyed | Full cost again, like the very first engine | | The group object itself destroyed | Existing engines keep working; no more cheap spawning | The **first** engine does not have to survive for later ones to share — only **some** engine from the group must be alive. And the very first engine per process, in any group, also pays the one-time Dart VM start. ## What stays separate Sharing is at the engine-resource level, not the Dart level: 1. Each engine runs its **own isolate**, so Dart objects, providers, caches and singletons are not shared. 2. Each engine has its **own navigation stack** and widget tree. 3. Engines talk to each other **through the host platform**, using platform channels or Pigeon; there is no direct Dart-to-Dart channel between them. Design consequence: put shared data — the signed-in user, loyalty balance — in the host or in a store every engine reads, not in a Dart singleton you expect all screens to see. ## Wiring it up Android: ```kotlin // Application.onCreate val group = FlutterEngineGroup(this) FlutterEngineGroupCache.getInstance().put("airline_group", group) // Launching a screen startActivity( FlutterActivity.withNewEngineInGroup("airline_group") .dartEntrypoint("loyaltyMain") .initialRoute("/points") .build(this) ) ``` Or create engines directly with `group.createAndRunEngine(context, dartEntrypoint)` and cache them. `FlutterFragment.withNewEngineInGroup` exists for fragments. iOS: create a `FlutterEngineGroup` with `initWithName:project:` and spawn engines with `makeEngineWithEntrypoint:libraryURI:`, then pass each to a `FlutterViewController`. A custom entrypoint such as `loyaltyMain` must be annotated in Dart so it is not tree-shaken: ```dart @pragma('vm:entry-point') void loyaltyMain() => runApp(const LoyaltyApp()); ``` ## Judgment calls - One pre-warmed engine reused across visits keeps state but holds memory while idle; a group of short-lived engines keeps each cheap but loses state when an engine is destroyed. - Several live engines still each hold their own Dart heap; 180 kB is the incremental fixed cost, not the whole cost of a screen with images and data. - Watch plugins that assume a single engine or a single instance: each engine creates its own plugin instances.