background

With the development of Flutter, more and more APPS in China begin to use Flutter.

To reduce the risk, most apps adopt a progressive approach to incorporating Flutter. Select a few pages in your App to write Flutter, but they all encounter the same problems.

How do I manage routing when native and Flutter pages coexist?

No such solution is officially provided, and FlutterBoost is designed to solve this problem.

FlutterBoost has been welcomed by community developers since it was open source. Many apps have used FlutterBoost, and community developers are also active, raising many issues and PR.

Thank the developers for their support and tolerance. We will carefully read the feedback and ridicule and continue to pay attention to the Issue.

mission

The mission of FlutterBoost is to make it very easy for developers to develop Flutter pages within the native App.

FlutterBoost, as the superlayer solution of Flutter SDK, has some limitations. We need to rely on the SDK’s more open capabilities. So we’re doing two things at once:

▐ Push Flutter to officially open more underlying interfaces

We participated in the discussion of Multiple Flutters[1] of the Flutter organization and emailed the Flutter team several times to report SDK bugs and unsupported application scenarios.

It is gratifying to see significant progress in hybrid development on Flutter 2.0.

FlutterEngineGroup is available in Flutter2.0. FlutterEngineGroup creates a new Engine with only 180K more memory, which gives us a lot of room for imagination.

However, the biggest problem of FlutterEngineGroup is that memory sharing among multiple engines is not at the isolate level.

At present, FlutterBoost, a single Engine memory sharing method, cannot be completely replaced.

▐ FlutterBoost upgrade

While the open source community is active, there are many stars, and many users, FlutterBoost is far from a good open source project. Flutter

The problem of the Boost

Existing problems

  • Stability Every time a Stable version of Flutter is released, developers will ask me if FlutterBoost has been adapted for the new version. They were going to upgrade to a new version and needed FlutterBoost to be compatible with the latest version. I had to pull two new branches (Androidx and Support) for each new version to adapt. After a long time, many branches will be generated, which brings great cost to branch management. For example, an issue repaired in one branch needs to be synchronized to other branches, and synchronization may be omitted if it is not careful.

  • Community issues do not tend to converge.

  • The design is too complex and there are too many concepts. This makes it difficult for a novice to see the code in FlutterBoost.

These issues led to a redesign of the design, and in order to address these stubborn issues once and for all, we made a major update, which we named FlutterBoost 3.0 (the last update was 2.0).

What does Flutter Boost 3.0 do

To address the above problems, we have done the following:

  • It does not invade the engine and is compatible with all versions of Flutter. Upgrading the Flutter SDK does not require upgrading FlutterBoost, greatly reducing the upgrade cost.
  • No distinction between Androidx and Support branches.
  • Simplified architecture and interfaces, with half the code compared to FlutterBoost2.0.
  • Dual-end unification, including interface and design unification.
  • Support to open the Flutter page without opening the container scene.
  • Notification of page lifecycle changes is more convenient for business use.
  • Solve the legacy problems in 2.0, such as difficult Fragment access, unable to transfer data after the page is closed, Dispose does not execute, too high memory usage.

Access and use of Flutter Boost3.0

access

Flutter_boost: git: url: 'https://github.com/alibaba/flutter_boost.git' ref: 'v3.0 - beta. 3'Copy the code

FlutterBoost3.0 is currently in beta and in public beta.

Access to the archives mouths

For details, see github.com/alibaba/flu…

Flutter2.0 new feature Flutter EngineGroup

FlutterBoost adopts a single Engine scheme, so the entire App is under the same Isolate and the memory is shared.

However, FlutterEngineGroup adopts a multi-engine scheme. Each page is an Engine, or a page contains multiple engines and each Engine corresponds to an Isolate. The memory is not shared. For FlutterEngine generated from FlutterEngineGroup, only 180K of memory is added.

Because it shares commonly used resources (such as GPU context, font metrics, and snapshots of isolated threads), it speeds up first rendering, reduces latency, and reduces memory footprint.

Does having a FlutterEngineGroup eliminate the need for FlutterBoost?

At present, FlutterBoost, a single Engine scheme, is reasonable to some extent and cannot be completely replaced.

Future development of Flutter Boost

I will continue to do the following three things:

  • FlutterBoost3.0 will continue to be refined and optimized in the single Engine direction to make it more stable and support more scenarios.
  • Communicate with Flutter officials, including whether they can support memory sharing with FlutterEngineGroup on the isolate level.
  • Explore the new hybrid stack under Flutter2.0 multi-engine scheme.