Native development technology

What is native development?

Native development refers to the development of pure native applications (REFERRED to as App). It is the development of apps on Android, iOS and other mobile platforms by using officially provided development languages, development libraries and development tools. For example, Android App refers to an App that uses Java or Kotlin development language to directly call Android SDK API development on Eclipse or Android Studio development tools. The iOS App refers to the App developed by directly calling the iOS SDK API on the Development tool of Xcode through Objective-C or Swift development language.

What are the pros and cons of native development?

Native App development represents better user experience and faster and higher performance, but the portability of native App is poor, especially for a native App, Android and iOS should be developed separately, and the same logic and interface should be written in two sets.

Main advantages:

  • Access to all Android/iOS features (GPS, camera…) ;
  • Fast speed, high performance and can achieve complex animation and drawing and the overall user experience is good.

Main disadvantages:

  • Platform-specific, high development cost; Different platforms must maintain different code, which increases the human cost;
  • Fixed content, weak dynamic; In most cases, when new features are updated and bugs are fixed, the App can only be reissued. Users need to download and upgrade the App again.

Cross-platform development technology

background

In the early stage of mobile Internet development, business scenarios were not complicated, and native development could also cope with product demand iteration. However, in recent years, with the advent of the Internet of Things era, mobile Internet advances rapidly and changes with each passing day. In many business scenarios, traditional pure native development can no longer meet the growing business needs.

The main performance is:

  • Dynamic content to demand when the demand changes, pure native applications need to upgrade to update the content, but time is needed to apps, the verification cycle, it is hard for high speed changes in the age of the Internet, so the application of dynamic (not hair also can update the application content) demand becomes imminent.
  • Business needs change rapidly, and the development cost increases, because the code of native development generally needs Android and iOS development teams to maintain, and when version iteration, both human cost and testing cost will increase.

Therefore, some cross-platform dynamic frameworks have been developed to address the two main issues of pure native development: dynamics and development cost.

H5+ native hybrid development

The main principle of this kind of framework is to realize part of the content that needs to be dynamically changed through H5, and use the web loading control WebView (Android) or WKWebView (iOS) of the native platform to load. In this way, the H5 part can be changed at any time without issuing a version, and it can meet the dynamic needs. Meanwhile, since the H5 code only needs to be developed once, it can run on both Android and iOS platforms, which can also reduce the development cost. That is to say, the more features of the H5 part, the lower the development cost. We call this H5+ native development mode Hybrid development, and the App developed in Hybrid mode is called Hybrid application or Hybrid App. If most of the functions of an App are realized by H5, we call it Web App.

Some of the best examples of hybrid frameworks are Taobao, Cordova and Ionic, and wechat miniprograms. It’s worth noting that wechat miniprograms are currently rendered in WebView, but will likely be rendered native in the future.

Mixed development technical point: communication between JS code and native code

In summary, native development can access all of the platform’s functions, but in hybrid development, H5 code runs in a WebView, which is essentially a browser kernel, and its JavaScript still runs in a sandbox with limited permissions, so access to most systems is limited. For example, the file system cannot be accessed or bluetooth cannot be used. Therefore, for the functions that H5 cannot achieve, we need to do them native. Hybrid frameworks generally provide some apis for JavaScript to access the system in advance in the native code, and then expose the WebView for JavaScript to call. In this way, the WebView becomes the communication bridge between JavaScript and the native API. It is mainly responsible for transferring call messages between JavaScript and native, and the message delivery must comply with a standard protocol, which specifies the format and meaning of the message, we rely on WebView, The tool for communicating between JavaScript and native and implementing a messaging protocol is called the WebView JavaScript Bridge (JsBridge for short) and is at the heart of the hybrid development framework.

Example: Javascript calls native API to get phone model

Let’s take Android as an example to implement a native API to get the phone model for JavaScript calls. In this example, you will see the flow of JavaScript calling the native API, so that you can get a sense of the flow. We use the open source dsBridge (Android version, iOS version) on Github to communicate. DsBridge is a cross-platform JsBridge that supports synchronous invocation, and only its synchronous invocation capability is used in this example.

