preface

Recently, I read the column “Android Development Master Class” opened by Teacher Zhang Shaowen (senior engineer of wechat, head of Tinker) on Geek Time. In this column, I introduced some status quo of Android development, and of course, how wechat has evolved step by step over the years, which impressed me deeply. Therefore, I started to learn the series of Android cross-platform dynamics, and wanted to record it in the form of a blog during the learning process. In this first article in the series, I intend to introduce the current state of cross-platform dynamics and my vision for the series.

First of all, cross-platform and dynamic are two different dimensions, and the two dimensions overlap and do not overlap. I will solve the two dimensions here.

A cross-platform

In recent years, the concept of “big Front End” has become very popular. The iconic event is that since 2017, GMTC mobile Technology Conference has changed its name to “Big Front End Technology Conference”. At present, front-end development and Native development are not replacing each other, but are converging, and the result is the so-called “big front end”. In the dimension of cross-platform, I have divided the current technology path into four categories: mobile Web technology, virtual runtime environment, applets and the current hot Flutter.

1.1 web

Since the desktop era, Web technology with browser as the carrier has the advantages of cross-platform, dynamic update and strong scalability. As the performance of mobile devices has increased, the performance of Web pages has become acceptable. There are more and more embedded Web pages in clients, and many applications are changing some of their functional modules to Web implementations.

A Web page is composed of HTML + CSS + JavaScript, executed through the browser kernel and rendered to the desired interface of the developer. The core of a browser consists of two main parts: the browser engine, which processes HTML and CSS according to the W3C standard, and the JavaScript engine, which processes JS according to the ECMAScript standard.

With Microsoft Edge announcing the switch to Chromium, apple and Google are the only two players in the battle. Their browser engines are Webkit and Blink (Blink is also a fork from Webkit). JS engines are JavaScriptCore and V8 respectively. For the browser rendering process, this is roughly as follows. HTML, CSS, JS, and other resources (images, videos, fonts, etc.) are all downloaded from the Web. HTML will be parsed into DOM, CSS will be parsed into CSSOM, JS will be executed by THE JS engine, and finally, DOM and CSSOM will be integrated into a Render Tree.

Cross-platform solutions such as the Web are the most common cross-platform solutions, but I won’t cover that much here until I focus on this later.

1.2 Virtual Operating Environment

This cross-platform solution is represented by Alibaba’s Weex and Facebook’s React Native. Of course, Flutter also falls into this category. The H5 cross-platform scheme based on WebView still fails to meet the requirements for some interactive and animation complex scenes (such as left-right sliding screen and gestures), even though the performance is almost crazy after optimization.

Facebook opened source React Native in 2015, which eliminates WebView and uses JavaScriptCore as a bridge to convert JavaScript calls into Native calls. In other words, React Native eventually generates the corresponding custom Native controls, following the system’s Native rendering process. While React Native and Weex dock up with front-end ecology and down with Native rendering, it looks like a perfect solution. But the differences between the front end and the client, Android and iOS in the client, are not so easy to smooth out, and forced integration will encounter all kinds of pits.

Weex has been abandoned by Alibaba, but Facebook is still optimizing this solution. Of course, In China, Meituan has modified React Native to form its own framework MRN. This solution will be introduced here. The following special article will be analyzed again.

1.3 a small program

At the beginning of 2017, Zhang Xiaolong announced the birth of wechat mini program. Now it has been two years, and in these two years, the ecosystem of small program is also developing healthily. On this basis, each big factory has launched its own small program framework, such as wechat, manufacturers, Alipay, Toutiao, Baidu, Taobao, Google Play.

Applets do not belong to a cross-platform development solution. Technically, the framework technology of applets is open, including H5 solution, React Native, Weex, and even Flutter. The following is a diagram to show the differences between these small programs, as shown in the figure:

Here in addition to the unique fast application, other small program technical solutions basically follow wechat. However, considering the performance of H5 in some scenarios, some native controls are supported on WebView by using the same layer rendering capability provided by the browser kernel. If one day wechat applet supports all Native controls, it will be another React Native/Weex solution. The reason why Alipay and Baidu small program have the same technical solution with wechat is that they also hope that the existing micro program can quickly migrate to their own platform.

1.4 Flutter

Eric Seidel, one of the early developers of Flutter, participated in an interview with What is Flutter in which he talked about why Flutter was developed in the first place, as well as some of the principles and directions of Flutter design. Eric Seidel and the early developers of Flutter came from the Chrome team and had extensive experience in typography and rendering. So why develop Flutter? They had been frustrated with the performance of their browsers for a long time, and one day they decided to jump out of the Web and do a lot of code removal on the Chromium base, throwing away Web compatibility, and found that performance was 20 times better. So their design principles are, respectively, performance first and efficiency first.

  • Performance is Paramount: built-in layout and rendering engine, rasterization via GPU using Skia. Dart language was chosen as the development language and AOT compilation was used when the official release was made, eliminating the need for parser interpretation execution or JIT. Tree Shaking useless code removal is also supported to reduce the size of distributed packages.
  • Efficiency first: support Hot Reload of the code in the development stage to achieve second-level compilation update. Attach importance to the development tool chain, from development, debugging, testing, performance analysis have perfect tools. The built-in Runtime is truly cross-platform, allowing a single set of code to generate Android/iOS apps at the same time, reducing development costs.

Flutter is a simplification of the browser engine. Both its layout engine (also using CSS Flexbox layout, for example) and its rendering pipeline design have a lot in common with browsers. However, it abandons the heavy historical burden of browsers and Web compatibility to achieve cross-platform development while maintaining performance. Flutter has great advantages in both cross-platform and performance, but it is not as dynamic as other solutions.

