Author: Idle fish technology – stone qing

background

With the development of Flutter, more and more APPS in China begin to use Flutter. In order to reduce the risk, most apps adopt a progressive approach to incorporating a Flutter. Select several pages in your App to write a Flutter, but they all encounter the same problem: how to manage the route when the native page and the Flutter page 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 participate in the discussion of Multiple Flutters[1] of Flutter organization. I also emailed the Flutter team several times about SDK bugs and some unsupported application scenarios. It is nice to see the great progress in hybrid development of Flutter2.0. FlutterEngineGroup is provided in Flutter2.0. FlutterEngineGroup creates a new Engine with only 180K more memory, which gives us a lot to imagine. 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.

The problem of FlutterBoost

Combed through the questions:

•

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 FlutterBoost3.0 do

In response to the above problems, we have done several things

• Does not invade the engine and is compatible with all versions of Flutter. Upgrades to the Flutter SDK do not need to update 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. • Solved the legacy problems in 2.0, such as difficult Fragment access, unable to transfer data after the page is closed, Dispose does not execute, and too high memory usage.

Architecture diagram

The FlutterBoost plug-in is divided into two ends of the platform and Dart, connected through the Message Channel. The platform side provides the configuration and management of the Flutter engine, creation/destruction of Native containers, notification of page visibility changes, and interface to open/close Flutter pages. In addition to providing a page navigation interface similar to native Navigator, the Dart side is responsible for the route management of Flutter pages

Non-intrusion engine

In order to solve the problems caused by the reuse of the official engine, FlutterBoost2.0 copies some of the embed code of the Flutter engine for modification, which makes the upgrade cost very high. And FlutterBoost3.0 adopt the way of inheritance extension FlutterActivity/FlutterFragment the ability of components, and by at the right time to Dart side appIsResumed messages sent to solving engine reuse the page life cycle events disorder lead to stuck problem. FlutterBoost3.0 is also compatible with Flutter 2.0, the latest official release.

No distinction between Androidx and Support branches

FlutterBoost2.0 FlutterActivityAndFragmentDelegate was achieved by themselves. The Host interface to extend FlutterActivity and FlutterFragment ability, GetLifecycle is the interface that must be implemented, which leads to a dependency on androidx. This is why the implementation of FlutterBoostView is not included in the FlutterBoost3.0 plug-in. By inheritance and FlutterBoost3.0 ability to expand FlutterActivity/FlutterFragment extra income is, can not rely on androidx.

Unified dual-end design and unified interface

Many Flutter developers know only one end, either Android or IOS, but they need access to both ends, so this can reduce their learning costs and access costs. In the design of FlutterBoost3.0, both Android and IOS have made alignment, especially the parameter level alignment on the interface.

Supports the “Open the Flutter page without opening the container” scenario.

In many scenarios, the Flutter page jumps to the Flutter page without opening the container. Do not open the container to save memory overhead. In FlutterBoost3.0, the difference between open and unopen containers is simply whether the withContainer parameter is true on the user interface. The code is as follows:

InkWell(child: Container(color: color. yellow, child: Text(' open external route ', style: TextStyle(fontSize: 22.0, color: Colors.black), )), onTap: () => BoostNavigator.of().push("flutterPage", arguments: <String, String>{'from': UniqueId}),), InkWell(child: Container(color: Colors. Yellow, child: Text(' open internal routing ', style: TextStyle(fontSize: 22.0, color: color.black), onTap: () => BoostNavigator.of().push("flutterPage", withContainer: true, arguments: <String, String>{'from': widget.uniqueId}), )Copy the code

Precise notification of the life cycle

On FlutterBoost2.0, each page receives a page lifecycle notification, whereas FlutterBoost3.0 only notifies pages whose visibility has actually changed, and the interface is more in line with flutter design.

Top Issue to solve

Statistics and classification were made for the issues with more feedback, and the following issues were mainly solved

• The transfer of parameters after the page is closed, which was previously only supported by iOS but not Android, is now implemented on the DART side, supported by both iOS and Android. • The android status bar font and color issues are resolved. • Fixed page rollback willPopScope not working. • Fixed life cycle callbacks for pages not at the top of the stack • Fixed multiple setState performance issues. • Demo of Various Framgent access modes is provided to facilitate TAB access. • Lifecycle callback code can be accessed with user code, easier to use. • Simplified access costs across the board, including the DART side, android side, and ios. • Enriched demo to include basic scenarios for user access and test regression.

FlutterBoost3.0 access and usage

access

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

Currently, FlutterBoost3.0 has released a beta version and is currently in public beta.

Interface documentation

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

New feature FlutterEngineGroup for Flutter2.0

FlutterBoost adopts a single Engine scheme, so the whole App is under the same Isolate and the memory is shared, while FlutterEngineGroup adopts a multi-engine scheme, each page is an Engine, or a page contains multiple engines. Each Engine corresponds to an Isolate, and 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 FlutterBoost

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. • continuously communicate with Flutter officials, including whether they can support memory sharing with FlutterEngineGroup at the isolate level. • explore new hybrid stacks under Flutter2.0 multi-engine solution.

References

[1] Multiple Flutters: docs.google.com/document/d/…