1. Background of React-native

Facebook created React-Native(RN) to build app. It was originally an internal project at Facebook in the summer of 2013. It became an open source project in 2015 because React was very popular in the community at that time. They felt that React was a good UI framework. So if you want to build a native-app, why not just let React run on the mobile operating system!

Therefore, in the same year, Facebook divided React into two independent libraries, namely React and React-dom. Maybe everyone is quite vague about this concept, let me explain briefly.

React: React is a JavaScript library for building user interfaces. It is a core library for creating React elements (elements), components (components) and virtual DOM (Virtual DOM), and managing the state and lifecycle of components in an application. React can be used on both client and server side including React Native.

React-dom: React-DOM is a supplement to the React library for DOM operations in browsers. React-DOM provides functions related to DOM, such as rendering React components into DOM and handling user interaction and other events.

Simply put, the React library provides a basic library for building component trees, while React-DOM provides you with some tools for Web pages, such as rendering components into web pages and supporting interaction through event responses.

From that point on, React doesn’t care which platform the component is rendered on. The rendering of the Web platform is undertaken by ReactDOM, while the rendering of the mobile platform is undertaken by RN.

2. What is React-native

RN is a cross-end framework based on javascript. RN provides the ability for a set of codes to run on multiple platforms.

The problem it initially solved was that on Android, developers need to implement a set of Java app, and on ios, they need to implement Swift, so we need to learn two languages ​​to implement a complete app.

That's what it felt like back then.

* web developers need to understand HTML, CSS, JS, React

* Android developers need to understand Java, Kotlin SDK

* ios developers need to know Object-c, Swift, CocoaPods.

In the R series family, React-native came into being, introducing a new platform to replace the previous one.

It looks like this now

This is what I mentioned earlier, React only manages the Fiber tree, em or component tree, and the rendering is left to react-dom or react-native.

* * *

Let’s further study how it runs on our app. rn actually uses React and Js to call native components and then build app. For example, the <Image/> component represents two other native components, Android's ImageView and iOS's UIImageView. In this rn architecture, it is controlled by two threads, a js thread and a native thread.


1. First, let me talk about js threads. Let us first have a concept. For example: our browser uses a virtual engine to execute js code like v8. This means that if our code wants to run on rn, it also needs a virtual engine to execute our api and process our events. At the beginning, there was the JScore engine built into ios, but when packaging Android, this engine would make the package larger and could not be used, so the new engine Hermes was adopted after version 0.6. After 0.64, ios also adopted this engine. After all, it is indeed better, as follows its advantages.

* Faster startup speed.

* Smaller bags.

* Less memory usage.

As in the browser, JS in rn is implemented in a single thread. This thread is responsible for executing JS. The business logic we are writing will be executed in this thread. This means that all our common code, such as components, state, hooks and REST API calls, will be handled in the JS part of the application.

2. So what does the native thread do? It is actually the place where native code is executed. rn implements this part on every platform (java, oc, ios). Most of the contents of this thread are sdk that communicates with Android ios, and at the same time provides us with a unified api. For example: if I call an alert pop-up window, the native layer integrates the two platforms to provide a unified api, and then we call it in the js thread. In fact, this is the interaction of threads. From the perspective of the native thread, we have to pop up a warning. It is actually two parts, Native ui to update the page, and Native Muddles to access platform-specific functions.

* * *

Above we talked about what the two threads do, and then the communication between threads is definitely inseparable. The communication between the two threads is through the bridge (just understand it). This bridge is written in C++ and is based on an asynchronous queue. When the bridge receives data from one of the parties, it serializes it, converts it to a JSON string, and queues it. After reaching the destination, the data is deserialized.

Taking the above alert as an example, native accepts the callback from JS and displays the dialog box. In fact, when the JS method is called, it sends a message to the bridge, and when the message is received, native executes the instruction. Native messages can also be forwarded to JS. For example, when the button is clicked, native sends a click event message to js. Something like this:


It should be easy for everyone to find the problem, because all events rely on the asynchronous bridge to complete the communication, you may face performance problems caused by the queue load being too high, but it does exist. It can only be said that there are pros and cons. Let us leave this suspense for now and see how the RN architecture handles this problem later (there is too much content about the new architecture in the next article).

* * *

In fact, the use of RN is to use asynchronous callbacks to operate the underlying mobile operating system, that is, to call the native api. rn has a JavaScript engine, and RN API is basically the same as Web's React, the difference is the native side; Rn is a native API called asynchronously, not DOM. As shown in the picture:

* RN uses the same React library used on web (that is, the React core library mentioned earlier) and runs in JavaScriptCore.

* Messages sent to Native api are asynchronous and batched.

* RN ships with components implemented for mobile platforms rather than components for HTML elements.

* RN actually represents the method of rendering components through iOS and Android api. It can use the same concepts to render on tvOS, TV, Windows, macOS, and even the web.

3. Advantages of using React-native

It is actually quite difficult to implement a new rendering for React. Just imagine it is like inventing a new dom that can run on ios and Android. However, cross-end applications still have to be done. I think there are several reasons.

1. The most important thing is that demand gives birth to technology, because of the huge demand for mobile terminals, and the performance of H5 is not satisfactory (that is, the user experience is poor), and rn is actually a disguised form of calling the native api which will be much better.

2. Then there is jsx. Maybe the reason why I don’t like flutter as much as rn is because of this. The learning cost is low.

3. Commercial value Luo, I don’t need to say much about what the client has become in recent years (but on the other hand, people still need to do some bridging things).

4. The philosophy of self-feeling Rn

I will just talk about my feelings about RN here.

How do you say that? Maybe everyone thinks that rn means that you can use react syntax to write an application that runs on any native device.

But no, because ios and Android are different at many basic levels, and even their UX philosophies are completely different (this is actually the reason why ios is much better), so it is really impossible to write a single app that does not handle both situations.

To put it simply, rn does not implement a component library for you to run anywhere, it only handles the overlap of native. rn is not written once and can be run anywhere (unless you don’t care about user experience at all). It should be said to be learned once and written at the task location. You need to use specific ios/Android components in some cases to provide a better UX (but in fact rn has already helped you deal with many differences and provided many common basic components, but you may need to have something similar to a red line awareness of platform differences in your mind)

5. Talk about products and apps

In fact, for users, the threshold of web application is far lower than that of app. If there is no strong demand, everyone is not willing to install a gray app. Everyone should prefer a browser to view some things, although it is not as good as the app experience.

Suppose I have a c-end product at this time, how should we choose its platform?

1. PC web.

2. Mobile web (tablet, mobile phone).

3. Mobile app.

If it is a large product with complex functions, you must choose app, and if it is a small product with a single function, you can choose the mobile web. Let me talk about why mobile browsers lack many features of mobile applications from a technical perspective. This is because the browser's HTML elements cannot maintain the same UI and interaction as native components. Although we can try to restore it, it is too troublesome.

Then there's the fact that user interaction on mobile devices is fundamentally different than usual interaction with HTML5. For example: the click event of the web, the event of clicking a button is just a stage. However, when the user uses their fingers to interact with the screen, the person keeps sliding (you have to count various touches x y and so on). There is a native gesture system that allows it to handle this problem. The web makes this extremely complicated.

To briefly summarize

1. The UI and interaction of mobile browsers are not unified with the native ones. Some designs even propose writing forms on the mobile terminal, but to be honest, this should not be part of the mobile experience at all.

2. Web applications lack many native capabilities, such as the gesture system mentioned above.

6. End

Because my business is writing Rn recently, it just helps to consolidate some knowledge and enhance everyone's competitiveness. It is estimated that there will be many chapters in this part later. This kind of concept is quite important, and everyone can absorb it. Woo! Do you want to be strong? Then come and learn together, ->Look at the boiling point here.