A brief introduction to cross-platform mobile solutions
What are the cross-platform solutions
The emergence of cross-platform technology development is for the same goal: to increase the reuse rate of business code, reduce the amount of work caused by adapting to multiple platforms, and thus reduce the development cost. In recent years, there have been many cross-platform development schemes, which can be roughly divided into web cross-platform scheme, pan-Web cross-platform scheme and self-drawing engine scheme.
Web Cross-platform solution
Interfaces and functions are implemented through browser components based on Web-related technologies. Typical frameworks include Cordova(PhoneGap), Ionic, and wechat applets. This was probably the first cross-platform solution, and the most successful cross-platform solution, and is still used today.
Adopt native application embedded browser control WebView (iOS for UIWebView or WKWebView, Android for WebView) for HTML5 page rendering, and define HTML5 and native code interaction protocol, Extend the boundaries of HTML5 by exposing some of its native system capabilities to HTML5. This type of interaction protocol is commonly referred to as JS Bridge. This is both HTML5 and native code, also known as a Hybrid development model.
Web cross-platform solutions, can be largely ensures the unity of the UI page, but on the rendering more complex page, from the naked eye can feel some caton, this is because the HTML page display to undergo browser controls loading, parse and render the three process, performance cost increased N order of magnitude than the native development.
Pan-web cross-platform solution
It adopts web-like standards for development, and the drawing and rendering are processed by Native systems at runtime, such as React Native, Weex and Fast Application frameworks, as well as Virtual View of Tmall in a broad sense.
On the basis of the Web scheme, the optimization of loading, parsing and rendering these three processes is the pan-Web cross-platform scheme. The Web standards that affect their independent operation are cut down to support the necessary Web standards (such as Flexbox, etc.) for building mobile pages in a relatively simple way, and also ensure a convenient front-end development experience; At the same time, this solution basically completely abandoned browser control rendering, instead of using native UI component implementation of the core rendering engine, only maintain the necessary basic control rendering capabilities, thus making the rendering process more simplified, but also ensure good rendering performance.
Front-end or use JavaScript development, the loading, rendering mechanism is greatly simplified, and then handed over to the native processing, the use of native control display. React Native and Weex are examples of this.
Self drawing engine scheme
With its own rendering engine, the client only provides a canvas to get a highly consistent multi-end rendering experience from business logic to functional presentation. Flutter is one of them.
In the pan-Web cross-platform scheme, the loading and rendering are optimized, and the performance is greatly improved. However, as the system version changes and apis change, we also have to deal with the differences in the rendering capabilities of native controls on different platforms and fix all kinds of weird bugs. Then the self-drawing engine solution was born.
Flutter has written a cross-platform UI framework from start to finish, including a logical rendering and development language. Skia complete rendering is implemented using the cross-platform Skia graphics library, using Dart that supports both JIT (Just-in-time) and AHEAD-of-time (pre-compiled)
The mechanism and principle of flutter
Operation mechanism
In computer system, the display of image needs the cooperation of CPU, GPU and display: CPU is responsible for image data calculation, GPU is responsible for image data rendering, and the display is responsible for the final image display.
The CPU gives the calculated content to be displayed to the GPU, and the GPU completes the rendering and puts it into the frame buffer. Then the video controller reads the frame data from the frame buffer and submits it to the display to complete the image display at the speed of 60 times per second according to the VSync signal.
This scheme is also used by the Flutter control rendering mechanism.
Flutter focuses on computing and synthesizing view data between VSync signals from two hardware clocks and then delivering it to the GPU for rendering via Skia: Dart is used by the UI thread to construct view structure data, which is then layered in the GPU thread and then delivered to the Skia engine for processing into GPU data, which is ultimately provided to the GPU rendering through OpenGL.
The principle of
The Framework layer is a UI SDK that uses Dart and includes animation, graphics, and gesture recognition. To provide a more intuitive and convenient interface for drawing fixed graphics such as controls, Flutter also builds on these basic capabilities by encapsulating a library of UI components based on the Material and Cupertino visual design styles. This is the control we should develop to use all can be found in this.
The Engine layer contains Skia, Dart and Text, which implements the rendering Engine, Text typesetting, event processing and Dart runtime of Flutter. Skia and Text provide the ability to call the underlying rendering and typesetting for the upper interface, while Dart provides the ability to call Dart and the rendering engine at runtime for Flutter. The Engine layer combines them to render views from the data they generate.
Embedder is an operating system Embedder layer that provides the ability to embed platform-specific features such as render Surface Settings, thread Settings, and platform plug-ins. From this we can see that the flutter platform does not have many characteristics, which makes the cost of maintaining cross-end consistency from the framework level relatively low.