1. First, realize the API of obtaining the phone model in native

class JSAPI{
  @JavascriptInterface
  public Object getPhoneModel(Object msg) {
    returnBuild.MODEL; }}Copy the code

2. Register native apis with JsBridge via WebView

import wendu.dsbridge.DWebView ... DWebView = (DWebView) findViewById(r.id.dwebView); . / / registered native API to JsBridge dwebView addJavascriptObject (new JSAPI (), null);Copy the code

3. Call native apis in JavaScript

var dsBridge=require("dsbridge"Var model= dsbridge.call ()"getPhoneModel"); // Print model console.log(model);Copy the code

The above example demonstrates the process of JavaScript calling native apis. Similarly, good JsBridge supports native JavaScript calls in general, as does dsBridge. If you are interested, Check out the Github dsBridge (Android, iOS) project home page.

conclusion

The advantages of mixed application are that the dynamic content is H5, new functions are added, and there is no need to issue the App again after fixing bugs. The Web technology stack, community and resources are rich, but the disadvantage is that the performance is not good. For complex user interface or animation, WebView cannot bear heavy responsibilities.

JavaScript development + native rendering

Currently, popular cross-platform frameworks for JavaScript development + Native rendering include Fast Application, Weex and React Native (RN for short).

Because RN and React work in the same way that Flutter is inspired by React and many ideas are in common, great oaks grow from little acrets. React is a responsive Web framework. Let’s first understand two important concepts: DOM tree and responsive programming.

The DOM tree

Document Object Model (DOM) is a standard programming interface recommended by W3C to deal with extensible markup language. It is a platform – and language-independent way to access and modify the content and structure of a Document. In other words, this is the standard interface for representing and processing an HTML or XML document. In the front-end development, it usually refers to the rendering tree corresponding to HTML, but the generalized DOM can also refer to the control tree corresponding to THE XML layout file in Android. And the term DOM operation refers to the direct operation of the rendering tree (or control tree). Therefore, You can see that DOM trees and control trees are equivalent concepts, except that the former is often used in Web development and the latter in native development.

Responsive programming

React framework reconstructs the USER interface in response to user state changes. This is a typical reactive programming approach. Here is a summary of the reactive principles in React:

  • Developers only need to focus on state transitions (data), and when the state changes, the React framework automatically reconstructs the UI based on the new state.
  • After receiving notification of user state changes, the React framework uses Diff algorithm to calculate the changed part of the tree based on the current rendering tree and the latest state changes, and then updates only the changed part of the tree (DOM operation), thus avoiding the whole tree reconstruction and improving performance.

It’s worth noting that in step 2 above, the React framework does not immediately calculate and render the changed part of the DOM tree after the state changes. Instead, React builds an abstraction layer on top of the DOM, namely the virtual DOM tree. Any changes made to the data and state are automatically and efficiently synchronized to the virtual DOM. Finally, batch sync to the real DOM instead of manipulating the DOM with each change. Why can’t we just manipulate the DOM tree every time we change? This is because every DOM operation in the browser can cause the browser to redraw or reflow:

  • If the DOM only changes in style, such as color, it will cause the browser to redraw the interface.
  • Changes in the structure of the DOM tree, such as size, layout, and node hiding, can cause browser backflow and relayout.

Browser redraw and backflow are expensive operations, and if you operate directly on the DOM for every change, it can cause performance problems, whereas batch operations only trigger one DOM update.

JavaScript development + native rendering cross-platform framework

RN

RN is a cross-platform mobile application development framework that Facebook opened source in April 2015. RN is a derivative of Facebook’s early open source JS framework React on the native mobile application platform, and currently supports both iOS and Android platforms. RN uses the JavaScript language, HTML-like JSX (JavaScript XML — an XML-like syntax that builds tags inside React components), and CSS to develop mobile applications, Therefore, technicians familiar with Web front-end development can enter the field of mobile application development with minimal learning.

