使用 React Native 替代基于 WebView 的框架來開發(fā) App 的一個(gè)強(qiáng)有力的理由，就是為了使 App 可以達(dá)到每秒 60 幀（足夠流暢），并且能有類似原生 App 的外觀和手感。因此我們也盡可能地優(yōu)化 React Native 去實(shí)現(xiàn)這一目標(biāo)，使開發(fā)者能集中精力處理 App 的業(yè)務(wù)邏輯，而不用費(fèi)心考慮性能。但是，總還是有一些地方有所欠缺，以及在某些場合 React Native 還不能夠替你決定如何進(jìn)行優(yōu)化（用原生代碼寫也無法避免），因此人工的干預(yù)依然是必要的。
本文的目的是教給你一些基本的知識，來幫你排查性能方面的問題，以及探討這些問題產(chǎn)生的原因和推薦的解決方法。
關(guān)于“幀”你所需要知道的
老一輩人常常把電影稱為“移動(dòng)的畫”，是因?yàn)橐曨l中逼真的動(dòng)態(tài)效果其實(shí)是一種幻覺，這種幻覺是由一組靜態(tài)的圖片以一個(gè)穩(wěn)定的速度快速變化所產(chǎn)生的。我們把這組圖片中的每一張圖片叫做一幀，而每秒鐘顯示的幀數(shù)直接的影響了視頻（或者說用戶界面）的流暢度和真實(shí)感。iOS 設(shè)備提供了每秒 60 的幀率，這就留給了開發(fā)者和 UI 系統(tǒng)大約 16.67ms 來完成生成一張靜態(tài)圖片（幀）所需要的所有工作。如果在這分派的 16.67ms 之內(nèi)沒有能夠完成這些工作，就會(huì)引發(fā)‘丟幀’的后果，使界面表現(xiàn)的不夠流暢。
下面要講的事情可能更為復(fù)雜：請先調(diào)出你應(yīng)用的開發(fā)菜單，打開Show FPS Monitor. 你會(huì)注意到有兩個(gè)不同的幀率.
JS 幀率(JavaScript 線程)
對大多數(shù) React Native 應(yīng)用來說，業(yè)務(wù)邏輯是運(yùn)行在 JavaScript 線程上的。這是 React 應(yīng)用所在的線程，也是發(fā)生 API 調(diào)用，以及處理觸摸事件等操作的線程。更新數(shù)據(jù)到原生支持的視圖是批量進(jìn)行的，并且在事件循環(huán)每進(jìn)行一次的時(shí)候被發(fā)送到原生端，這一步通常會(huì)在一幀時(shí)間結(jié)束之前處理完（如果一切順利的話）。如果 JavaScript 線程有一幀沒有及時(shí)響應(yīng)，就被認(rèn)為發(fā)生了一次丟幀。 例如，你在一個(gè)復(fù)雜應(yīng)用的根組件上調(diào)用了this.setState，從而導(dǎo)致一次開銷很大的子組件樹的重繪，可想而知，這可能會(huì)花費(fèi) 200ms 也就是整整 12 幀的丟失。此時(shí)，任何由 JavaScript 控制的動(dòng)畫都會(huì)卡住。只要卡頓超過 100ms，用戶就會(huì)明顯的感覺到。
這種情況經(jīng)常發(fā)生在老的Navigator導(dǎo)航器的切換過程中：當(dāng)你 push 一個(gè)新的路由時(shí)，JavaScript 需要繪制新場景所需的所有組件，以發(fā)送正確的命令給原生端去創(chuàng)建視圖。由于切換是由 JavaScript 線程所控制，因此經(jīng)常會(huì)占用若干幀的時(shí)間，引起一些卡頓。有的時(shí)候，組件會(huì)在componentDidMount函數(shù)中做一些額外的事情，這甚至可能會(huì)導(dǎo)致頁面切換過程中多達(dá)一秒的卡頓。
另一個(gè)例子是老的觸摸事件的響應(yīng)：如果你正在 JavaScript 線程處理一個(gè)跨越多個(gè)幀的工作，你可能會(huì)注意到TouchableOpacity的響應(yīng)被延遲了。這是因?yàn)?JavaScript 線程太忙了，不能夠處理主線程發(fā)送過來的原始觸摸事件，結(jié)果TouchableOpacity就不能及時(shí)響應(yīng)這些事件并命令主線程的頁面去調(diào)整透明度了。
UI 幀率(主線程)
很多人會(huì)注意到，NavigatorIOS的性能要比老的純 JS 實(shí)現(xiàn)的Navigator好的多。原因就是它的切換動(dòng)畫是完全在主線程上執(zhí)行的，因此不會(huì)被 JavaScript 線程上的掉幀所影響。
同樣，當(dāng) JavaScript 線程卡住的時(shí)候，你仍然可以歡快的上下滾動(dòng)ScrollView，因?yàn)镾crollView運(yùn)行在主線程之上（盡管滾動(dòng)事件會(huì)被分發(fā)到 JS 線程，但是接收這些事件對于滾動(dòng)這個(gè)動(dòng)作來說并不必要）。
性能問題的常見原因
開發(fā)模式 (dev=true)
JavaScript 線程的性能在開發(fā)模式下是很糟糕的。這是不可避免的，因?yàn)橛性S多工作需要在運(yùn)行的時(shí)候去做，譬如使你獲得良好的警告和錯(cuò)誤信息，又比如驗(yàn)證屬性類型（propTypes）以及產(chǎn)生各種其他的警告。請務(wù)必注意在release 模式下去測試性能。
console.log 語句
在運(yùn)行打好了離線包的應(yīng)用時(shí)，控制臺打印語句可能會(huì)極大地拖累 JavaScript 線程。注意有些第三方調(diào)試庫也可能包含控制臺打印語句，比如redux-logger，所以在發(fā)布應(yīng)用前請務(wù)必仔細(xì)檢查，確保全部移除。
這里有個(gè)小技巧可以在發(fā)布時(shí)屏蔽掉所有的console.*調(diào)用。React Native 中有一個(gè)全局變量__DEV__用于指示當(dāng)前運(yùn)行環(huán)境是否是開發(fā)環(huán)境。我們可以據(jù)此在正式環(huán)境中替換掉系統(tǒng)原先的 console 實(shí)現(xiàn)。
if (!__DEV__) {
??global.console = {
????info: () => {},
????log: () => {},
????warn: () => {},
????debug: () => {},
????error: () => {}
??};
}
這樣在打包發(fā)布時(shí)，所有的控制臺語句就會(huì)被自動(dòng)替換為空函數(shù)，而在調(diào)試時(shí)它們?nèi)匀粫?huì)被正常調(diào)用。
還有個(gè)babel 插件可以幫你移除所有的console.*調(diào)用。首先需要使用yarn add --dev babel-plugin-transform-remove-console來安裝，然后在項(xiàng)目根目錄下編輯（或者是新建）一個(gè)名為·.babelrc`的文件，在其中加入：
{
??"env": {
????"production": {
??????"plugins": ["transform-remove-console"]
????}
??}
}
這樣在打包發(fā)布時(shí)，所有的控制臺語句就會(huì)被自動(dòng)移除，而在調(diào)試時(shí)它們?nèi)匀粫?huì)被正常調(diào)用。
ListViewinitial rendering is too slow or scroll performance is bad for large lists
Use the newFlatListorSectionListcomponent instead. Besides simplifying the API, the new list components also have significant performance enhancements, the main one being nearly constant memory usage for any number of rows.
If yourFlatListis rendering slow, be sure that you've implementedgetItemLayoutto optimize rendering speed by skipping measurement of the rendered items.
在重繪一個(gè)幾乎沒有什么變化的頁面時(shí)，JS 幀率嚴(yán)重降低
你可以實(shí)現(xiàn)shouldComponentUpdate函數(shù)來指明在什么樣的確切條件下，你希望這個(gè)組件得到重繪。如果你編寫的是純粹的組件（界面完全由 props 和 state 所決定），你可以利用PureComponent來為你做這個(gè)工作。再強(qiáng)調(diào)一次，不可變的數(shù)據(jù)結(jié)構(gòu)（immutable，即對于引用類型數(shù)據(jù)，不修改原值，而是復(fù)制后修改并返回新值）在提速方面非常有用 —— 當(dāng)你不得不對一個(gè)長列表對象做一個(gè)深度的比較，它會(huì)使重繪你的整個(gè)組件更加快速，而且代碼量更少。
在屏幕上移動(dòng)視圖（滾動(dòng)，切換，旋轉(zhuǎn)）時(shí)，UI 線程掉幀
當(dāng)具有透明背景的文本位于一張圖片上時(shí)，或者在每幀重繪視圖時(shí)需要用到透明合成的任何其他情況下，這種現(xiàn)象尤為明顯。設(shè)置shouldRasterizeIOS或者renderToHardwareTextureAndroid屬性可以顯著改善這一現(xiàn)象。 注意不要過度使用該特性，否則你的內(nèi)存使用量將會(huì)飛漲。在使用時(shí)，要評估你的性能和內(nèi)存使用情況。如果你沒有需要移動(dòng)這個(gè)視圖的需求，請關(guān)閉這一屬性。
使用動(dòng)畫改變圖片的尺寸時(shí)，UI 線程掉幀
在 iOS 上，每次調(diào)整 Image 組件的寬度或者高度，都需要重新裁剪和縮放原始圖片。這個(gè)操作開銷會(huì)非常大，尤其是大的圖片。比起直接修改尺寸，更好的方案是使用transform: [{scale}]的樣式屬性來改變尺寸。比如當(dāng)你點(diǎn)擊一個(gè)圖片，要將它放大到全屏的時(shí)候，就可以使用這個(gè)屬性。
Touchable 系列組件不能很好的響應(yīng)
有些時(shí)候，如果我們有一項(xiàng)操作與點(diǎn)擊事件所帶來的透明度改變或者高亮效果發(fā)生在同一幀中，那么有可能在onPress函數(shù)結(jié)束之前我們都看不到這些效果。比如在onPress執(zhí)行了一個(gè)setState的操作，這個(gè)操作需要大量計(jì)算工作并且導(dǎo)致了掉幀。對此的一個(gè)解決方案是將onPress處理函數(shù)中的操作封裝到requestAnimationFrame中：
handleOnPress() {
??// 謹(jǐn)記在使用requestAnimationFrame、setTimeout以及setInterval時(shí)
??// 要使用TimerMixin（其作用是在組件unmount時(shí)，清除所有定時(shí)器）
??this.requestAnimationFrame(() => {
????this.doExpensiveAction();
??});
}
分析
你可以利用內(nèi)置的分析器來同時(shí)獲取 JavaScript 線程和主線程中代碼執(zhí)行情況的詳細(xì)信息。
對于 iOS 來說，Instruments 是一個(gè)寶貴的工具庫，Android 的話可以使用 systrace，具體可以參考下面的使用 systrace 調(diào)試 Android UI 性能。
But first,make sure that Development Mode is OFF!You should see__DEV__ === false, development-level warning are OFF, performance optimizations are ONin your application logs.
Another way to profile JavaScript is to use the Chrome profiler while debugging. This won't give you accurate results as the code is running in Chrome but will give you a general idea of where bottlenecks might be. Run the profiler under Chrome'sPerformancetab. A flame graph will appear underUser Timing. To view more details in tabular format, click at theBottom Uptab below and then selectDedicatedWorker Threadat the top left menu.
使用 systrace 調(diào)試 Android UI 性能
Android supports 10k+ different phones and is generalized to support software rendering: the framework architecture and need to generalize across many hardware targets unfortunately means you get less for free relative to iOS. But sometimes, there are things you can improve -- and many times it's not native code's fault at all!
The first step for debugging this jank is to answer the fundamental question of where your time is being spent during each 16ms frame. For that, we'll be using a standard Android profiling tool calledsystrace.
systraceis a standard Android marker-based profiling tool (and is installed when you install the Android platform-tools package). Profiled code blocks are surrounded by start/end markers which are then visualized in a colorful chart format. Both the Android SDK and React Native framework provide standard markers that you can visualize.
1. Collecting a trace
First, connect a device that exhibits the stuttering you want to investigate to your computer via USB and get it to the point right before the navigation/animation you want to profile. Runsystraceas follows:
$ <path_to_android_sdk>/platform-tools/systrace/systrace.py --time=10 -o trace.html sched gfx view -a <your_package_name>
A quick breakdown of this command:
timeis the length of time the trace will be collected in seconds
sched,gfx, andvieware the android SDK tags (collections of markers) we care about:schedgives you information about what's running on each core of your phone,gfxgives you graphics info such as frame boundaries, andviewgives you information about measure, layout, and draw passes
-a <your_package_name>enables app-specific markers, specifically the ones built into the React Native framework.your_package_namecan be found in theAndroidManifest.xmlof your app and looks likecom.example.app
Once the trace starts collecting, perform the animation or interaction you care about. At the end of the trace, systrace will give you a link to the trace which you can open in your browser.
2. Reading the trace
After opening the trace in your browser (preferably Chrome), you should see something like this:
HINT: Use the WASD keys to strafe and zoom
If your trace .html file isn't opening correctly, check your browser console for the following:
SinceObject.observewas deprecated in recent browsers, you may have to open the file from the Google Chrome Tracing tool. You can do so by:
Opening tab in chromechrome://tracing
Selecting load
Selecting the html file generated from the previous command.
Enable VSync highlighting
Check this checkbox at the top right of the screen to highlight the 16ms frame boundaries:
You should see zebra stripes as in the screenshot above. If you don't, try profiling on a different device: Samsung has been known to have issues displaying vsyncs while the Nexus series is generally pretty reliable.
3. Find your process
Scroll until you see (part of) the name of your package. In this case, I was profilingcom.facebook.adsmanager, which shows up asbook.adsmanagerbecause of silly thread name limits in the kernel.
On the left side, you'll see a set of threads which correspond to the timeline rows on the right. There are a few threads we care about for our purposes: the UI thread (which has your package name or the name UI Thread),mqt_js, andmqt_native_modules. If you're running on Android 5+, we also care about the Render Thread.
UI Thread.This is where standard android measure/layout/draw happens. The thread name on the right will be your package name (in my case book.adsmanager) or UI Thread. The events that you see on this thread should look something like this and have to do withChoreographer,traversals, andDispatchUI:
JS Thread.This is where JavaScript is executed. The thread name will be eithermqt_jsor<...>depending on how cooperative the kernel on your device is being. To identify it if it doesn't have a name, look for things likeJSCall,Bridge.executeJSCall, etc:
Native Modules Thread.This is where native module calls (e.g. theUIManager) are executed. The thread name will be eithermqt_native_modulesor<...>. To identify it in the latter case, look for things likeNativeCall,callJavaModuleMethod, andonBatchComplete:
Bonus: Render Thread.If you're using Android L (5.0) and up, you will also have a render thread in your application. This thread generates the actual OpenGL commands used to draw your UI. The thread name will be eitherRenderThreador<...>. To identify it in the latter case, look for things likeDrawFrameandqueueBuffer:
Identifying a culprit
A smooth animation should look something like the following:
Each change in color is a frame -- remember that in order to display a frame, all our UI work needs to be done by the end of that 16ms period. Notice that no thread is working close to the frame boundary. An application rendering like this is rendering at 60 FPS.
If you noticed chop, however, you might see something like this:
Notice that the JS thread is executing basically all the time, and across frame boundaries! This app is not rendering at 60 FPS. In this case,the problem lies in JS.
You might also see something like this:
In this case, the UI and render threads are the ones that have work crossing frame boundaries. The UI that we're trying to render on each frame is requiring too much work to be done. In this case,the problem lies in the native views being rendered.
At this point, you'll have some very helpful information to inform your next steps.
Resolving JavaScript issues
If you identified a JS problem, look for clues in the specific JS that you're executing. In the scenario above, we seeRCTEventEmitterbeing called multiple times per frame. Here's a zoom-in of the JS thread from the trace above:
This doesn't seem right. Why is it being called so often? Are they actually different events? The answers to these questions will probably depend on your product code. And many times, you'll want to look intoshouldComponentUpdate.
Resolving native UI Issues
If you identified a native UI problem, there are usually two scenarios:
the UI you're trying to draw each frame involves too much work on the GPU, or
You're constructing new UI during the animation/interaction (e.g. loading in new content during a scroll).
Too much GPU work
In the first scenario, you'll see a trace that has the UI thread and/or Render Thread looking like this:
Notice the long amount of time spent inDrawFramethat crosses frame boundaries. This is time spent waiting for the GPU to drain its command buffer from the previous frame.
To mitigate this, you should:
investigate usingrenderToHardwareTextureAndroidfor complex, static content that is being animated/transformed (e.g. theNavigatorslide/alpha animations)
make sure that you arenotusingneedsOffscreenAlphaCompositing, which is disabled by default, as it greatly increases the per-frame load on the GPU in most cases.
If these don't help and you want to dig deeper into what the GPU is actually doing, you can check outTracer for OpenGL ES.
Creating new views on the UI thread
In the second scenario, you'll see something more like this:
Notice that first the JS thread thinks for a bit, then you see some work done on the native modules thread, followed by an expensive traversal on the UI thread.
There isn't an easy way to mitigate this unless you're able to postpone creating new UI until after the interaction, or you are able to simplify the UI you're creating. The react native team is working on an infrastructure level solution for this that will allow new UI to be created and configured off the main thread, allowing the interaction to continue smoothly.
拆包(RAM bundles)和內(nèi)聯(lián)引用
如果你有一個(gè)較為龐大的應(yīng)用程序，你可能要考慮使用RAM(Random Access Modules，隨機(jī)存取模塊）格式的 bundle 和內(nèi)聯(lián)引用。這對于具有大量頁面的應(yīng)用程序是非常有用的，這些頁面在應(yīng)用程序的典型使用過程中可能不會(huì)被打開。通常對于啟動(dòng)后一段時(shí)間內(nèi)不需要大量代碼的應(yīng)用程序來說是非常有用的。例如應(yīng)用程序包含復(fù)雜的配置文件屏幕或較少使用的功能，但大多數(shù)會(huì)話只涉及訪問應(yīng)用程序的主屏幕更新。我們可以通過使用RAM格式來優(yōu)化bundle的加載，并且內(nèi)聯(lián)引用這些功能和頁面（當(dāng)它們被實(shí)際使用時(shí)）。
加載 JavaScript
在 react-native 執(zhí)行 JS 代碼之前，必須將代碼加載到內(nèi)存中并進(jìn)行解析。如果你加載了一個(gè) 50MB 的 bundle，那么所有的 50mb 都必須被加載和解析才能被執(zhí)行。RAM 格式的 bundle 則對此進(jìn)行了優(yōu)化，即啟動(dòng)時(shí)只加載 50MB 中實(shí)際需要的部分，之后再逐漸按需加載更多的包。
內(nèi)聯(lián)引用
內(nèi)聯(lián)引用(require 代替 import)可以延遲模塊或文件的加載，直到實(shí)際需要該文件。一個(gè)基本的例子看起來像這樣：
優(yōu)化前
import React, { Component } from 'react';
import { Text } from 'react-native';
// ... import some very expensive modules
// You may want to log at the file level to verify when this is happening
console.log('VeryExpensive component loaded');
export default class VeryExpensive extends Component {
??// lots and lots of code
??render() {
????return <Text>Very Expensive Component</Text>;
??}
}
優(yōu)化后
import React, { Component } from 'react';
import { TouchableOpacity, View, Text } from 'react-native';
let VeryExpensive = null;
export default class Optimized extends Component {
??state = { needsExpensive: false };
??didPress = () => {
????if (VeryExpensive == null) {
??????VeryExpensive = require('./VeryExpensive').default;
????}
????this.setState(() => ({
??????needsExpensive: true,
????}));
??};
??render() {
????return (
??????<View style={{ marginTop: 20 }}>
????????<TouchableOpacity onPress={this.didPress}>
??????????<Text>Load</Text>
????????</TouchableOpacity>
????????{this.state.needsExpensive ? <VeryExpensive /> : null}
??????</View>
????);
??}
}
即便不使用 RAM 格式，內(nèi)聯(lián)引用也會(huì)使啟動(dòng)時(shí)間減少，因?yàn)閮?yōu)化后的代碼只有在第一次 require 時(shí)才會(huì)執(zhí)行。
啟用 RAM 格式
在 iOS 上使用 RAM 格式將創(chuàng)建一個(gè)簡單的索引文件，React Native 將根據(jù)此文件一次加載一個(gè)模塊。在 Android 上，默認(rèn)情況下它會(huì)為每個(gè)模塊創(chuàng)建一組文件。你可以像 iOS 一樣，強(qiáng)制 Android 只創(chuàng)建一個(gè)文件，但使用多個(gè)文件可以提高性能，并降低內(nèi)存占用。
在 Xcode 中啟用 RAM 格式，需要編輯 build phase 里的"Bundle React Native code and images"。在../node_modules/react-native/packager/react-native-xcode.sh中添加export BUNDLE_COMMAND="ram-bundle":
export BUNDLE_COMMAND="ram-bundle"
export NODE_BINARY=node
../node_modules/react-native/packager/react-native-xcode.sh
在 Android 上啟用 RAM 格式，需要編輯 android/app/build.gradle 文件。在apply from: "../../node_modules/react-native/react.gradle"之前修改或添加project.ext.react：
project.ext.react = [
??bundleCommand: "ram-bundle",
]
如果在 Android 上，你想使用單個(gè)索引文件（如前所述），請?jiān)?Android 上使用以下行：
project.ext.react = [
??bundleCommand: "ram-bundle",
??extraPackagerArgs: ["--indexed-ram-bundle"]
]
配置預(yù)加載及內(nèi)聯(lián)引用
現(xiàn)在我們已經(jīng)啟用了RAM格式，然而調(diào)用require會(huì)造成額外的開銷。因?yàn)楫?dāng)遇到尚未加載的模塊時(shí)，require需要通過bridge來發(fā)送消息。這主要會(huì)影響到啟動(dòng)速度，因?yàn)樵趹?yīng)用程序加載初始模塊時(shí)可能觸發(fā)相當(dāng)大量的請求調(diào)用。幸運(yùn)的是，我們可以配置一部分模塊進(jìn)行預(yù)加載。為了做到這一點(diǎn)，你將需要實(shí)現(xiàn)某種形式的內(nèi)聯(lián)引用。
添加 packager 配置文件
在項(xiàng)目中創(chuàng)建一個(gè)名為 packager 的文件夾，并創(chuàng)建一個(gè)名為 config.js 的文件。添加以下內(nèi)容：
const config = {
??transformer: {
????getTransformOptions: () => {
??????return {
????????transform: { inlineRequires: true },
??????};
????},
??},
};
module.exports = config;
在 Xcode 的 Build phase 中添加export BUNDLE_CONFIG="packager/config.js"
export BUNDLE_COMMAND="ram-bundle"
export BUNDLE_CONFIG="packager/config.js"
export NODE_BINARY=node
../node_modules/react-native/packager/react-native-xcode.sh
編輯 android/app/build.gradle 文件，添加bundleConfig: "packager/config.js",
project.ext.react = [
??bundleCommand: "ram-bundle",
??bundleConfig: "packager/config.js"
]
最后，在 package.json 的“scripts”下修改“start”命令來啟用配置文件：
"start": "node node_modules/react-native/local-cli/cli.js start --config ../../../../packager/config.js",
此時(shí)用npm start啟動(dòng)你的 packager 服務(wù)即會(huì)加載配置文件。請注意，如果你仍然通過 xcode 或是 react-native run-android 等方式自動(dòng)啟動(dòng) packager 服務(wù)，則由于沒有使用上面的參數(shù)，不會(huì)加載配置文件。
調(diào)試預(yù)加載的模塊
在您的根文件 (index.(ios|android).js) 中，您可以在初始導(dǎo)入(initial imports)之后添加以下內(nèi)容：
const modules = require.getModules();
const moduleIds = Object.keys(modules);
const loadedModuleNames = moduleIds
??.filter(moduleId => modules[moduleId].isInitialized)
??.map(moduleId => modules[moduleId].verboseName);
const waitingModuleNames = moduleIds
??.filter(moduleId => !modules[moduleId].isInitialized)
??.map(moduleId => modules[moduleId].verboseName);
// make sure that the modules you expect to be waiting are actually waiting
console.log(
??'loaded:',
??loadedModuleNames.length,
??'waiting:',
??waitingModuleNames.length
);
// grab this text blob, and put it in a file named packager/modulePaths.js
console.log(`module.exports = ${JSON.stringify(loadedModuleNames.sort())};`);
當(dāng)你運(yùn)行你的應(yīng)用程序時(shí)，你可以查看 console 控制臺，有多少模塊已經(jīng)加載，有多少模塊在等待。你可能想查看 moduleNames，看看是否有任何意外。注意在首次 import 時(shí)調(diào)用的內(nèi)聯(lián)引用。你可能需要檢查和重構(gòu)，以確保只有你想要的模塊在啟動(dòng)時(shí)加載。請注意，您可以根據(jù)需要修改 Systrace 對象，以幫助調(diào)試有問題的引用。
require.Systrace.beginEvent = (message) => {
??if(message.includes(problematicModule)) {
????throw new Error();
??}
}
雖然每個(gè) App 各有不同，但只加載第一個(gè)頁面所需的模塊是有普適意義的。當(dāng)你滿意時(shí)，把 loadedModuleNames 的輸出放到 packager/modulePaths.js 文件中。
更新配置文件
Returning to packager/config.js we should update it to use our newly generated modulePaths.js file.
const modulePaths = require('./modulePaths');
const resolve = require('path').resolve;
const fs = require('fs');
// Update the following line if the root folder of your app is somewhere else.
const ROOT_FOLDER = path.resolve(__dirname, '..');
const config = {
??transformer: {
????getTransformOptions: () => {
??????const moduleMap = {};
??????modulePaths.forEach(path => {
????????if (fs.existsSync(path)) {
??????????moduleMap[resolve(path)] = true;
????????}
??????});
??????return {
????????preloadedModules: moduleMap,
????????transform: { inlineRequires: { blacklist: moduleMap } },
??????};
????},
??},
};
module.exports = config;
在啟用RAM格式之后，配置文件中的preloadedModules條目指示哪些模塊需要預(yù)加載。當(dāng) bundle 被加載時(shí)，這些模塊立即被加載，甚至在任何 requires 執(zhí)行之前。blacklist 表明這些模塊不應(yīng)該被要求內(nèi)聯(lián)引用，因?yàn)樗鼈兪穷A(yù)加載的，所以使用內(nèi)聯(lián)沒有性能優(yōu)勢。實(shí)際上每次解析內(nèi)聯(lián)引用 JavaScript 都會(huì)花費(fèi)額外的時(shí)間。
測試和衡量改進(jìn)
您現(xiàn)在應(yīng)該準(zhǔn)備好使用RAM格式和內(nèi)聯(lián)引用來構(gòu)建您的應(yīng)用了。保存啟動(dòng)前后的時(shí)間，來測試下有多少改進(jìn)吧！
無狀態(tài)組件需使用 PureComponent 而不是 Component； 說明：無狀態(tài)組件是指內(nèi)部沒有使用 state 的組件，但是可以使用 props 來進(jìn)行某些屬性控制;
使用 InteractionManager.runAfterInteractions，在動(dòng)畫或者某些特定場景中利用 InteractionManager 來選擇性的渲染新場景所需的最小限度的內(nèi)容； 使用場景類似于：
class ExpensiveScene extends?React.Component{
????constructor(props, context) {
????????super(props, context);
????????this.state = { renderPlaceholderOnly: true };
????}
????componentDidMount() {
????????InteractionManager.runAfterInteractions(() => {
????????????this.setState({ renderPlaceholderOnly: false });
????????});
????}
????render() {
????????if (this.state.renderPlaceholderOnly) {
????????????return this.renderPlaceholderView();
????????}
????????return (
????????????<View>
????????????????<Text>Your full view goes here</Text>
????????????</View>
????????);
????}
????renderPlaceholderView() {
????????return (
????????????<View>
????????????????<Text>Loading...</Text>
????????????</View>
????????);
????}
}
使用新版本組件替換舊辦法組件； 例如：FlatList 替換 ListView，React Navigation 替換 Navigator 等
在使用 Touchable 系列組件時(shí)，進(jìn)行 setState 或者大量調(diào)幀操作，請使用如下方式
handleOnPress() {
????this.requestAnimationFrame(() => {
??????//todo
????});
??}