Two dynamic

2.1 Common dynamic scenarios

Mobile mobility has been on the radar in recent years, and while it’s been evolving for years, it’s changing every year. Here’s a look at what companies are known for.

As I watched QCON 2018, Meituan engineers shared their dynamic practices. Meituan, as a strong operating application, has a very strong appeal for dynamic, and also has rich practical experience. They divide dynamic solutions into the following four types.

  • Web container enhancement: Implemented based on H5, but also supported by various optimization methods such as offline package, represented by PWA, Tencent’s VasSonic, Taobao’s Zcache and most of the small program solutions.
  • Virtual runtime environment: Runs on an independent VM, but ultimately uses Native controls for rendering, such as React Native, Weex, and Fast Apps.
  • Business plug-in: Component-based development based on Native, which is very common in taobao, Alipay, Meituan, Didi, 360 and other carrier applications. Examples include Alibaba’s Atlas, 360’s RePlugin and Didi’s VirtualAPK. In addition, I think each hot repair framework should also belong to a type of business plug-in, such as Wechat’s Tinker, Meituan’s Robust and Ali’s AndFix.
  • Dynamic layout: Plugins or hotfixes can dynamically modify page layout and data, but the cost is huge, and it is not easy to achieve personalized operation. In order to achieve “thousands of faces”, the home page structure of Taobao and Meituan can be updated through dynamic configuration. Examples include Alibaba’s Tangram and Facebook’s Yoga.

2.2 Choice of dynamic scheme

Which of the four dynamic scenarios is stronger? Here’s a graph to see the difference between them, as follows:

At present, we cannot find a “perfect” dynamic solution, each solution has its own advantages and disadvantages and corresponding use scenarios. For example, The Web container enhancement solution has great advantages in terms of dynamic capability and development efficiency, but it is not satisfactory in terms of stability and fluency. On the contrary, the layout dynamic solution has a very good performance in terms of performance, but has a lot of limitations in terms of dynamic ability and development efficiency.

Web container enhancement and virtual Runtime environment schemes bridge Native modules through independent Runtime and JS-SDK, while business plug-in is directly invoked through plug-in framework and interface capabilities. The former is more abstract and less likely to cause code clutter, which is why companies are starting to “de-plug”.

2.3 Native dynamic scheme

Native dynamic schemes are mainly divided into two types: thermal repair, plug-in and layout dynamic.

2.3.1 Hot repair and plug-in

Wechat once hoped to use Tinker instead of version release to realize the proxy of four components on the basis of hot fix. However, the introduction of Android P proprietary API restrictions has largely put paid to that idea. Hotfixes are not A replacement for release, but they can be used to implement features not supported in the app store, such as accurate greyscale population control, channel and user attribute selection, and full package A/B testing.

There are a lot of compatibility problems in Android P applications in China, most of which are caused by hot fixes, plug-ins and reinforcement (according to the data provided by Google, 43% of compatibility problems are caused by these three problems). On this basis, the future of hot updates and plug-ins is pessimistic. But the release of Android Q came as a big surprise. Google has added the AppComponentFactory API to Android P and the Interface instantiateClassloader to replace ClassLoaders to Android Q. After Android Q, we will be able to replace the existing ClassLoader and four components at runtime. This way, you can use the official Google API to implement hot fixes, so that you don’t have to worry about updating later versions of Android.

Thermal repair and plug-in are Native dynamic solutions, which have certain limitations. With the development of mobile technology, some functions may be replaced by other dynamic solutions such as applets. But at present, they still have a very large value of existence and use scenarios.

2.3.2 Dynamic layout

For scenes like Taobao and Meituan home page, we have very high requirements on performance, so we can only use Native implementation here. But the home page is also the gathering place of traffic, “increase growth, retention, transformation” require us to have a strong operation ability. In the last two years, Taobao, Tmall has been carrying out the “thousands of thousands of faces”, each user to see the home page layout, content may not be quite the same. In this context, dynamic layout emerges. In my opinion, dynamic layout requires the following three abilities.

  • UI containerization: The ability to dynamically add and adjust UI interfaces without having to issue versions.
  • Capability interface: Common capabilities such as click and jump can be provided externally through routing protocols to meet the call requirements after UI containerization.
  • Data channelization: Data can be reported automatically by the client based on the configuration through field configuration.

In specific practice, you can choose Tangram, which is open source of Tmall, or do secondary development based on the underlying VirtualView.

In general, compared with virtual operating environment, dynamic layout not only realizes the dynamic addition and modification of UI, but also has good experience and performance, and the cost of access and learning is lower.

Summary and plan

This article covers a wide range of technologies, and in the iron triangle of performance, cross-platform, and dynamics, we can’t optimize all three at once.

As long as the development cost of H5’s cross-platform solution is not too high, it can develop applications with good performance and functions. But for extreme optimization, it’s easy to see how little the developer can control and how performance and functionality depend on browser support. To go further, we need not only to understand the internal mechanics of the browser, but perhaps to be able to customize and modify the browser kernel, which is why Alibaba, Tencent, Toutiao and Baidu have all formed kernel teams.

Native development, on the other hand, requires a high initial development cost, but once production starts, developers have more room to play. React Native and Weex solutions aim to create a comprehensive solution that combines cross-platform, development cost, and performance.

In later articles in this series, I will study and document each of these cross-platform dynamics solutions. My main goal is to understand how they work, and in the process I will analyze some of the open source libraries that represent these solutions, hoping to improve my capabilities. This is just a start. Look forward to sharing next time.

The resources

  • Android Development Master Class
  • Dynamic Practice of Meituan Client