Flutter practice – cross platform development



With the convergence of mobile terminals from birth to development everywhere and then to platform, in order to continuously meet the enterprise’s pursuit of development efficiency and cross platform consistency, various cross platform solutions emerge in endlessly. For our product design and development, development efficiency and use experience are two crucial factors. If you are in the front end, you have to embrace cross end, which is a trend that is not transferred by human will. In order to reduce the development cost and maintenance cost of cross platform development, it is essential to reduce the development cost of cross platform adaptation.

Scheme evolution

Regardless of the size of the cross platform scheme, according to its core design idea, it can be divided into three stages

  • Web container
    Realize page and business functions based on the native browser components of the device system. Representative programs include Cordova et al
  • Pan web container
    Web standard is adopted for development, and the native system is responsible for rendering at run time. Representative schemes include RN, weex, etc
  • Self rendering engine
    With its own rendering engine, the client only needs to provide canvas to realize the multi terminal consistent rendering experience from business functions to UI. Representative scheme: flutter

Let’s analyze the different design ideas and respective advantages of these three stages one by one

Web container

The scheme of web container is the simplest and easiest to operate. It mainly uses the browser controls embedded in the native system (WebView of Android and wkwebview of IOS) to render H5 pages. The client defines the interaction protocol with HT, exposes some native system capabilities to H5 and invokes them through JS, which is called jsbridge.
The interactive design of web container can be presented intuitively through the following figure

Flutter practice - cross platform development

Web container png

The final rendering Party of this scheme is the browser. The presentation of an H5 page needs a more complex process. We can show the most basic loading process to know the complexity of this process.

  1. The browser control loads the HTML main document of the HTML5 page.
  2. When an external CSS file is encountered during loading, the browser sends another request to obtain the CSS file.
  3. In case of image resources, the browser will also send another request to obtain image resources. This is an asynchronous request and does not affect the loading of HTML documents.
  4. JavaScript files are encountered during loading. Because JavaScript code may modify the DOM tree, the rendering thread of HTML document will be suspended (loading, parsing and rendering synchronization). The rendering thread of HTML document can not be restored until the JavaScript file is loaded, parsed and executed.
  5. The attribute style in the CSS file is used in the JavaScript code, so it is blocked and can not be resumed until the CSS is loaded.

From this process, we can see that the rendering of a completed H5 page goes through three processes: browser control loading, parsing and rendering, and the performance consumption and rendering efficiency are greatly increased compared with the original page. Although the web container scheme has the advantages of friendly development experience and strong cross platform compatibility, it needs to carry a large number of protocol standards specified with the web, which will lead to the container being too cumbersome, and it is difficult to realize complex interaction and present a better user experience

Pan web container

The pan web container scheme optimizes the three processes of browser loading, parsing and rendering of the web container scheme, tailors the web standards that affect their independent operation, supports the necessary web standards for building mobile pages (such as flexbox) in a relatively simple way, and also ensures a convenient front-end development experience; At the same time, the solution of this era basically completely abandons the browser control rendering, but uses the native UI component instead of the core rendering engine, and only maintains the necessary basic control rendering ability, so as to simplify the rendering process and ensure good rendering performance. In other words, in the era of Pan web container, we still use front-end friendly JavaScript for development. The overall loading and rendering mechanism is greatly simplified, and the native system takes over the rendering, that is, the native system is used as the back-end of rendering to provide the required UI control entity for JavaScript code relying on JavaScript virtual machine. This is also the idea of most cross platform frameworks. RN and weex adopt this design scheme.

Flutter practice - cross platform development

Pan web container png

In order to pursue better performance experience and further the simple scalability of location solutions, some companies have abandoned web standards. Abandon the dynamic execution capability of JS and develop a set of native DSL parser to realize cross end solutions, such as tmall, meituan, Didi, etc.

Self rendering engine

The pan web container scheme uses native controls to host interface rendering, which solves many performance problems, but also brings new problems. Aside from the framework itself, we need to deal with a large number of platform related logic. With the change of system version and API, we also need to deal with the difference of rendering ability of native controls on different platforms and repair all kinds of strange bugs. Follow native thinking is always needed, while flutter uses a new idea, that is, rewriting a set of cross platform UI framework from beginning to end, including rendering logic and even development language.

  • The rendering engine relies on the cross platform skia graphics library. The skia engine will process the abstract view structure data constructed by dart into GPU data, which will be finally provided to GPU rendering by OpenGL. So far, the rendering closed loop is completed. Therefore, the consistency of experience of an application on different platforms and devices can be guaranteed to the greatest extent.
  • The development language is dart, which supports JIT (just in time) and AOT (ahead of time), which not only ensures the development efficiency, but also improves the execution efficiency (much higher than the pan web container scheme developed with JavaScript).

    Flutter practice - cross platform development

    Self rendering png

Through this idea, fluent can reduce the differences between different platforms as much as possible, while maintaining the same high performance as native development. Flutter has become the most flexible of the three types of cross platform mobile development schemes. At present, it is also a cross platform scheme with relatively high popularity.

Our choice

Comparing the most representative frameworks of the three schemes, we can compare their different advantages and disadvantages

Flutter practice - cross platform development


When making technology selection, we should comprehensively consider the team size, development efficiency, technology stack, performance, maintenance cost and community ecology. For example, do you have to support dynamism? Is it just to solve the cross end problems of Android and IOS, or to include the web? What are the performance requirements? Is there a strong demand for the absolute consistency and maintenance cost of multi-end experience? Whether the community is active enough to exchange more difficult problems and solutions is what we need to consider. Because once the model is selected, in the process of promoting the business, these problems will eventually be digested by themselves. Judging whether a technology can become the development trend of the mainstream technology of the large front-end in the future mainly depends on whether the technology can reduce the dependence on the underlying host environment, isolate the differences of each terminal system, and whether it can lead the performance of similar products in terms of principle, operation mechanism and ecology, so as to provide developers with unified and standardized ability.