I was honored to participate in the whole process of IMWeb Conf 2018 Native cross-terminal fusion topic. In recent years, due to the rapid development of mobile Web, its simplicity and flexibility makes more and more cross-terminal fusion solutions keep emerging, especially the emergence of various terminal platforms such as small programs, which further increases the appeal of cross-terminal fusion. Cross-end convergence is definitely a topic worth discussing at the moment. This paper summarizes the main content of the meeting and gives some thoughts of its own, hoping to throw a brick into the discussion.

Cross the fusion

“Write once, Run anywhere, WORA” (” Write once, run anywhere, WORA “) was originally Sun’s slogan in cross-platform, which also represents our ultimate pursuit of efficiency as developers. In recent years, with the rapid development of mobile Internet, software and hardware of mobile terminal equipment, operating system, development tool chain and technical community are becoming increasingly mature and perfect, and various cross-platform development schemes have emerged in the front end.

The meeting topic

Principles and evolution direction of the Weex kernel

The first share is by Alibaba technical experts Zhang Han, Shen Yuan brought about Weex share, in the share, Zhang Han introduced Weex basic situation, internal structure, analysis and comparison, Shen Yuan talked about Weex in 2018 and related features.

Weex has been widely used in ali-based applications and communities. It applies to production environments in routine business, Double 11 / promotion, and high-performance scenarios. At the same time, a series of supporting facilities, such as EMACS, WeeX-UI, Da Vinci, etc.

Weex is divided into four parts: Vue, JS Framework, Weex Core and Render Engine. JS Framework connects to Weex DOM API, and communicates with Weex Core through Bridge API. Weex Core makes low-level calls to Native.

As we know, in the mobile terminal, the more close to the native development of the performance is better, the more close to the Web development cost is lower, WEEX is relatively close to the Web development experience, so the development curve is very similar to the Web, to the later close to the native development experience, the middle will experience an inflection point, Zhang Han believes that the inflection point lies in the effective combination of front-end and client, which requires the client to empower the front-end. When the front-end needs the client, the client can provide corresponding infrastructure and transition to the performance experience of native development.

Then Shen Yuan talked about the architecture upgrade of WeexCore and the situation of rendering architecture 2.0, which mainly optimized the Layout performance, upgraded the Timer and specially optimized the first screen rendering. We can see the obvious effect of the optimization in speed performance and memory consumption.

Finally shenyuan also mentioned, Weex Render is based on SKIA, put aside the limitations of the client native view, can be exchanged for performance improvement, the most important is, can achieve complex CSS effect, based on this, Weex also extended more than 140 CSS style ability.

Hippy framework design and optimization

In the second session, Zhao Honggang and Sheng Bo, senior engineers of Tencent, shared about Hippy, introducing the birth of Hippy from the perspective of front-end and terminal, improvement and optimization strategy compared with RN, application scenarios and future planning, etc.

As a cross-end framework of Tencent, Hippy integrates the advantages of front-end and terminal implementation, and has the advantages of good experience and high development efficiency. Hippy was originally intended to solve a number of problems that RN posed.

The overall architecture design of Hippy is divided into five parts: component layer, Render parsing, front-end core, C++ and terminal layer. The component layer encapsulates many practical upper-layer components. The Render parsing layer supports the core parsing and rendering logic of React and Vue. The Bridge communicates with the terminal, which is parsed and rendered via custom V8 and JS Core. In addition, Hippy provides a perfect release management system, which directly connects to terminal SDK packages and has incremental release functions, effectively solving the problem of too large RN packages.

Hippy supports React and Vue syntax in the upper layer, parses JSX or Vue Template in the Render layer, corresponds to DOM API of Hippy in a unified manner, and then communicates with the bottom layer through Bridge. This is also very similar to the DOM API design of the browser itself.

Compared with RN, Hippy is optimized in many aspects. In terms of gesture, Hippy improves the behavior of the terminal to continuously send gesture events to the front end, and solves the problem that the front terminal channel is occupied a lot. For communications, Hippy removes the cache of RN LastFlush; In terms of animation, Hippy uses AnimateConfig to make animation in one step and performance is significantly improved.

For ListView, Hippy also does UI reuse to prevent memory loss caused by excessive List data. At the same time, Hippy has also made a lot of optimizations for startup speed, API design at both ends, and stability.

Hippy not only provides a library, but also a suite of solution services, including package management system, dynamic operations, gray isolation, ABTest, differential publishing, forced updates, security verification, flow control, and more, to help manage publishing better.

Hippy has been widely used by Tencent in many internal businesses. It has been switched to Hippy on the first screen of QQ browser, which has withstood the test in the business with various UI and tens of millions of DAU.

Finally, Hippy also gives some suggestions for optimization in actual business, such as clipping package size, scanning image size, third-party library detection, lazy loading, AsyncStorage, critical path optimization, and so on.

Multi-development unified framework Taro in-depth analysis

The third session will be shared by Li Weitao, senior engineer of JINGdong, introducing Taro’s historical background, design ideas, continuous optimization, open source exploration and future planning.

Taro, as a multi-terminal unified framework, is designed to solve various pain points in the development of small programs, and quickly develop small programs that can be adapted to h5, RN and other terminals according to a set of codes.

Due to the problems encountered in the development of small programs, such as complex code organization, inconsistent specifications, weak string templates, chaotic dependency management, inability to use ES Next, and backward development methods, Taro decided to implement the code written by the React modern technology stack. And through the compilation of the way to generate to different platforms, so that “one place to write, multi-terminal operation”.

Taro’s general idea is to make use of Babel’s compilation ability to optimize the code and convert it according to different platforms after the analysis process of morphology and grammar, and finally obtain the target code.

During the compilation process, many problems will be encountered. Components and apis of different platforms vary greatly. Therefore, Taro applies bootstrap to each platform through a unified component and API layer.

Taro continues to provide rich and perfect support for JSX, reconstructs the componentization scheme of small programs, uses a more intuitive and user-friendly componentization form to organize code, and optimizes the setState performance of small programs according to the asynchronous mode of React. There is further support for TypeScript and React Native conversions, as well as baidu/Alipay applets.

Taro was officially open source on June 7 this year. Since open source, it has received a lot of praise, with a high resolution rate of issues and a good number of PR. It supports some well-known frameworks of React community and small program community, and has a nice UI.

In future plans, Taro will soon support Baidu/Alipay mini programs and fast applications, provide easier testing and debugging methods, support for generating code from native apps, and support for visual interface generation, all of which are worth waiting for.

summary

Cross-end development has been explored on the front end for a long time, and since the Days of PhoneGap, we have wanted mobile applications to have the performance experience of native development with the flexibility and agility of Web development. RN, Weex, and Hippy are constantly balancing development and performance. Flutter chooses to sacrifice some of the development experience in pursuit of higher performance. Taro/mpVue and other programs make their own explorations in the multi-terminal aspect of small programs. Each framework has its own starting point, but in essence, the pursuit of multi-terminal can be more unified, enhance the maintainability of code, enhance the development experience, and enhance the performance experience.

It was nice to see the Weex team talking to the W3C at the conference, hoping to make some standards in many aspects, with less choice and more uniformity in actual development. At the same time, I also hope that the small program team can be more open to community opinions, to provide better development experience, native support for the mainstream framework, rather than relying on other means to save the country, solve the problem of cross-end development experience, so that the front end can focus more on thinking about itself.

(zhihu related issues: www.zhihu.com/question/29.)