RN is a derivative of React on the native mobile app platform. What are the main differences between the two? In fact, the main difference is what is the object of the virtual DOM map? The React virtual DOM is eventually mapped to the browser DOM tree, while the RN virtual DOM is mapped to the native control tree via JavaScriptCore.

JavaScriptCore is a JavaScript interpreter that serves two main functions in RN:

(1) Provide a running environment for JavaScript;

(2) JsBridge is a communication bridge between JavaScript and native JavaScript. It plays the same role as JsBridge. In fact, many JsBridge implementations in iOS are based on JavaScriptCore.

2. The process of mapping virtual DOM to native control through JavaScriptCore in RN is divided into two steps:

(1) Layout messaging, passing virtual DOM layout information to the native;

②, native according to the layout information through the corresponding native control rendering control tree.

At this point, RN is cross-platform. Compared to hybrid applications, RN is a native control rendering, so its performance is much better than H5 in hybrid applications. Meanwhile, RN is a Web development technology stack, and can be used on multiple platforms with only one piece of code to maintain.

Weex

RN only supports JSX syntax, while Weex supports Vue syntax and Rax syntax. Rax’s DSL syntax is created based on React JSX syntax, which is different from React. JSX is mandatory in Rax, it does not support component creation by other means, so learning JSX is a necessary foundation to use Rax.

Fast application

Kuaiapps is a lightweight application standard jointly developed by Huawei, Xiaomi and OPPO, as well as Meizu, the country’s nine leading mobile phone manufacturers, targeting small programs. It is also developed in JavaScript language, native control rendering, compared to RN and Weex in two major differences:

  • The app itself does not support Vue or React syntax. It uses native JavaScript for development, and its development framework is similar to wechat applet. It is worth mentioning that applet can be developed using Vue syntax (MPVUE) at present.
  • RN and Weex’s rendering/typesetting engines are integrated into the framework, and each App needs to be packaged in a large installation package. The quick application rendering/layout engine is integrated into ROM, no packaging is required, and the installation package is small, so fast applications can be distributed quickly while maintaining performance.

conclusion

The main advantages of JavaScript development + native rendering are as follows:

  • Adopting Web development technology stack, large community and fast development and relatively low development cost;
  • Native rendering, performance is much better than H5;
  • Dynamic is good, support hot update.

The main disadvantages of JavaScript + native rendering are as follows:

  • Communication between JavaScript and native is required for rendering, and in some scenarios, such as dragging, communication may cause congestion;
  • JavaScript is a scripting language, which requires JIT (just-in-time compilation) for execution, and there is still a gap between execution efficiency and AOT (pre-compiled) code.
  • Because rendering relies on native controls, controls for different platforms need to be maintained separately, and community controls may lag when systems are updated; In addition, the control system is also limited by the native UI system. For example, in Android, the rules for gesture collision disambiguation are fixed, which can be tricky when nested with controls written by different people.

Self-painted UI+ native

Self-drawing UI+ native is a cross-platform technology, the idea of this technology is: by implementing a unified interface rendering engine in different platforms to draw UI, and does not rely on system native controls, so it can achieve the consistency of different platform UI. Note that the draw engine addresses UI cross-platform issues, and if other system capabilities are involved, it still relies on native development.

The advantages of self-painting UI+ native are as follows:

  • High performance; Because the paint engine calls the system API directly to draw the UI, performance is close to native controls.
  • Flexibility, easy maintenance of component library and high fidelity and consistency of UI appearance; Because UI rendering does not rely on native controls, there is no need to maintain a separate set of component libraries for different platform controls, so the code is easy to maintain; Because the component library is the same set of code, the same rendering engine, so in different platforms, the component display appearance can achieve high fidelity and high consistency; In addition, by not relying on native controls, you are not limited by the native layout system, which makes the layout system very flexible.

