An in-depth analysis of mobile cross-platform development

Cross-platform is a perennial topic, with cordova, Ionic, React-native, Weex, Kotlin-native, Flutter, and many other cross-platform frameworks popping up to push native developers over the edge. After reading this article, you will have a better understanding of the current state of cross-platform mobile development, the implementation principles, the choice of frameworks, and so on.

The whole content is more, need patience to eat! (/ / / del / / /)

One, foreword

Why do we need cross-platform development? In essence, cross-platform development is about increasing code reuse, reducing the amount of work developers have to do to adapt to different platforms, reducing development costs, improving business focus, and providing a better experience than the Web. Well ~ colloquial saying is: save money, lazy.

In this article, react-Native, WEEx and Flutter are used to discuss the implementation principle, current situation and future of cross-platform mobile development. 4, (ionic, phoneGap) is my face naive (4, ⁻̫ red).

Ultra complete cross-platform open source project

type	link
react-native	Github.com/CarGuo/GSYG…
weex	Github.com/CarGuo/GSYG…
Flutter	Github.com/CarGuo/GSYG…

Ii. Principle and characteristics

At present, the cross-platform development of mobile terminal can be summarized as follows:

React Native and WEEX both use JavaScript as the programming language. At present, JavaScript accounts for half of the cross-platform development, with a trend of “dominating the world”.
Kotlin-native is starting to support iOS and Web development (Kotlin has become a first-level language for Android) and is trying to “dominate the world.”
Dart is Google’s cross-platform mobile UI framework, and Dart, Google’s own son, is undoubtedly the programming language of The Flutter, as shown below. As a new giant, and as shown on the Website, Flutter is also “worldwide.”

1, the React of Native

Made by Facebook, JavaScript, JSCore engine, React design mode, native rendering

1.1. Conceptual framework

“Learn once, write anywhere” represents Facebook’s definition of React Native: Learn React and master the development skills of web and APP at the same time. React Native uses react design mode, but UI rendering, animation effects, network requests, and so on are all implemented on the native side. React Native’s middle tier converts javascript code to native controls and actions, providing a much better user experience than cross-platform applications such as Ionic.

To sum up, JS is actually used to call the components of Native side, so as to achieve the corresponding function.

As shown in the figure below, react native cross-platform implementation is mainly composed of three layers, among which the dynamic link library (.so) implemented by C++, as the intermediate mediation layer bridge, realizes the two-way communication and interaction between js end and native end. The main thing here is that JavaScriptCore is encapsulated to perform JS parsing. React Native runs in JavaScriptCore, so there is no browser compatibility issue.

The built-in javascriptcore is directly used on IOS, and the official open source Jsc.so of Webkit.org is used on Android.

1.2 Implementation principle

Unlike the front-end development, all tags in React Native are not real controls. The functions of controls written in JS code are similar to key values in Map. JS end will use the Dom of this key combination, and the Native end will finally parse this Dom to get the corresponding Native control rendering, such as the ViewGroup control corresponding to

tag in Android.

In React Native, the JS side runs in a separate Thread (called a JS Thread). As a single-threaded logic, JS Thread cannot handle time-consuming operations. In Android, operations such as FETCH, image load, data persistence and so on correspond to okHTTP, Fresco, SharedPreferences and so on. Cross-thread communication also means that the interaction and communication between Js Threads and native threads is asynchronous.

As you can see, the key to cross-platform is the C++ layer, and developers, for the most part, only focus on the JS side of the code implementation. The various Native Module modules provided on the Native side (such as network request, ViewGroup control) and the various JS modules provided on the JS side (such as JS EventEmiter Module) are stored in the C++ implementation of so. Communication between the two sides through C++ saved mapping, the final realization of the two sides of the interaction. The communication data and instructions will be transferred into String strings in the middle layer. The two-way calling process is as follows.

1.3. Package and load

Finally, the JS code is packaged into a bundle file that is automatically added to the App’s resource directory. The react Native package script directory is /node_modules/ React-native /local-cli, and the bundle file will be compressed through the Metro module. The bundle file only packages JS code, and naturally does not contain static resources such as images. Therefore, the static resources after packaging are actually copied to the corresponding platform resource folder.

PNG resource (img/ PIC/log.png) in the react Native project root directory will be renamed at compile time and merged into the drawable directory according to size. Change the name to img_pic_logo.png.

The package of Android and IOS definitely requires the existence of the corresponding platform project. The project created during React-Native Init already contains the template project of Android and IOS. The packaged project will load the bundle file and then start the project, as shown in the figure below. React Native For Android: A first look at the React Native architecture For Android

