Flutter Technical Principles
Flutter is a mainstream cross-platform application development framework that develops UI interfaces based on the Dart language, compiles the Dart code describing the interface directly into machine code, and uses the rendering engine to invoke GPU/CPU rendering.
Advantages of the rendering engine
Using its own rendering engine is the biggest difference between Flutter and other cross-platform frameworks.
Unlike frameworks such as React Native, which rely heavily on native components, Flutter gets rid of native component dependencies, has a more flexible interface layout, and has a highly consistent multi-terminal display effect. Since the rendering engine is built-in, there is more room for performance optimization, which is why Flutter is known for its smoothness.
Origin of the Impeller rendering engine
Flutter's rendering engine has gone through several iterations, with Skia being used on all sides in the early days, and later the Flutter team developed a new generation of rendering engine, Impeller, to solve the problem of shader compilation lag on iOS. Due to its outstanding performance, Impeller has become the future direction of Flutter.
The rendering engine compiles the shader into GPU instructions, which are binary code.
shader is a graphics drawing program that defines how to draw a shape, such as colors, shapes, transformations, etc.
Flutter has made many efforts and attempts to solve the lag problem based on Skia, but it has never been satisfactory, and finally Impeller was born.
Impeller's design goals include: eliminating first-time stuttering, reducing frame rendering drive overhead, and leveraging the parallel rendering capabilities of modern GPUs
Impeller vs Vulkan
Vulkan is the next generation of graphics APIs launched by OpenGL, and on Android, Flutter Impeller calls Vulkan for UI rendering.
- Impeller implements commonly used shaders, supports parameterization, and avoids compilation lag by precompiling shaders
- The layered architecture simplifies the rendering process, with each layer performing a specific function based on the capabilities of the lower layer, which is efficient and easy to maintain and update
- Draw commands are easy to aggregate, easy to split and parallel
- Decoupling the rendering design from the graphics API
Impeller Harmony
Impeller's HarmonyOS is based on Vulkan, which hosts Flutter views through the XComponent component provided by ArkUI.
As with other platforms, through Method Channel, Dart calls ArkTS for native capability calls.
How XComponent hosts Flutter views
Through XComponet, the OHNativeWindow instance at the bottom of the system is obtained, which is the native window of HarmonyOS, and through the extension VK_OHOS_surface provided by HarmonyOS, this window is converted into a VKSurface in Vulkan, and then the window is drawn through VKSwapchain.
External Textures: How system-generated graphic images are embedded in Flutter displays
With XComponent, the interface drawn by Flutter can be displayed in HarmonyOS. So if it is a non-Flutter drawn interface, such as a system camera, video, etc., how to embed it into the Flutter interface? This brings us to external textures.
Taking the camera as an example, if you use the camera in Flutter, of course, the most basic thing is to communicate through the Method Channel and pass the data over, but this process is obviously very time-consuming and the performance is worrying. Another option is to overlay the system page and the Flutter screen by digging holes, but this may lead to inconsistencies in the operation and animation of the two sets of interfaces. HarmonyOS uses a more difficult data import scheme, that is, importing external data into Flutter and drawing this data in the form of texture components.
HarmonyOS external textures involve encoding data transmission, how to solve performance problems
NativeBuffer is provided by HarmonyOS and allows memory sharing to be implemented. Externally imported data can be directly used by the GPU through NativeBuffer, avoiding the performance loss caused by data copying.
Whether it's VKImage, or GLTexture, you can use NativeBuffer.
How to fix the blurred screen problem
Different from Android, the Impeller Harmony solution uses a GPU hardware-level synchronization mechanism to protect data reading, prevent data competition, avoid blurred images, and reduce idling time and improve performance through CPU decoupling.
The Flutter engine does not need to wait for the buffer to complete the read and write before calling the drawing capability, as long as the semaphore status of the buffer data is read when the GPU draws the queue, which reduces the performance loss caused by CPU idle time.
Render Pipeline preloading
Impeller avoids runtime compilation in Skia by precompiling shaders, but requires them to be loaded at startup (i.e., loading the render pipeline), which results in noticeable white screen time. To solve this problem, you need to preload the render pipeline.
When HarmonyOS Flutter is running, it first creates a Dart virtual machine to parse the UI, and in the process, the render pipeline is loaded synchronously, so as to achieve fast loading of the first frame on the screen and reduce the latency by 50ms.
This part does not require developer action, the SDK will do it automatically.
Hybrid Development Loading Optimization: Page preloading
Jumping from the native ArkUI page to the Fluter page requires initializing the Flutter engine (a long process) before rendering the first frame of the page, which can cause significant lag.
Developers can manually call the Flutter engine initialization API in advance to solve this lag problem. For example, when the user touches, the Flutter engine is initialized synchronously, and when the user raises their hand, they can immediately jump to the Flutter page, and the whole process will be more streamlined.
Performance Testing
With preloading, you can save half the jump time. Compared to the Skia solution, Impeller's transition smoothness is significantly improved.
Compared to the Skia solution, the Impeller scheme performs better in terms of performance.
The future of HarmonyOS Flutter
Led by Huawei, the HarmonyOS Flutter adaptation group, plans to launch 1-2 relatively large versions every year, and these two major versions are realized by forking the official main version at that time. As for whether the part of HarmonyOS adaptation can be merged into the official Flutter official, it depends on Google's attitude.
Combined with the launch of Flock, the community version of Flutter some time ago, the author is optimistic. While Google has been slow to make progress on the Flutter update, the community version brings a lot of imagination. The coexistence of multiple SDK versions does not mean that there is more competition. In addition to OracleJDK, there are more than a dozen community versions such as OpenJDK and AdoptOpenJDK.
In addition to the existing plug-in development methods, HarmonyOS Flutter plans to launch a lower-cost solution, that is, through a unified interface description, automatically generate the call code of each end, saving developers the coding work.
Summary
As a popular cross-platform framework, Flutter is the general trend to support HarmonyOS. Huawei's entry into the game has given a strong boost to the Flutter community.
Judging from the feedback from all parties so far, Flutter should be the best adaptation solution after ArkTs.
Whether it is the official, the open source community, or the majority of developers, they all have a strong demand for Flutter.
HarmonyOS hopes that more apps will be adapted to HarmonyOS as soon as possible, and developers or manufacturers also hope to launch them as soon as possible at a lower cost. ArkTS still has a lot to improve, and in contrast to Hot Reload, Flutter is already far ahead in terms of ease of use, stability, and maturity.For platform-specific features, such as various picker components in HarmonyOS and permission-free buttons, this is the same as on other platforms, which is a unique advantage of native languages.
Although Flutter Harmony has achieved initial results, and many third-party Flutter applications have also been quickly adapted to the shelves, it still takes a lot of time for ecological construction, and the third-party libraries still need to be built and shared.
The future of HarmonyOS is promising, and the HarmonyOS of Flutter has brought fresh blood to this framework that has been silent for a long time.
Top comments (0)