What is React Native

React Native is A framework for building Native apps using React. RN is A framework for building Native apps using React. We can also interpret RN as allowing us to develop native applications using only javascript, which is a common point when discussing the nature of RN.

React Native’s advantages?

What are the advantages of RN over developing an application using native, or Hybrid, or even the Web? Regardless of the context for the framework itself, RN has the following advantages:

  1. RN uses the same basic UI components as native apps, so it claims to have the same experience as native apps. However, the word “experience” is closely related to many details of actual development. Whether it can be consistent with native apps has certain requirements for developers.
  2. Cross-platform developers can only use JS to develop applications on IOS and Android platforms at the same time, which is quick and easy to get started for front-end developers. At the same time, because of the single technology stack, the development and maintenance of time and cost are lower, suitable for fast online.

But when you actually develop with RN, you’ll encounter a lot of discomfort

How does React Native work?

The react framework uses JSX to convert virtual DOM to real DOM. The react framework uses virtual DOM to convert virtual DOM to real DOM. And defined a set of rendering related configuration;

  • React ART host config
  • The React DOM host config
  • React Native host config

A brief glance through the Config file of RN shows that RN mainly relies on various apis under the UIManager module to achieve the rendering of native components. How is the rendering of style layout realized? RN uses Yoga to implement flex layouts in CSS, but some other styles are mapped to native properties. .

However, everything mentioned here stops at the JS part. After dom diff is calculated, how does RN communicate with the native end, and the JS instructions to be executed are transmitted to the native end?

source
here

First, the native configuration table needs to be injected into the JS execution environment, including some methods, modules and constants provided by Native. After the JS running environment is configured, the application can be started, and then the content of native module can be called. It should be noted that there is no pointer passing between JS and native, all parameters are passed as strings.

As I am ignorant of native development, I can only read @guoxiaoxing’s Vinci. It can simply be summarized that c++ plays a role as a bridge between js and native.

How does React Native compare to other technology stacks?

Here we borrow the data from the comparative analysis of H5, React Native and Native applications: develop a simple app relying on the three stacks to keep the same as possible and test the performance of the three stacks. Here we only take part of the data.

platform Average memory usage Maximum CPU usage Fluency (perceived by author) Update the cost Maintenance costs
RN 72MB 41% 95/100 Hot update, repair in time A single technology stack is easy to maintain
Native 117MB 34% 85/100 As the version is updated, platform review is required and the cycle is long Two teams cost more
Hybrid 137MB 30% 70/100 Stable update at any time Web + Native support, relatively simple

To sum up: Compared with pure Native, RN only has the advantages of development cost (corresponding developers + long development cycle), while compared with Hybrid, RN only has smaller advantages in performance modification and fluency (and these two advantages have certain requirements for developers). However, it sacrifices the cross-platform capability of H5 and has rapid iteration. The advantages of a prosperous community and easy to promote, I think it is best to be cautious in choosing RN.

How does React Native compare horizontally to similar technologies?

If you are sure to be native and confident (?) , you can also choose from RN, WEEx and FLUTTER.

  • The WEEX framework is similar to RN in that it encapsulates native components. Developers can simply use JS to “assemble” applications. However, Weex not only supports the output of native applications, but also supports the output of Web applications (i.e. a line of code, Build apps that run on ios, Android, and browsers.) This is a big advantage over RN. The only drawback is that WEEX does not support React, only RAx, but RAX claims to implement it based on the React standard.
  • Flutter really only addresses native cross-platform (ios and Android) issues and uses Dart, a new programming language, although I think Flutter was created primarily to address application development issues on Fuchsia. So until Fuchsia has a certain market share, flutter may not develop well (Flag). One of the main differences between Flutter and Weex and RN is that it renders a set of components rather than encapsulating native components, which may have some performance advantages.

React Native development practice

1. Technical selection

In fact, there was no complete technology selection process. At that time, the project team had accumulated experience in using RN to develop APP, so this project naturally inherited previous development experience and used RN to develop app. Now that I think about it, there is no reason. Firstly, without the advantage of a vibrant Web ecosystem, many components in the development process are self-developed, such as 1. Components for rendering tables, components for rendering Echart (developed again on Native Echart). In addition, the self-encapsulated components encountered performance problems in the later stage and were not solved (limited ability + time, and the team did not know how to native development); 2. Later requirement changes require simultaneous release of the browser version (PC+Mobile). The code of the two requirements cannot be reused, because this problem was not considered in the early stage of development, and the development framework combining iOS + Android + Web was not used.

2. Some problems encountered during actual development

  • About RN:
    • When there are multiple charts on the same page, one drawing component needs to open a WebView, and the use of multiple WebViews leads to a large memory consumption of the application. Considering now, hybrid pages should be used together. Or modify the Native Echart component to accept the options array and draw multiple charts one by one.
    • Rendering a large number of lists has obvious frame drop, most cases for long lists are page-turning (or lazy loading) processing, but there will be a few businesses do not page-turning, now think of the data should be processed, gradually put into the view.
    • People on the team who don’t have a good understanding of native development are better off not using RN. If you have a problem, you can only turn to search for help. Optimization can’t even begin, let alone deep customization.
  • About architecture
    • App uses Redux for state management. Due to multiple business functions, the entire Redux-related code is very large. Later, it was thought that you should separate the code that handles data from the code that handles business, and that page components barely handle data and only keep changes to the UI.
    • It seems that the framework RN does not have a high priority. If you do not know what is better, it is recommended to choose the framework hybrid for development. At least hybrid can run at both ends of Native + Web, and RN may not reach your ideal performance if you are not familiar with native development.

Reference reading:

  • React Native Research Report
  • Comparison and analysis of H5, React Native, and Native applications
  • React Native?
  • RN to update
  • React Native’s practice in “Vitality reading”
  • ReactNative- Source code parsing (recommended)
  • Understand React-native in depth
  • ReactNative source article