2, WEEX

Alibaba produced, JavaScript language, JS V8 engine, Vue design mode, native rendering

2.1. Concept structure

“Write once, run everywhere”. Weex is like writing a vUE front end and compiling it into a decent apK and IPA (although the reality is sometimes pretty skinny). Based on Vue design mode, it supports web, Android and ios terminals. The native terminal also converts controls and operations into native logic through the middle layer transformation to improve user experience.

Weex consists of JS Bridge, Render, and Dom, which respectively correspond to WXBridgeManager, WXRenderManager, and WXDomManager. The three parts are centrally managed by WXSDKManager. The JS Bridge and Dom both run in separate handlerthreads, while Render runs in the UI thread.

The JS Bridge is mainly used for two-way communication with the JS implementation, such as passing THE JS DOM structure to the DOM thread. The Dom is responsible for parsing, mapping, adding, and so on, and finally notifying the UI thread of updates. Render is responsible for the DOM rendering in the UI thread.

2.2. Implementation principle

Just like React Native, all labels of WEEx are not real controls. The DOM generated and stored in JS code is finally parsed by the native end, and then the corresponding native control is rendered. For example, in Android, the

tag corresponds to the WXTextView control.

The default file in weex is.vue, and the vue file cannot be run directly, so the vue will be compiled into the.js file. Weex SDK will load and render this JS file. Weex can cross the three terminals because during the development process, the code pattern, compilation process, template components, data binding, life cycle and other upper-level syntax is consistent. The difference is that at the end of JS Framework layer, web platform and Native platform execute different parsing methods for Virtual DOM.

In fact, the loading of the bundle file in Native generally goes through the following stages:

After weeX receives a JS file, the JS Framework invokes the createInstance method in weeX-Vue-Framework to create an instance based on the Vue mode of the file. (Also Rax mode)
CreateInstance creates a component with new Vue() in the Js Entry code and creates a Virtual DOM node with its render function.
The Virtual DOM is parsed by the JS V8 engine, and Json data is sent to the DOM line. The OUTPUT Json is also convenient for cross-terminal data transmission.
The Dom thread parses the Json data, gets the corresponding WxDomObject, and then creates the corresponding WxComponent to Render.
Render finally handles the rendering task on the native side and calls back JS methods.

Thanks to the unity of the upper layer, weeX-Vue-framework is only used to judge whether the real Dom is generated by vue. js or through Native Api rendering components. Weex, to a certain extent, uses JS to realize the unification of VUE.

Weex will gradually Render the data into native components after receiving the Render instruction when native Render. Render parses the description of the Render data and then distributes it to different modules.

For example, control rendering belongs to the DOM module, page jump belongs to the Navigator module and so on. The rendering process of a module is not a process of one execution and another execution, but a stream-like process. Before the last

component was rendered, the next

rendering was sent. In this way, when a component has many nested components, or you can see the UI within the large component, one by one rendering process.

Weex is mainly based on THE JS V8 engine compared with React Native, and more JS Framework takes on important responsibilities, which makes the upper layer unified and can support across three platforms. In general, its main responsibilities are: managing the Weex life cycle; Parse THE JS Bundle, convert it into Virtual DOM, and then build the page through the different API methods of the platform; Two-way data interaction and response.

2.3, packaging,

Weex, as a cross-platform implementation solution after React-Native, can naturally stand on the shoulders of predecessors to optimize problems, such as the problem of large Bundle files.

The size of the Bundle file greatly affects the performance of the Framework. Weex chooses to integrate JS Framework into WeexSDK, which reduces the volume of JS Bundle to a certain extent, so that only business code is retained in the Bundle.

Weex packages bundles through WebPack. The bundle configuration depends on how many entries are configured. By default, there is only one bundle for each entry.

As you can see in the weex project webpack.mon.conf.js, the packaging also distinguishes the different packaging methods of webConfig and weexConfig. In the figure below, weexEntry is where weeX is packaged and configured. You can see that index and entry.js already exist. If necessary, you can configure the packaging page you want, which I won’t expand here. Interested to see: Weex Principle to take you to squat.

3, Flutter

Made by Google, Dart language, Flutter Engine, responsive design mode, native rendering

The Flutter is a cross-platform mobile UI framework released by Google in 2018. Since I have already used React Native and Weex in my projects, Flutter has only been run in a simple Demo. After all, it is still in the beta phase. Here is a little bit more about its implementation mechanism and effects.

