Multiple Flutter screens or views

Contents

Experimental

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.

Scenarios

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 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.

Components

The primary API for adding multiple Flutter instances on both Android and iOS is based on a new FlutterEngineGroup class (Android API, iOS API) to construct FlutterEngines, rather than the FlutterEngine constructors used previously.

Whereas the 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.

  • FlutterEngines spawned from FlutterEngineGroup can be used to connect to UI classes like FlutterActivity or FlutterViewController in the same way as normally constructed cached FlutterEngines.

  • The first FlutterEngine spawned from the FlutterEngineGroup doesn’t need to continue surviving in order for subsequent FlutterEngines to share resources as long as there’s at least 1 living FlutterEngine at all times.

  • Creating the very first FlutterEngine from a FlutterEngineGroup has the same performance characteristics as constructing a FlutterEngine using the constructors did previously.

  • When all FlutterEngines from a FlutterEngineGroup are destroyed, the next FlutterEngine created has the same performance characteristics as the very first engine.

  • The FlutterEngineGroup itself doesn’t need to live beyond all of the spawned engines. Destroying the FlutterEngineGroup doesn’t affect existing spawned FlutterEngines but does remove the ability to spawn additional FlutterEngines that share resources with existing spawned engines.

Samples

You can find a sample demonstrating how to use FlutterEngineGroup on both Android and iOS on GitHub.

A sample demonstrating multiple-Flutters