I heard that the client will disappear within three years.

[[400044]]

This article is reprinted from the WeChat public account "Amateur Coder", author Amazing10. Please contact the Amateur Coder public account to reprint this article.

Hello everyone, I’m An Jiang. Sometimes you need to step out of your comfort zone and learn about technologies in other fields. I always hear about “three eliminations of clients”, so why not today just talk about cross-client technologies that may determine the future of clients?

Alibaba's leaders once summarized, "Generally speaking, there are four types of cross-end technology scenarios, namely cross-device platform (cross-web and mobile), cross-operating system (such as cross-Android and iOS), cross-App, and cross-rendering container."

Among them, cross-platform technology on mobile terminals has always been a hot topic. In the context of no one being optimistic about the ceiling of client technology, the future of the client seems to be gradually leaning towards a cross-platform direction.

The advantages of cross-platform solutions are very obvious. For developers, they can develop once and reuse on multiple terminals, and a set of code can run on different devices. This can greatly reduce R&D costs and achieve rapid verification and rapid launch of product performance.

However, cross-platform technology for mobile terminals is not just about considering a set of codes that can run in different scenarios, but also needs to solve problems of performance, dynamics, R&D efficiency and consistency.

Performance: How to achieve better rendering and interactive performance through the combination of front-end and client;

Dynamicity: How can the client achieve a lower-cost version release, or even dynamically update the code without releasing a version? R&D efficiency: How to improve the R&D efficiency of dynamic debugging of different clients;

Consistency: How to implement multi-terminal deployment of a code and ensure the consistency and compatibility of the code displayed in multiple clients.

Nowadays, there are many cross-platform mobile frameworks such as WebView, React Native, Weex, Flutter, and Mini Programs. However, the industry is full of competition, and no framework can really solve the above problems perfectly, and at the same time, it can take advantage of the strengths of many.

1 WebView

WebView is simply a container for displaying HTML. In official terms, it is called:

A View that displays web pages. This class is the basis upon which you can roll your own web browser or simply display some online content within your Activity. It uses the WebKit rendering engine to display web pages and includes methods to navigate forward and backward through a history, zoom in and out, perform text searches and more.

Let me translate it for you:

A view that displays web pages. This is the basis for running your own web browser or just displaying some online content in your app. It uses the WebKit rendering engine to display web pages, and includes methods such as navigating through the browsing history, zooming in and out, and performing text searches.

So in simple terms, WebView is like a browser that can load and render various HTML pages. At the same time, WebView generally inherits the UI base class of the native client. Therefore, for native applications, WebView itself generates the client's native UI class by loading the h5 page, parsing it through the Chromium/WebKit kernel, and performing UI synthesis, and then displays it on the screen.

The communication and interaction between HTML page and native is realized through the so-called JSB (JavaScript Bridge). The client encapsulates the native system-level interface and then exposes it to the front-end page in WebView through JSB for calling.

This is essentially the communication between the native system API and the front-end page Javascript. In this way, front-end developers can quickly implement cross-end pages, communicate with the native system through JSB, and ensure that cross-end applications can be connected and call each other as a whole.

However, the disadvantage of this mechanism is also obvious, that is, the communication between the front-end page and the native system depends entirely on the structure of JSB. If JSB lacks an interface for calling native capabilities, the cross-segment capabilities will be directly limited. In this case, it is still necessary to expand the JSB interface in the native application separately, which reduces development efficiency.

In addition, WebView's rendering of the UI depends on the browser kernel, which is independent of the system components, so the native experience of the cross-end UI cannot be guaranteed. The native experience is always the ultimate goal of cross-end technology.

2 React Native

In order to pursue the native experience mentioned above, Facebook launched the very popular React Native, abbreviated as RN, in 2015.

[[400045]]

The biggest difference between RN and WebView is that it no longer uses the browser kernel for UI rendering, but uses something called Virtual DOM to manage cross-end UI rendering.

Virtual DOM is actually similar to DOM, both are tree structures that record different elements of the UI on different nodes. However, Virtual DOM leaves the rendering work to the native rendering engine, such as web browsers, iOS, and Android. After that, different platforms still create different Native views through the corresponding Bridge.

In this way, the experience is improved to a certain extent. However, the interaction between React Native and native depends on only one Bridge, and the interaction between JS and Native is asynchronous, so there may be performance deficiencies for functions that require a lot of real-time interaction with Native, such as animation efficiency, and the performance is still not as good as native.

3. Flutter

Flutter is a mobile cross-platform UI framework incubated internally by Google. It was proposed when RN was being questioned. It is currently the framework that is closest to the native experience.

From the underlying principle, it neither uses the mixed form of WebView and H5, nor the mode of bridging through JavaScript, but implements a set of UI frameworks by itself, and directly renders the UI at a lower level. Not only that, it no longer uses JavaScript as a development language, but chooses Dart. It is said that the Dart language can be compiled into native code and communicate directly with native code.

The reason for choosing Dart is that the Flutter team evaluated more than a dozen languages ​​in the early stage and chose Dart because they felt it fit the way they built user interfaces and also had the following advantages:

1 Dart is AOT (Ahead Of Time) compiled into fast, predictable native code, allowing Flutter to be written almost entirely in Dart.

2 Dart can also be compiled in JIT (Just In Time), with an extremely fast development cycle and a disruptive workflow (including Flutter's popular sub-second stateful hot reload);

3 Dart makes it easier to create smooth animations and transitions that run at 60fps. Dart can allocate and garbage collect objects without locks.

4 Dart makes Flutter not require a separate declarative layout language such as JSX or XML, or a separate visual interface builder, because Dart's declarative programming layout is easy to read and visualize.

Flutter is essentially different from the above-mentioned Recat Native and WebView containers. It does not use WebView, JavaScript interpreter or native controls of the system platform. Instead, it has its own set of exclusive widgets, and all components are self-drawn based on the Skia engine.

Since Flutter uses its own engine to render the UI, the effects on iOS and Android are basically the same. In contrast, RN converts UI controls into native controls of the corresponding platform, so there will inevitably be some differences.

From a technical perspective, RN actually provides a JavaScript runtime environment in a Native container, but its layout engine and rendering layer all use Native controls, so there are still system differences in UI interaction. The Flutter solution is more thorough, and even the rendering layer is replaced with self-drawn UI controls based on the graphics engine, thus ensuring cross-end consistency of UI interaction.

4 Conclusion

These three cross-end technologies are basically the most popular technologies in the industry and can be seen in many large apps. Especially in apps, pages related to activities are basically implemented through cross-end technologies, after all, activities themselves mean a high degree of dynamism.

I feel that the value of cross-end technology in practice is mainly that it can shorten the release cycle of the app, eliminating the need to go through the very long process of closing, releasing, grayscale and full release. Once a problem is encountered or the app needs to be modified immediately, it can be directly implemented through cross-end technology. It is very useful.

However, judging from the above, many cross-platform problems have not been truly solved. However, if they were truly solved, the keyboard warriors in Maimai who are "three-elimination" would probably be excited again.

But as long as you keep learning, you won't be afraid of anything. Hey, if you think this article is good, please like and share it~ I'm An-chan, see you next time.