Unlike React Native and Weex, which are developed through Javascript, The programming language Flutter is Drat, “It is said that the Drat project team was selected because the Drat was located next to the Flutter (◐ retract ◑)), so executing does not require a Javascript engine, but the actual effect also ends up with native rendering.”

As shown above, Flutter is divided into Framework and Engine. We develop our App based on the Framework and run on the Engine. Engine is the independent virtual machine for Flutter, which is adapted and provides cross-platform support. It is currently assumed that the Flutter application runs directly on Engine on Android, so there is no need for the Dalvik VIRTUAL machine. (Is this more thorough than Kotlin, abandoning JVM entanglement?)

As shown below, thanks to the Engine layer, Flutter doesn’t even use the mobile platform’s native controls. Instead, it uses its own Engine to draw widgets (the display unit of the Flutter), and the Dart code is aoT-compiled to the platform’s native code. So the Flutter can communicate directly with the platform without the need for a JS engine bridge. The only thing Flutter requires the system to provide is a canvas to draw the UI. Yi? In this sense, support for the Web side is no problem!

In The Flutter, most things are widgets, and widgets are immutable, only support one frame, and do not update directly on each frame. To update, you must use the state of the widget. The core features of stateless and stateful widgets are the same, they are rebuilt every frame, and there is a State object that can store State data across frames and restore it.

Skia comes with Android. Skia is a 2D drawing engine library that is cross-platform, so it can be embedded into the iOS SDK of Flutter, which makes the Android SDK much smaller than the iOS SDK.

Three, contrast

This is the part where we hurt each other. (/ / / del / / /)

type	React Native	Weex	Flutter
Platform to realize	JavaScript	JavaScript	No bridge, native coding
engine	JSCore	JS V8	Flutter engine
The core of language	React	Vue	Dart
Apk size (Release)	7.6 M	10.6 M	8.1 M
Bundle File size	Default single, large	Small, multiple pages can be multiple files	Don’t need
To fit the difficulty	A little higher?	easy	general
Degree of framework	The heavier	The lighter	heavy
Features (not limited)	Suitable for overall App development	Suitable for single page	Suitable for overall App development
community	Rich, Facebook focus maintenance	A little residual, hosting Apache	Just starting out, he’s got a lot of fans
support	Android, IOS,	Android, IOS, Web	Android, IOS (and not just?)

1, size,

The Apk size above is the Apk size of the release signature that was packaged without adding any code after the project was created with React-native init, Weex Create and Flutter. As can be seen from the figure below, a large proportion of them are in the SO library.

2, community

React Native is one of the main open source projects on Facebook. So far, there are a variety of third-party libraries. Even open source projects such as Realm and Lottie also have React Native related versions. Of course, the robustness and compatibility of the third library is sometimes mixed because it is not a fully legitimate development platform.

Weex actually has a kind of domestic feeling. In fact, Weex’s design and concept are excellent, and performance is good, but compared with React Native’s third-party support, it seems a little stepmother. Since open source 2016, the community and various documents have been a little weak. As a cross-platform developer, most of the time, you certainly don’t want to add native function support frequently, because such a lot of work will run counter to the concept of cross-platform development, which will increase the development cost and maintenance difficulty.

Flutter is still in beta, but there is no doubt that Google’s appeal has been strong.

3, performance,

Theoretically, the performance of the Flutter should be the best, but in the actual experience, there is not much difference between the performance of the Flutter and react Native (after 0.5.0) and WEEX. Of course, there are no actual render milliseconds and frame rates.

4. Other differences

Weex multi-page implementation problem

Weex does not support

on the native side, which is different from react-Native. If you need to implement page redirection on the Native side, using Weee-Router will be very bad: the page will be blank after return without special processing. For reference to the official Demo playground, the native version of weex.requiremodule (‘navigator’) was implemented correctly.

At the same time, the design of navigator jump in WEEX also leads to the difference in the communication between multiple pages. Weex under multiple pages in data communication, are implemented via the url, such as file://assets/dist/SecondPage.js? Params =0, whereas vuex and Vue-Router are not shared across pages; However, when React Native is used across Actvity, because it is the same bundle file, as long as the manager is the same, the router and store can be used as well, and the data communication mode is the same as when Actvity is used.

Project template

Weex and React Native template code patterns are also different. The weex template is modified from cordova mode, and fixed modules are added with commands according to platform requirements. In the.gitignore platform folder, trace is ignored. React Native templates exist when the project is created, especially when third-party plug-in native side support is added. The template code is modified directly, and tracking changes are added to git code.