Author: Idle fish technology – the real thing

Writing in the front

Currently, The Xianyu client has implemented the full reconstruction of product details page based on Flutter, with good online results. Since Alpha, we have encountered many problems that have been solved one by one, either on principle, through the community, or in collaboration with the authorities. It is time to sort out and summarize, and hopefully provide inspiration and help to other developers, especially those already working on the progressive refactoring of Flutter. In view of the existence of multiple problems a cause or solution, and the focus of this series is to illustrate the solutions and ideas of various problems, not a list of problems. All Debug/thermal overload associated wipes are Debug mode wipes and are not specified.

This series of articles consists of three parts: introduction, operation and launch. The introduction focuses on the engineering RESEARCH and development system; The running chapter introduces the stack management and capacity complement under the mixed scenario. The introduction of compatibility/stability assurance and methods.

Key points of the engineering R&D system include:

A. Flutter development structure under hybrid engineering

How about a global perspective of the research and development structure in hybrid engineering.

B. Engineering structure

How to introduce Flutter into existing Native projects, how to organize the engineering structure, how to manage the Flutter environment, how to compile and build, integrate and package, etc.

C. Construction optimization

This section describes how to debug and optimize Flutter toolchains (Flutter_tools, Intellij, etc.).

D. ative start up Flutter debugging

This is what I call separate Flutter debugging, unlike the all-in-one Flutter debugging under Flutter startup, this Native startup (Xcode/Android Studio startup, or click the icon to open the application). Separate debugging simplifies the complexity of Flutter_tools and improves debugging stability and flexibility.

E.native starts the hot overload of Flutter

With d.

F. Joint debugging

Debug Flutter and Android/iOS simultaneously.

G. Continuous integration

Namely, Flutter construction and continuous integration in a mixed environment.

The environment that

Flutter development structure under hybrid engineering

Engineering structure

The core logic of this section is how to run Flutter with minimal changes to existing iOS/Android projects. Flutter can be partially understood as a separate module, introduced into the main project by CocoaPods and Gradle via pod libraries (iOS) and AAR libraries (Android).

For specific principles and practices, please refer to:

In-depth understanding of flutter compilation and optimization

Retrofit practice of Flutter hybrid engineering

Add Flutter to existing apps

We managed the whole Flutter environment as a Git Submodule to ensure a consistent environment within the team and unified handling of individual problems/requirements.

Building optimization

Optimization of compile speed (Android)

Problem :Android builds slowly when started by Flutter.

Cause: When Android /app/build.gradle is not found in the logic of the flutter toolchain (Flutter_tools), gradle Build is run to build multiple compiled configurations instead of Gradle assembleDebug.

Solution: Reconstruct the Android project so that the build.gradle corresponding to the project Module is located under Android /app, which conforms to the logic of Flutter_tools.

Principle: Debugging flutter_tools

A. Modify flutter_tools.dart to print parameters

B. delete flutter/bin/cache/flutter_tools stamp that flutter_tools can be rebuilt

C. Run the build from the flutter to obtain its entry parameters

D. Open the Flutter_tools project with Intellij, create the Dart Command Line App, and configure “Program arguments” based on the input parameters obtained in Step C.

E. Start your Flutter_Tools debugging tour

Optimization of compile speed (iOS)

Error: the Flutter build reported “Observatory connection never became ready “, causing the build to be interrupted

Cause: The full build time of our project before refactoring was long (1000+ file full build time >10min), and the build of Flutter Intellij was interrupted due to a timeout logic.

Solution A: Customize the Flutter Intellij plugin (modify the timeout in the code below), compile the plugin, and replace the Flutter plugin in Android Studio. A more logical solution would be to mention PR, but this is basically a non-stop process of solving various productization problems, so… (This logic has been removed in the latest version)

Principle:

Go to the source of Flutter Intellij

In fact, when we developed Flutter using the IDE, we had the following logical flow:

Solution B (middle solution):iOS project module splitting and Pod(Framework), the main project construction depends on the compiled Framework, greatly speeding up the construction time.

Principle: Modular + precompiled Framework

Solution C: Flutter debugging from a Native perspective

Principle: Flutter debugging and thermal reloading at Native startup

Flutter debugging from a Native perspective

Flutter debugging and thermal overload logic under Flutter startup

In fact, when a Native project is configured with Flutter support, the main things that Flutter does are:

A. Check whether flutter_tools.snapshot needs to be generated again.

B. Obtain dependencies based on pubspec.yaml and generate plug-in description files.

