在PhoneGap、RubyMotion、Xamarin、Ionic一眾跨平臺開發(fā)工具中，React Native能夠殺出一條血路，獲得目前這么大的影響力，除了React社區(qū)生態(tài)圈的加持和Facebook的大力推廣以外，另外一個最主要的原因就是其在開發(fā)效率和應(yīng)用性能方面取得了一個比較好的平衡：

• 開發(fā)效率通過JS工程實踐，邏輯跨平臺復(fù)用得到極大提升
• 性能則通過全Native的UI層得到滿足

不過，雖說框架提供了這個平衡能力，平衡點的選擇卻掌握在開發(fā)者手中，本文將從React Native的性能角度來看看應(yīng)該如何掌握這個平衡點。

一、React Native的工作原理

在React Native的應(yīng)用中，存在著兩個不同的技術(shù)王國：JS王國和Native王國。應(yīng)用在啟動時會先進(jìn)行雙向注冊，搭好橋，讓兩個王國知道彼此的存在，以及定義好彼此合作的方式：

(圖片來源：http://t.cn/RXwes3j )

然后，在應(yīng)用的實際運行過程中，兩個技術(shù)王國通過搭好的橋，彼此合作完成用戶功能：

(圖片來源：http://t.cn/R5xMqZ0)

因此，React Native的本質(zhì)是在兩個技術(shù)王國之間搭建雙向橋梁，讓他們可以相互調(diào)用和響應(yīng)。那么就可以把上圖簡化一下：

二、React Native的性能瓶頸

經(jīng)過上面的分析，我們就可以把一個React Native應(yīng)用分成三個部分：Native王國、Bridge、JS王國。當(dāng)應(yīng)用運行時，Native王國和JS王國各自運行在自己獨立的線程中：

1. Native王國：

• 運行在主線程上(可能會有些獨立的后臺線程處理運算，當(dāng)前討論中可忽略)
• iOS平臺上運行Object-C/Swift代碼，Android平臺上運行Java/Kotlin代碼
• 負(fù)責(zé)處理UI的渲染，事件響應(yīng)。

2. JS王國：

• 運行在JS引擎的JS線程上
• 運行JS代碼
• 負(fù)責(zé)處理業(yè)務(wù)邏輯，還包括了應(yīng)該顯示哪個界面，以及如何給頁面加樣式。

在Native王國中，經(jīng)過谷歌、蘋果公司多年的優(yōu)化調(diào)整，Native代碼能夠非?？焖俚倪\行在設(shè)備上。在JS王國中，JS代碼作為腳本語言，也能夠很快速的運行在JS引擎上，這兩邊獨立來看都不會有性能問題。性能的瓶頸只會出現(xiàn)在從一個王國轉(zhuǎn)入另一個王國時，尤其是頻繁的在兩個王國之間切換時，兩個王國之間不能直接通信，只能通過Bridge做序列化和反序列化，查找模塊，調(diào)用模塊等各種邏輯，最終反應(yīng)到應(yīng)用上，就是UI層用戶可感知的卡頓。 因此，對React Native的性能控制就主要集中在如何盡量減少Bridge需要處理的邏輯上。

那么，什么情況下會需要Bridge處理邏輯呢?

• UI事件響應(yīng)： 所有的UI事件都發(fā)生在Native側(cè)，會以事件的形式傳遞到JS側(cè)。這個過程非常簡單，也不會涉及大量的數(shù)據(jù)轉(zhuǎn)移。在React Native應(yīng)用中，業(yè)務(wù)邏輯，應(yīng)用狀態(tài)，數(shù)據(jù)都在JS側(cè)，所以UI事件只是一個觸發(fā)器，不會有性能問題。

• UI更新：前面已經(jīng)說過JS負(fù)責(zé)決定應(yīng)該展示哪個界面，以及如何樣式化界面，因此UI更新的發(fā)起方是JS側(cè)，更新時會向Native側(cè)同步大量的UI結(jié)構(gòu)和數(shù)據(jù)，這類更新經(jīng)常出現(xiàn)性能問題，尤其是在界面復(fù)雜、變動數(shù)據(jù)大，或者做動畫、變動頻繁時。

• UI事件響應(yīng)和UI更新同時出現(xiàn)：在UI更新時，結(jié)構(gòu)變化不大，則性能問題不大;但是如果這時又有UI事件觸發(fā)JS側(cè)邏輯處理，而該邏輯處理又比較復(fù)雜，耗時較長，導(dǎo)致JS側(cè)沒有時間片處理與Native側(cè)數(shù)據(jù)同步時，也會發(fā)生性能問題。

三、React Native的性能優(yōu)化措施

前面已經(jīng)解釋了React Native的性能瓶頸會在什么地方，React Native官方也知道這些，其在React Native中提供了一些性能優(yōu)化措施幫助開發(fā)者克服這些性能問題:

1. 框架自帶的React基于Virtual Dom的Diff算法保證了UI變動時傳遞的只是變化的UI部分，盡量減少需要同步的數(shù)據(jù)。

2. 通過Direct Manipulation的方式直接在底層更新了Native組件的屬性，從而避免渲染組件結(jié)構(gòu)和同步太多視圖變化所帶來的大量開銷。這樣的確會帶來一定的性能提升，同時也會使代碼邏輯難以理清，而且并沒有解決從JS側(cè)到Native側(cè)的數(shù)據(jù)同步開銷問題。因此這個方式官方都不再推薦，更推薦的做法是合理使用setState()和shouldComponentUpdate()方法解決這類問題。

3. 在遇到動畫性能問題時，可以使用Annimated類的庫，一次性把如何變化的聲明發(fā)送到Native側(cè)，Native側(cè)根據(jù)接收到的聲明自己負(fù)責(zé)接下來的UI更新。不需要每幀的UI變化都同步一次數(shù)據(jù)。

4. Native和JS混編，把會大量變化的組件做成Native組件，這樣UI的變更數(shù)據(jù)直接在Native側(cè)自己處理了，無需通過Bridge，而不變的內(nèi)部組件因為沒有數(shù)據(jù)更新需要同步，所以也不會使用到Bridge。框架提供的NavigatorIOS相對于Navigator的性能提升就是這種做法。

5. 遇到事件響應(yīng)和UI更新同時發(fā)生導(dǎo)致的性能問題時，可以使用Interaction Manager把那些耗時較長的工作安排到所有互動或動畫完成之后再進(jìn)行。

四、探求性能和效率平衡的套路

在了解了React Native的性能瓶頸和優(yōu)化措施之后，就可以大概總結(jié)一個探尋React Native開發(fā)效率和性能平衡點的套路：

***步: 全JS實現(xiàn)， 從一開始在技術(shù)選型上用React Native就是為了保證開發(fā)的效率，在沒有遇到性能問題之前，***化效率是團隊的一致追求。

第二步: 從JS側(cè)進(jìn)行性能優(yōu)化

• 對于那些明顯會涉及Bridge、需大量處理邏輯的場景，比方說動畫，復(fù)雜的手勢操作響應(yīng)等，嘗試使用經(jīng)過優(yōu)化過的庫(比方說：Animated)，一次傳遞動畫或者數(shù)據(jù)整個數(shù)據(jù)的描述給Native，Native側(cè)自己會按照聲明執(zhí)行下去。
• 使用InteractionManager把耗時操作遞延到UI響應(yīng)之后，處理那些存在因為耗時的JS操作導(dǎo)致的UI響應(yīng)性能問題。

第三步：在真機上實測，檢查性能問題點。不要過早優(yōu)化，找到問題點再一一處理。

第四步：如果經(jīng)過JS端的優(yōu)化策略之后，在設(shè)備上還是有性能問題，可以把有問題的部分以Native方式實現(xiàn)，這也是為什么要推薦React Native團隊中有10%左右的Native Developer。在這個步驟中，需要注意問題的隔離方式，假設(shè)一個場景：在移動一個Container時，Container的UI同時發(fā)生變化，但是Container內(nèi)部的內(nèi)容并沒有發(fā)生變化，這種情況下，只需要用Native實現(xiàn)Container，Container內(nèi)部的組件還是以JS實現(xiàn)。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文