Disadvantages of UI+ native are as follows:

  • Lack of dynamic; Because self-drawn UI systems typically compile their distributions in AOT mode to ensure UI rendering performance, applications cannot be delivered dynamically like Hybrid and RN frameworks that use JavaScript (JIT, just-in-time compilation) as a development language.
  • Low development efficiency: QT uses C++ as its development language, and the efficiency of programming will directly affect the efficiency of APP development. As a static language, C++ has less flexibility in UI development than dynamic languages such as JavaScript. In addition, C++ requires developers to manually manage memory allocation. There is no garbage collection (GC) mechanism in JavaScript and Java.

You might have guessed that Flutter is one of these cross-platform technologies. Yes, Flutter implements a self-drawing engine and has its own UI layout system. However, the idea of a draw engine is not a new one, nor is Flutter the first attempt to do so. There was a classic example before it, QT.

QT

QT is a cross-platform C++ graphical user interface application development framework developed by the QT Company in 1991. In 2008, Qt Company technology was acquired by Nokia, and Qt became a programming language tool under Nokia. Qt was acquired by Digia in 2012. In April 2014, Qt Creator 3.1.0, a cross-platform integrated development environment, was officially released, realizing full support for iOS. Plug-ins such as WinRT and Beautifier were added, GDB debugging support without Python interface was abandoned, and C/C++ code modules based on Clang were integrated. Android support has been tweaked to fully support iOS, Android, and WP, which gives app developers all the functionality they need to build graphical user interfaces. However, although QT in the PC was a brilliant success, and by the community, but its in the mobile terminal is poor performance, in recent years, although sometimes can hear the sound of the QT, but has been very weak, whatever how QT itself technology, design idea, but in fact is lost after all, the reason is that the author thinks that there are four main:

  • QT mobile development community is too small, insufficient learning materials, ecology is not good;
  • The official promotion is not good and the support is not enough;
  • Mobile came late, and the market has been occupied by other dynamic frameworks (Hybrid and RN).
  • In mobile development, C++ development has an inherent disadvantage compared to the Web development stack. As a direct result, QT development is inefficient.

Based on these four points, QT has become a martyr despite being a pioneer in developing cross-platform paint engines on mobile.

Flutter

Flutter is a cross-platform, high-fidelity, high-performance mobile application development framework developed by Google and open source. Dart language is used as the development language. Developers can use Dart language to develop Flutter App, a set of code that runs on both iOS and Android platforms. Flutter provides a wealth of components, interfaces, and developers can quickly add native extensions to Flutter.

Flutter differs from most other frameworks used to build apps because Flutter uses neither WebView nor native controls for platforms (Android, iOS, etc.). Instead, Flutter uses its own high-performance rendering engine to draw widgets. This ensures UI consistency on both Android and iOS platforms, and avoids the limitations and high maintenance costs associated with native controls dependency.

Flutter uses Skia as its 2D rendering engine. Skia is a Google LIBRARY of 2D graphics processing functions that provide efficient and compact representations of fonts, coordinate transformations, and bitmaps. Skia is cross-platform and provides a very friendly API. Flutter uses Skia as its drawing engine for both Google Chrome and Android. It is worth noting that Because Android already has Skia built-in, Flutter does not need to put Skia into APK when it packages Android applications. However, Skia is not built into iOS, so when building an iPA, Skia must also be packaged together. This is the main reason why the Android package of Flutter APP is smaller than the iOS package.

Flutter has its drawbacks, however. It does not support dynamic code delivery or hot updates.

Please poke to learn more about Flutter

This chapter summarizes

This chapter mainly introduces three cross-platform development technologies and native development technologies in mobile development. Now let’s compare the three cross-platform development technologies from the perspective of framework:

Technical types UI rendering performance Development efficiency dynamic Framework on behalf of
H5 + native The WebView rendering general high ✔ ️ Cordova, Ionic
JavaScript+ native rendering Native control rendering good high ✔ ️ RN, Weex
Self-painted UI+ native Call system API render good Flutter is high, QT is low Not supported by default QT, Flutter

Dynamic in the preceding table mainly refers to whether dynamic code delivery and hot update are supported. Note that the Release package of Flutter is compiled in Dart AOT mode by default, so it does not support dynamic behavior. Dart also supports JIT or SNAPSHOT execution, which will be described later.