C. Generate Generated. Xcconfig (iOS) and local.properties(Android) based on Flutter configuration, such as Framework path, Debug/Release mode, and whether Dart2 is enabled.

D. Build applications based on Gradle and XcodeBuild (see the previous article for further understanding of Flutter compilation and optimization).

E. Start the application based on ADB and LLDB.

F. Wait for the Flutter to start in the application, look for the Observatory port, and connect to the Dart Debugger for debugging.

G. After the port is found, the Hot Reload files are synchronized and the Full Restart or Hot Reload is implemented through Daemon listening commands (such as the user clicking the plug-in button).

From another perspective, if we can solve Dart debugging and Hot Reload under Native startup, slow compilation caused by Flutter_tools will not be a problem, and unstable debugging environment can be solved (for example, in our scenario, after application startup, Flutter starts only when the user clicks on the details page, at which point Flutter_tools can discover Observatory ports, debug, and hot reload, which often doesn’t work well. We need to pay attention to abcfg when launching the iOS app that contains Debug mode Flutter content from Xcode (or click the desktop icon to launch, not to repeat). ABC does not need to be re-executed unless flutter_tools or pubspec.yaml or Flutter configuration changes, etc. Fg is the debugging and thermal overloading that r&d depends on, so we must consider how to support it in this mode.

Debugging and thermal overload logic of a Flutter under Native startup

A. Search for the Observatory port on the iOS device

Alternatively, the command line can be obtained from idevicesyslog. Here, the LibiMobileDevice library is involved, which contains idevicesyslog, iProxy and other commands.

You can see that on the iOS device, the Observatory has launched a XXXX port (random port number).

B. Use iProxy to map port XXXX on the iOS device to local port YYYY

C. Waiting for connection (waiting for connection)

You can use the Observatory to check many DART related memory, debug, and so on. It is not expanded here.

Debugging can also be done via the IDE link:

D. Configure Dart Remote Debug

Note here that the port is the one just forwarded to the computer: YYYY. The search source path is the root directory of the Flutter project.

E. After the configuration, click Debug to connect to the debugging port

F. If Connected is displayed, click the green debug button ️ again.

G. You can then set breakpoints and debug dart(Flutter) code normally using the IDE

Thermal overload of a Flutter from a Native perspective

A. Start App, enter the Flutter page, search for Observatory port XXXX, and send it to computer YYYY (same as above AB).

B. Run the Flutter attach –debug-port= YYYY command in the Flutter project directory

C. Modify the DART source code, and enter r in Terminal B (after ‘To quit,press”q”‘)

Here we replace the awesome copy with the awesome copy.

D. Terminal displays “Initializing hot reload… Reloaded…” , the change takes effect on the device (the copy in the lower left corner becomes like)

Under the Android Native Flutter debugging/hot start overloading similar iOS, the difference is for port through the IDE logcat or the adb logcat | grep Observatory, port forwarding use adb forward.

Native is modulated with Flutter

The previous article described how to debug the Flutter at any time after the Flutter has been started. We can also debug Android using Android Studio’s Attach Debugger to the Android Process. This allows Android to be combined with Flutter. Similarly, iOS and Flutter can be combined with Xcode Attach to Process.

Continuous integration

The current team includes Native students and Flutter students, so we distinguish Flutter mode from Native mode. There is a common device (Mac Mini) that installs the Flutter environment and is responsible for the build of the Flutter. The built product is integrated into the Native project in the form of an AAR (Android) or pod library (iOS) (think of the Flutter code as a module). The CI platform used to build the end product APK (Android) or IPA (iOS) is also eventually integrated with Flutter and packaged by product.

For more details, see:

Best practices for continuous integration of the Idle Fish Flutter hybrid Engineering

Write in the back

This paper mainly introduces the engineering research and development system under mixed scenarios. Having solved this problem, the next step is to solve the problems encountered in actual business development. For example, how to manage the stack when the Native and the Flutter jump to each other, how to complete the functions that the Flutter cannot implement (platform features, etc.), and how to manage the Flutter Plugin/Dart Package, please pay attention to this series.

Contact us

If you have any questions or corrections about the content of the text, please let us know.

Idle fish technology team is a dapper engineering technology team. We not only pay attention to the effective solution of business problems, but also promote the cutting edge practice of computer vision technology in mobile terminals by breaking the division of division of technology stack (the unification of android/iOS/Html5/Server programming model and language). As a software engineer in the Idle Fish technology team, you have the opportunity to demonstrate all your talents and courage in the evolution of the entire product and user problem solving to prove that technology development is a life-changing force.

Resume: [email protected]