This article will give you an in-depth look at how Flutter packaging and plug-in installation work, and help you quickly integrate Flutter into existing Android projects, enabling mixed development support.

Article summary address:

A complete series of articles on Flutter

A series of articles on the world outside Flutter

One, foreword

With the emergence of various cross-platform frameworks, hybrid development is often used as a scaffold, because companies do not put their business on a single framework, and unless it is a new project, hybrid development will try to sink into the pit due to the cost and risk of refactoring the original business.

Hybrid development, however, requires more familiarity with the packaging, build, and startup processes, and has more problems. I wrote a similar article on React Native before: From Android to React Native Development (IV, package process analysis and release into Maven library). There are a lot of common experience in this aspect, so an appropriate mixed mode can help avoid some problems. At the same time, only by understanding the construction idea of the whole Flutter project, can we get into a more comfortable position.

As an additional remark, the significance of cross-platform is to solve the unification of multi-terminal logic, at least to avoid repeated implementation of logic, so enterprises generally choose some lightweight businesses to try at the beginning.

Officially there will beFlutter build aarMethods are available for use.

Second, the packaging

There are two options for cross-platform hybrid development:

  • 1, will beFlutterThe overall framework dependencies and packaging scripts are integrated into the main project.
  • 2,aarThe complete library integration form is added to the main project.

Both implementation methods have advantages and disadvantages:

  • The first approach makes it easier to fix problems at run time, but it is more “dirty” to the main project, and the changes are larger.

  • The second method requires that the AAR file be updated separately and then integrated into the project for debugging. However, this method is cleaner and the Flutter code can run tests independently with less change.

Generally speaking, FOR ordinary projects, I suggest to integrate into the project in the second way, by creating a Flutter project and componentized script processing for the project, so that it can run and debug independently in the form of APK and be packaged to provide external support in the form of AAR.

If you’re familiar with native platforms, you can quickly add flutter_app_lib by simply modifying the gradle script, as shown below.

When the project is published as a lib, set isLib to true and execute./ Gradlew assembleRelease. The rest of the work is still the packaging process of Flutter itself. For packaged AAR files, the dependencies can be completed by introducing them directly into the native project.

For general access, if information such as token and user data is required, it is recommended to define a native interface, such as init(String Token, String userInfo), and then synchronize the information to Flutter through MethodChannel.

For the native master project, you just plug in the AAR file, initialize it, and open the page without worrying about its internal implementation, just like introducing normal dependencies.

You may also need to modify the start MainActivity in AndroidManifset to remove it and then add a custom Activity to inherit FlutterActivity for customization.

Third, the plug-in

Normally, this would have done the job of integrating Flutter. However, this is not always the case. Some Flutter plug-ins provide their functionality through native code. Flutter_webview, Android_intent, device_info, etc. How are they referenced?

If you have used React Native, you need to install the React Native plugin using the React-Native link command after NPM installation. This command triggers the script to modify the native code, which modifies gradle scripts to add references to the plug-in project, and modifies the Java code to implement the plugin’s template introduction, which makes the project somewhat “polluted” by the plug-in.

React Native plugins will be introduced as Native Module projects. How about Flutter?

The principle of Flutter is that the plugin with native code is also introduced as a local Module Project after the plugin is installed, but the whole process is more subtle and makes the process almost non-intuitive.

If you have noticed, after the plugin is installed, all plug-ins with native code are stored in the.flutter-plugins file as their path and key=value of the plugin name.

In the Android project settings.gradle, as shown below, the.flutter-plugins are included into the main project one by one by reading this file.

Apply from the main project “$flutterRoot/packages/flutter_tools/gradle/flutter gradle” the introduction of the script, This script is commonly flutterSDK/packages/flutter_tools gradle/directory, as shown in the following code, one of the most critical part of the same is read. The flutter – plugins files in the project, And then implement one by one into the main project to complete the dependencies.

Since all native code Flutter plug-in, have been as a local Module Project, the introduction of the main Project in the form of the final script will automatically generate a GeneratedPluginRegistrant. Java file, realize the native code references to register, And the process is completely insensitive to you.

All that said, since plug-ins are treated as nativeModule ProjectThen it would be problematic to package an AAR directly as before:

When ‘Android’ gradle ‘scripts are packaged by default, for’ project ‘and remote dependencies only references are packaged, not source code and resources.

Therefore, the support of FAT-AAR is needed. The detailed concept of FAT-AAR can be seen as follows: Android to React Native is a plugin that allows you to merge referenced code and resources into an AAR.

As shown in the following code, we added the Apply plugin to the original componentized script: Import the plugin ‘com.kezon.fat-aar’ and embed references to the.flutter-plugins file by referring to the Flutter script. The aar file is then packaged as the complete Flutter project code.

The full version is visible in Flutter_app_lib.

Four, stack,

The last thing that needs to be addressed is the stack.

If there is one thing that is most difficult to deal with in hybrid development, it is stack management between platforms. We generally avoid hybrid stack calls to each other, but when we have to do so, the idle fish come up with their answer: fluttet_boost.

We know that the whole Flutter project is drawn on a Surface canvas, while Fluttet_boost unites the stack into the native layer, drawn by a singleton Flutter engine.

Each FlutterFragment and FlutterActivity is a Surface bearing container. When switching pages, the Surface rendering display is switched, and the pages that are not rendered are displayed by Surface screenshot cache.

So the wholeFlutterIs mapped to the native stack and managed uniformly by the native page stack,FlutterWithin eachpushOne page is one pageActivity 。

Flutter_boost is only supported before 1.2 as of my test date of 2019-05-16. The overall flow of Flutter_boost is relatively complex, and dialogs are not well supported, and black screens can occur when business jumps are too deep.

And with that, canto XIV comes to an end! (/ / / del / / /)

Resources to recommend

  • Demo: github.com/CarGuo/flut…
  • Making: github.com/CarGuo/
  • Open Source Flutter complete project:Github.com/CarGuo/GSYG…
  • Open Source Flutter Multi-case learning project:Github.com/CarGuo/GSYF…
  • Open Source Fluttre Combat Ebook Project:Github.com/CarGuo/GSYF…
Full open source project recommendation:
  • GSYGithubApp Flutter
  • GSYGithubApp React Native