Author: Idle fish technology – word flat

background

The Xianyu Technology team was the first to introduce the Flutter technology in the first half of 2018 in an attempt to unify the client development and successfully transform and bring the complex commodity detail business online. In this process, since the existing iOS and Android projects were quite large, how to connect the Flutter seamless bridge to these projects and ensure that the development efficiency was not affected became a priority. This paper presents a general engineering transformation scheme for project practitioners, hoping to provide a reference for the team preparing the transformation of Flutter.

The problem

The engineering structure of Flutter is special. It consists of the Flutter directory and the directory containing Native projects (ios and Android directories) respectively. By default, a Native project that introduced Flutter cannot be built and run independently of its parent directory, because it would rely in reverse on the libraries and resources associated with Flutter.

Typical Flutter catalog structure

Obviously, with the Native project in place, it is unlikely that the developers will create a whole new Project to rewrite the entire product, so the Project Flutter will include the existing Native project, which brings a number of problems: __1). Build packaging issues: With the introduction of the Flutter, Native projects could not build independently due to dependencies and coupling with it. Project construction in the Flutter environment starts with the construction command of the Flutter, and the execution process includes the construction of the Native project. The developer needs to configure the complete operation environment of the Flutter to go through the whole process. __2). Reduction in development efficiency caused by mixed compilation: In the process of transforming Flutter, many businesses must still be developed using Native. The change of engineering structure will make the development unable to be carried out in the pure Native environment, and adapting to the engineering structure of Flutter will cause unnecessary construction steps for the pure Native development, resulting in the reduction of development efficiency.

The target

In view of the above problems, we propose the following modification goals to minimize the reliance of Native project on the Flutter related documents, so as to: 1).Native engineering can be compiled, built, debugger and executed independently, thus minimizing the interference to relevant developers and making the packaging platform no longer dependent on the Flutter environment and related processes; 2).Native Agents rely on the relevant libraries and files in the Flutter environment (i.e., as an ios or Android subdirectory) to perform the various Flutter functions normally, such as building, debugging, and hot reload of the DART code, to ensure the correctness of the development of the Flutter environment.

Plan formulation

Two modes

The first step is to define Native projects in the Standalone directory environment called Standalone mode and in the Flutter directory called Standalone mode. While the target is pure Native development or platform packaging in Standalone mode, Flutter is transparent to both the developer and the packaging platform and does not interfere with build and debugging; The code for the Flutter is developed in the Flutter mode, and the related libraries are generated, compiled, and debugged through the process defined by the Flutter.

Two modes

Clarify rely on

From the definition above, the core of the transformation is to extract the Standalone mode, which depends on Flutter, and extract it into a third-party library, resource, or source file. Taking iOS as an example, by reading the source code of the Flutter, we can see that the Xcode project has the following dependencies on the Flutter: 1).app. framework: Dart business source related files 2).flutter. Flutter engine library file 3). Pub plugin directory and file for indexing: Plug-ins under Flutter, including various system and custom channels 4). Flutter_assets: Static resources that Flutter depends on, such as fonts, images, and so on

Depends on the policy introduced

In the process of transformation, Xianyu has tried two dependency introduction strategies, which are respectively described below. 1). Local dependency: By modifying the construction process of Flutter, its library files, source code and resources are directly placed into the subdirectory of Native project for reference. Taking iOS as an example, the framework and related plug-ins are made into local POD dependency, and the resources are copied to the local for maintenance. Thus, the Standalone mode provides the ability to build and execute independently. For pure Native developers, Flutter is just a collection of two libraries and resources that need no attention. However, under Flutter mode, the construction process of DART source code is unchanged, which does not affect compilation and debugging. Also due to local dependencies, changes to the Flutter mode can be synchronized to the Native project subdirectory in real time, and the Standalone mode has the latest Flutter related features once the changes are submitted. The advantages of __Flutter: changes related to the __Flutter can be easily synchronized to the Standalone mode. __ Disadvantages: __ requires slightly complex changes to the original construction process of the Flutter, conflicts with subsequent merging of the Flutter code, and Native engineering and the contents of the Flutter are still not coupled locally independently. 2). Remote dependency: The idea of remote dependency is to place all of Flutter’s dependencies in a separate remote repository. In the Standalone mode, the relevant resources, source code and library files in the remote repository are referenced, while the build process and reference method in the Standalone mode remain unchanged. __ Advantages: __ has fewer changes to the construction process of the Flutter itself and more thoroughly solves the problem of local coupling; __ Disadvantages: __ synchronization process becomes more cumbersome, changes to the Flutter content need to be synchronized to the remote repository and then synchronized to the Standalone mode for the Standalone mode to take effect. PS. Idle Fish eventually chose this strategy.

Long-range dependence

Realization of transformation

Organization of directories

In Flutter mode, the ios and Android subdirectories of the parent project directory respectively contain corresponding Native projects. In code management, the sub-projects can use git submodule form to ensure the independence between directories.

Implementation of remote dependencies

In the Standalone mode, the dependencies of the Flutter all point to the corresponding files in the remote repository, while the dependencies remain the same in the Standalone mode. Synchronizing the Flutter to Standalone mode is cumbersome due to the remote dependency issue, so Xiandao has developed a series of scripting tools to automate the process as much as possible. Assuming that the content of the Flutter (be it business source code, engine library, or some resource file) changes, the script will extract all the generated dependent files and copy them to a remote repository, submit them, and tag them. A new remote dependency description (such as a PodSpec for iOS) is generated based on the tag, and the synchronization process is completed by modifying the dependency of the Flutter to the latest version in Standalone mode.

The synchronization process

2) Timing of synchronization During testing and grayscale, each submission of Flutter can trigger the execution of synchronous scripts and app packaging; Synchronize once a day during development.

conclusion

To solve the engineering adaptation problem after the introduction of Flutter, we extracted the relevant dependencies of Flutter to be referenced remotely by pure Native projects, so as to ensure the independent and parallel execution of Flutter and pure Native development. Several versions of the scheme have been implemented in Xiashu and exported back to the Flutter team to provide direction and reference for their subsequent organizational plans for the Hybrid project. At the same time, I believe that this project can also help the team to transform the Flutter. Of course, differences between projects can also lead to different projects, so I hope to have more communication if there are better methods and opinions! Finally, xianyu technology team is looking for talents in all directions, whether you are proficient in mobile terminal, front end, background, machine learning, audio and video, automated testing, etc., you are welcome to submit your resume and join us, together with technology to improve life!

Resume delivery: [email protected]