The current memory footprint for each additional Flutter instance beyond the first instance is ~180kB on Android and iOS.
As of the 2.0.0 release, communication between Flutter instances is handled using platform channels (or Pigeon) through the host platform. To see our roadmap on communication, or other multiple-Flutters issues, see Issue 72009.
Before Flutter 2.0.0, multiple instances of
FlutterEngine and its associated
UI could be launched, but each instance came with significant latency
and fixed memory cost.
Multiple Flutter instances can be useful in the following scenarios:
- An application where the integrated Flutter screen is not a leaf node of the navigation graph, and the navigation stack might be a hybrid mixture of native -> Flutter -> native -> Flutter.
- A screen where multiple partial screen Flutter views might be integrated and visible at once.
The advantage of using multiple Flutter instances is that each instance is independent and maintains its own internal navigation stack, UI, and application states. This simplifies the overall application code’s responsibility for state keeping and improves modularity. More details on the scenarios motivating the usage of multiple Flutters can be found at docs.flutter.dev/go/multiple-flutters.
The 2.0.0 Flutter release drastically reduces the memory footprint of additional Flutter engines from ~19MB on Android and ~13MB on iOS, to ~180kB on Android and iOS. This ~99% fixed cost reduction allows the multiple Flutters pattern to be used more liberally in your add-to-app integration.
The primary API for adding multiple Flutter instances on both Android and iOS
is based on a new
FlutterEngineGroup class (Android API, iOS API)
FlutterEngines, rather than the
constructors used previously.
FlutterEngine API was direct and easier to consume, the
FlutterEngine spawned from the same
FlutterEngineGroup have the performance
advantage of sharing many of the common, reusable resources such as the GPU
context, font metrics, and isolate group snapshot, leading to a faster initial
rendering latency and lower memory footprint.
FlutterEnginespawned from the
FlutterEngineGroupdoesn’t need to continue surviving in order for subsequent
FlutterEngines to share resources as long as there’s at least 1 living
FlutterEngineat all times.
Creating the very first
FlutterEngineGrouphas the same performance characteristics as constructing a
FlutterEngineusing the constructors did previously.
FlutterEngines from a
FlutterEngineGroupare destroyed, the next
FlutterEnginecreated has the same performance characteristics as the very first engine.
FlutterEngineGroupitself doesn’t need to live beyond all of the spawned engines. Destroying the
FlutterEngineGroupdoesn’t affect existing spawned
FlutterEngines but does remove the ability to spawn additional
FlutterEngines that share resources with existing spawned engines.
You can find a sample demonstrating how to use
on both Android and iOS on GitHub.