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

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

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 / / /)

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.

Fourth, future trends

When choosing a framework, a lot of times we focus on the maturity and vitality of the framework (◐ retract ◑).

1, the React of Native

“Airbnb Announces Move away from React Native, Back to Native” : Airbnb is one of the biggest backers of the React Native platform, and its open-source Lottie supports both Native and React Native.

Airbnb also expressed a lot of affirmation of React Native in the article announcing the abandonment, but the reasons that made them give up mainly focus on the maintenance difficulties after the huge project, the good and bad of the third-party library, and the need to spend more energy on compatibility, which led to the abandonment.

Ps: The Lottie library Airbnb is a JSON file containing animation information that helps parse AE exports. This resolves the paradox that designers can focus on creating cool animations, while developers can simply support them.

Facebook is refactoring React Native, rewriting a lot of the underlying layer. After experiencing the storm of open source protocol, it can be seen that Facebook still attaches great importance to React Native. The underlying refactoring and optimization mainly focus on:

First, change the threading model. UI updates no longer need to be performed on three different threads, but instead JavaScript can be called synchronously on any thread for priority updates while pushing low-priority work out of the main thread in order to remain responsive to the UI. Second, asynchronous rendering was introduced into React Native, allowing multiple renderings to be performed and simplifying asynchronous data processing. Finally, simplify bridging to make it faster and lighter. Direct calls between native and JavaScript are more efficient and make it easier to build debugging tools, such as cross-language stack traces.

2, Weex

Not dead! Ali disclosed Weex technology architecture, but also open source a large wave of components. In early 2018, weex suffered a bit like Duddo (Dubbo was abandoned by Ali for a time due to internal competition). Weex was hosted by Apache after this wave of scandals, and WeexTeam on Github is still updated. Let’s see what happens next.

3, Flutter

The Flutter is Google’s cross-platform mobile UI framework. Dart is Google’s own son in Flutter, and Google’s new operating system Fuchsia supports Dart, which uses Flutter as an operational UI framework. All of this together makes you wonder if Android is going to be abandoned by Google.

Or promote the Flutter and Dart now on platforms like Android in order to make a good transition to the new system, because developers are part of the life of the operating system. Java and the JVM could be thrown out by Google entirely. Of course, at the moment Flutter seems to lack some grammatical sugar, the nested code is a bit hard to look at, or maybe it will be more beautiful when the official version is released.

The last

The content is a bit long, in fact, many points did not elaborate, but through this article, for the current situation and the future of mobile cross-platform, I hope it can give you a little help.

Ultra complete cross-platform open source project

Other Fluttr related articles:

• Overview of the Complete Development of Flutter (I. Dart Language and Foundation of Flutter)

• Overview of the Complete Development of Flutter (Ii. Rapid Development)

• Overview of the Complete Development of the Flutter (Packaging and Pit Filling)

• Overview of the Complete Development of Flutter (IV. Redux, Theme and Internationalization)

• Overview of the Complete Development of Flutter (v. In-depth Exploration)

• Overview of the Complete Development of Flutter (vi. In-depth Principles of Widgets)

• Overview of the Complete Development of Flutter (vii. In-depth Layout Principles)

• Overview of the Complete Development of Flutter (viii. Practical Tips and Pit filling)

• Overview of the Complete Development of Flutter (ix. In-depth Drawing Principles)

• Overview of the Complete Development of Flutter (10. In-depth Image Loading Process)

• Overview of the Complete Development of Flutter (xi, Comprehensive and In-depth Understanding Stream)

• Cross-platform Project Open Source Project Recommendation

React Native

• React Hooks: The Future of React Native

• From Android to React Native Development

• From Android to React Native development (II. Communication and Module Implementation)

• Develop from Android to React Native (iii)

• From Android to React Native Development (iv. Packaging process and release to Maven Library)

Other Weex related articles

• Weex principle takes you to squat