cross-platform

About the BeesAndroid project

BeesAndroid project provides a series of tools, theoretical analysis and methodology, aimed at reducing the threshold of Android source code, so that readers better understand the design and implementation of Android system. For the first time in this series, see the introduction and the table of contents for more articles.

I have been in touch with cross-platform containers for nearly a year. Standing on the shoulders of predecessors and combining my own understanding, I would like to talk about my views on the ecology of cross-platform containers and point out some inappropriate points.

Background and History

The core problem that cross-platform technology solves

• Efficiency: solve the problem of developing efficiency in multi-application, multi-platform and multi-container.
• Performance: Addresses the performance and experience of the business.

Evaluation metrics for cross-platform technologies

• Technology stack
• R&d efficiency
• dynamic
• Multiterminal consistency
• Performance experience
• Maintenance costs
• Community ecology

Cross-platform rendering solutions

• WebView rendering: Rely on WebView rendering to compromise functionality and performance, such as PhoneGap, Cordova, small programs (some of which also use ReactNative rendering solutions), etc.
• Native rendering: The top layer embraces W3C and translates the front-end framework into native controls through the middle layer, such as ReactNative+React, Weex+Vue combination. This solution adds another translation layer, resulting in performance loss. As native systems upgrade, there will be compatibility issues.
• Build your own rendering: Build your own rendering framework using Skia and other graphics libraries such as Flutter and Unity.

The development history of cross-platform technology It a bit, the React of Native and Weex an additional layer of the practice, now has encountered bottleneck in performance, and after the system upgrade, frame maintenance cost is higher, if the future without big refactoring, at present is in a state of decline, other schemes in the condition of coexistence.

Cross-platform framework	Hybrid App	React Native	Weex	Fast application	Small program	Flutter
time	2011	2015	2016	2017	2017	2018
Developer divide	multiple	Facebook	Alibaba	Handset makers	multiple	Google
Support platform	Android iOS Web	Android iOS	Android iOS Web	Android	Android iOS	Android iOS Web
Render container	Android: the WebView IOS: WKWebView	The original container	The original container	The original container	Many containers	The original container
Development of language	JavaScript	JavaScript (React)	JavaScript (Vue)	JavaScript (native)	JavaScript (Applet syntax)	Dart
R&d efficiency	high	general	general	general	high	general
Technology stack	The front end	Partial front end	Partial front end	Partial front end	Partial front end	Partial client
dynamic	support	support	support	support	support	support
Multiterminal consistency	high	general	general	No iOS	high	high
Performance experience	poor	general	general	general	general	good
Maintenance costs	low	high	high	high	low	low
Community ecology	active	inactive	inactive	inactive	active	active

Note: The above mention of rendering performance is just to say that in general terms, it is not desirable to talk about performance without tuning, so it should be treated separately.

Let’s summarize the evolution of cross-platform container technology implementation

• Hybrid App: JavaScript development +WebView rendering
• React Native/Weex/ Quick application: JavaScript development + Native rendering
• Small program: JavaScript development + multiple containers (multiple rendering methods)
• Flutter: Dart development + native rendering

Container ecological

• Front-end framework ecology
• Container unity layer
• The container layer

Front-end framework ecology

A front-end framework ecosystem is directly business-oriented and should have two characteristics:

• Embracing the W3C ecosystem
• Relative stability

It should embrace the W3C ecosystem. The W3C ecosystem is a thriving and vibrant one that will continue to grow for many years to come. Trying to ditch the W3C ecosystem and build your own subset is not going to go very far. This can be seen from the launch of wechat mini apps and Flutter for Web series. ** It should be relatively stable. ** It cannot be said that every time we change a set of containers, the front-end business needs to be rewritten. For example, we made H5 container before, and then made small program container. Because DSL is not available, the front-end has to spend a lot of effort to rewrite the business. Although the small program is a code, but I think it does not solve the efficiency problem, there are two main problems:

• The increased cost of learning the front-end, the relatively simple DSL for small applications, and the Widget architecture of Flutter that takes a little time to learn are all costs to the team.
• Business code was rewritten, a lot of logic needed to be sorted out, and old businesses were not always suitable to migrate to new containers. For example, applets were a lightweight solution, but we piled a lot of functionality on top of them, causing serious experience problems.

Under these circumstances, it is difficult for the business to run fast. So no matter what happens to the underlying container, the front-end framework must be relatively stable. This stability depends on the container uniform layer.

Container unity layer

The container Unification layer is a layer between the front-end framework and the container layer. It defines the basic capabilities provided by containers that, like protocols, are relatively stable. The protocol is very important, just like the OpenGL protocol, with The OpenGL protocol, no matter how the underlying rendering scheme is implemented, the upper layer of the call does not change. For our business as well, we need to precipitate common solutions around the container unification layer.

• Unified API solution
• Unified performance solution
• Unified component solutions
• Unified supporting facilities solutions
• , etc.

These things don’t mean we have to reinvent the wheel every time we build a container. There’s something wrong with that. What has already been done, when it comes to new technology, it can only show that the previous definition of the scheme is not comprehensive, without considering the precipitation of unity and expansion. If we do the same thing over and over again, the business will wait for us.

The container layer

The iterative core of the container layer is to maximize performance and experience while solving efficiency problems. The early ReactNative mode solved the efficiency problem, but it had a communication layer (ReactNative relies on transmitting the information of virtual DOM to native, and then native constructs the corresponding native control tree according to the layout information to achieve native rendering), which has performance problems. Moreover, this translation mode needs to adapt to the system version. Brings more compatibility issues.

WeChat follow-up and introduced a small application solutions, in my opinion, small program scheme is not like a technical solution, it’s more like a business solution, solves the platform big flow specification management and distribution, general technical solutions for business, small procedures at the bottom of the rendering process, of course, also is many and varied.

One sore point that upstart Flutter addresses is performance. It has a built-in GUI system that renders directly from the Skia graphics library (just like Android does), enabling native rendering. However, Dart was chosen based on efficiency, performance, and its own ecosystem, which is a direct abandonment of the flourishing front-end ecosystem. Given the history of cross-platform containers, maximizing the W3C ecosystem while addressing efficiency and performance is probably the best direction for the future. Flutter has also launched Flutter for Web. The idea behind Flutter is to get through Android and iOS first and then gradually penetrate the Web. We are looking forward to its performance. Container technology is moving forward dynamically. We’re doing Flutter this year, and maybe other solutions next year. We need to make sure that the transition is fast and smooth, rather than doing it all over again. With the improvement of mobile phone performance, The performance of WebView is getting better and better, and Flutter provides a new idea to solve the performance problem. A cross-platform container ecosystem with complete infrastructure, experience first and multiple terminals is worth looking forward to.