See how Facebook optimizes React Native performance, facebookreact

See how Facebook optimizes React Native performance, facebookreact

Source: facebook Source: @ Siva high waves

This article is translated from Facebook's official blog.

React Native allows us to use the Declarative Programming Model provided by React and Relay to write JavaScript to build our iOS and Android applications. This method makes our code more streamlined, easier to understand and read, and the code can be shared across multiple platforms. We can also speed up iteration (because there is no need to wait for a long compilation process during development. With React Native, we can release faster, refine more details, and make the application run more smoothly. In this regard, optimizing performance is an important part of our work. Next we will tell the story about how Facebook has doubled application performance ~

Why speed up?

When the application runs faster and the content is loaded more quickly, it means that users can spend more time using the application. The smooth animation allows users to enjoy the application. In the new market, 2G networks and models that were built a few years ago are still the main players. At this time, those with good performance are very different from those with slow running.

Since the release of React Native for iOS and Android versions, our team has been improving the scrolling performance of the List View and optimizing memory occupation, it makes the UI more responsive and accelerates application startup. In this case, application startup is an initial impression and a pressure source for other parts of the framework. Therefore, it is a top problem to be solved.

Quantize everything

We re-implemented the event homepage in Facebook's iOS version with RN (Click events on more tabs to view details ). This is a very good example for testing performance, because the native version has done a lot of optimization work, and this page is also a very good example of a typical list interaction.

Next, we automated CT-Scan performance testing to help us automatically locate the tab we need. Then, the event homepage is repeatedly opened and closed for 50 times. In each interaction, we can record the time from clicking the event button to the time when the event homepage is fully displayed, we also add more detailed performance tracking to tell us which steps are slow or CPU-consuming during the startup process.

Below is a rough description of the steps we have recorded and measured:

1 native startup: Initialize JavaScript virtual machines and some other native modules (such as disk cache, network, UI manager, etc)

2. JS initialization and dependency loading: Read the compressed JS code from the mobile phone storage and load it to the JavaScript Virtual Machine to parse and generate bytecode and load related dependencies.

3. Before data extraction, load and execute the application code of the event homepage, construct a Relay query statement, and trigger data retrieval.

4. Data retrieval: read data from the mobile phone disk cache

5. JS rendering: Initialize all related React components and send them to the native UI manager module for display.

6 native rendering: In the shadow thread, the view size is calculated based on the FlexBox layout. Create and locate these views in the main thread.

The prime rule behind this is: Never Forget regression testing. We continue to run it to track performance improvements and functional regression. Before submitting the modified Code, the developer uses it to run the specific submission and perform detailed performance analysis. Other tests also need to be established in the same way to measure such features and memory usage.

What happened at startup

When we set automatic performance tracing, we need a tool to give us more details to determine which parts of the startup process need optimization. In our framework, we add detailed start/stop performance anchors, collect data, and use the catapult viewer to locate the interaction between hot spots and blocked threads. You can also start the performance analysis of our applications from the developer menu.

In rn, the code is executed in a JavaScript thread. Every time you write data to a disk, in a network request, or retrieve some other native resources (such as cameras), your code needs to call the native module. When you want to render your React components, they will be forwarded to the native module of the interface manager. It will execute the layout and create the corresponding view in the main thread. Bridge Protocol to forward requests to native modules and be called back to your JS Code (if needed ). In rn, all native calls must be asynchronous to avoid blocking the main thread and JS thread.

In the following event component startup visualization diagram, we can see that the application is running in the JS queue. to display the event list, related cache reads are triggered asynchronously in the local storage queue ). Once the cache data is obtained, the application uses React to render the event cell in the JS queue, and then passes it to the grid queue for layout and finally to the main queue column to create a view display. This example shows that multiple cache reads (combined into a single common read operation can be faster) and some React rendering operations on JS threads can be merged in a unified manner.

Performance Improvement

The following are the most important performance and timing improvement practices in our implementation process, with links to corresponding code submission.

Do less at startup

• Cleanup of the Require/Babel auxiliary method (high priority): clears unnecessary logic and code executed during require for website preparation rather than RN
• Avoid copying and decoding strings when loading packaged files
• Remove the modules required during development: Unlike compiling code, JS does not need a pre-processor to remove the debug feature in release mode. Using the Babel conversion function, we can removeDEVThe code below the statement can effectively reduce the amount of code to be packaged, thus saving the JavaScript parsing time.
• Generate Event Description on the server

Arrange proper time for execution

• Lazy Loading
• Read incremental cache of Relay: at the beginning, Relay was born as a web project, so it only put the request response in the memory-the cache response of the first request to be read from the disk needs to read all the caches from the disk to the memory. By reading only the cache that meets specific query requests, we can significantly reduce the I/O load and the traffic from native to JS bridges.
• You do not need to call the batch Bridge Protocol. You need to call the Relay protocol in batches. At the beginning, we thought that by Batch Sending JS requests to the native module, we could reduce the load from calling the native to the JS bridge, however, performance analysis tells us that the bridge call between JS and native is not a performance bottleneck at all. In fact, the latency of batch operations on the UI interface or cache read will also delay operations on native threads, thus affecting application performance. In other cases, injection of Relay is used to pull cache reads of multiple key value data, which can be significantly improved through batch processing.
• Interface filling earlier
• Lazy loading of native modules
• Lazy binding on the touch of text components: it takes a lot of time to bind the touch Event Callback. So now we only need to bind the touch start event touch down event (that is, when you touch the object for the first time) and then bind other callback functions only after you touch the object, instead of binding all the calls at the beginning
• Delayed query of popular events:

Prepare for the speed of light

A few months ago, it took two seconds to start the event homepage on iPhone 5. After a lot of our performance optimization work on RN, the launch of the event homepage was doubled in London, menlopark and RN, React and Relay teams in New York. Most of our optimizations are implemented at the RN framework layer, which means that the developer's RN application will automatically benefit from this work (when they migrate the application to the latest version of RN ).

These optimizations are just the beginning: we will continue to work in all parts of the entire stack, from JavaScript code parsing time to data pulling performance. At the same time, you can also contribute to the community, learn how to make applications faster, and ask any questions you may encounter in the community forum. QQ technology exchange group 290551701