建站
咨詢
售后
建站咨詢
新聞中心
在PhoneGap、RubyMotion、Xamarin、Ionic一眾跨平臺(tái)開發(fā)工具中，React Native能夠殺出一條血路，獲得目前這么大的影響力，除了React社區(qū)生態(tài)圈的加持和Facebook的大力推廣以外，另外一個(gè)最主要的原因就是其在開發(fā)效率和應(yīng)用性能方面取得了一個(gè)比較好的平衡：
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡(jiǎn)單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名申請(qǐng)、網(wǎng)絡(luò)空間、營銷軟件、網(wǎng)站建設(shè)、雨城網(wǎng)站維護(hù)、網(wǎng)站推廣。
- 開發(fā)效率通過JS工程實(shí)踐，邏輯跨平臺(tái)復(fù)用得到極大提升
- 性能則通過全Native的UI層得到滿足
不過，雖說框架提供了這個(gè)平衡能力，平衡點(diǎn)的選擇卻掌握在開發(fā)者手中，本文將從React Native的性能角度來看看應(yīng)該如何掌握這個(gè)平衡點(diǎn)。
一、React Native的工作原理
在React Native的應(yīng)用中，存在著兩個(gè)不同的技術(shù)王國：JS王國和Native王國。應(yīng)用在啟動(dòng)時(shí)會(huì)先進(jìn)行雙向注冊(cè)，搭好橋，讓兩個(gè)王國知道彼此的存在，以及定義好彼此合作的方式：
(圖片來源：http://t.cn/RXwes3j )
然后，在應(yīng)用的實(shí)際運(yùn)行過程中，兩個(gè)技術(shù)王國通過搭好的橋，彼此合作完成用戶功能：
(圖片來源：http://t.cn/R5xMqZ0)
因此，React Native的本質(zhì)是在兩個(gè)技術(shù)王國之間搭建雙向橋梁，讓他們可以相互調(diào)用和響應(yīng)。那么就可以把上圖簡(jiǎn)化一下：
二、React Native的性能瓶頸
經(jīng)過上面的分析，我們就可以把一個(gè)React Native應(yīng)用分成三個(gè)部分：Native王國、Bridge、JS王國。當(dāng)應(yīng)用運(yùn)行時(shí)，Native王國和JS王國各自運(yùn)行在自己獨(dú)立的線程中：
1. Native王國：
- 運(yùn)行在主線程上(可能會(huì)有些獨(dú)立的后臺(tái)線程處理運(yùn)算，當(dāng)前討論中可忽略)
- iOS平臺(tái)上運(yùn)行Object-C/Swift代碼，Android平臺(tái)上運(yùn)行Java/Kotlin代碼
- 負(fù)責(zé)處理UI的渲染，事件響應(yīng)。
2. JS王國：
- 運(yùn)行在JS引擎的JS線程上
- 運(yùn)行JS代碼
- 負(fù)責(zé)處理業(yè)務(wù)邏輯，還包括了應(yīng)該顯示哪個(gè)界面，以及如何給頁面加樣式。
在Native王國中，經(jīng)過谷歌、蘋果公司多年的優(yōu)化調(diào)整，Native代碼能夠非?？焖俚倪\(yùn)行在設(shè)備上。在JS王國中，JS代碼作為腳本語言，也能夠很快速的運(yùn)行在JS引擎上，這兩邊獨(dú)立來看都不會(huì)有性能問題。性能的瓶頸只會(huì)出現(xiàn)在從一個(gè)王國轉(zhuǎn)入另一個(gè)王國時(shí)，尤其是頻繁的在兩個(gè)王國之間切換時(shí)，兩個(gè)王國之間不能直接通信，只能通過Bridge做序列化和反序列化，查找模塊，調(diào)用模塊等各種邏輯，最終反應(yīng)到應(yīng)用上，就是UI層用戶可感知的卡頓。 因此，對(duì)React Native的性能控制就主要集中在如何盡量減少Bridge需要處理的邏輯上。
那么，什么情況下會(huì)需要Bridge處理邏輯呢?
- UI事件響應(yīng)： 所有的UI事件都發(fā)生在Native側(cè)，會(huì)以事件的形式傳遞到JS側(cè)。這個(gè)過程非常簡(jiǎn)單，也不會(huì)涉及大量的數(shù)據(jù)轉(zhuǎn)移。在React Native應(yīng)用中，業(yè)務(wù)邏輯，應(yīng)用狀態(tài)，數(shù)據(jù)都在JS側(cè)，所以UI事件只是一個(gè)觸發(fā)器，不會(huì)有性能問題。
- UI更新：前面已經(jīng)說過JS負(fù)責(zé)決定應(yīng)該展示哪個(gè)界面，以及如何樣式化界面，因此UI更新的發(fā)起方是JS側(cè)，更新時(shí)會(huì)向Native側(cè)同步大量的UI結(jié)構(gòu)和數(shù)據(jù)，這類更新經(jīng)常出現(xiàn)性能問題，尤其是在界面復(fù)雜、變動(dòng)數(shù)據(jù)大，或者做動(dòng)畫、變動(dòng)頻繁時(shí)。
- UI事件響應(yīng)和UI更新同時(shí)出現(xiàn)：在UI更新時(shí)，結(jié)構(gòu)變化不大，則性能問題不大;但是如果這時(shí)又有UI事件觸發(fā)JS側(cè)邏輯處理，而該邏輯處理又比較復(fù)雜，耗時(shí)較長(zhǎng)，導(dǎo)致JS側(cè)沒有時(shí)間片處理與Native側(cè)數(shù)據(jù)同步時(shí)，也會(huì)發(fā)生性能問題。
三、React Native的性能優(yōu)化措施
前面已經(jīng)解釋了React Native的性能瓶頸會(huì)在什么地方，React Native官方也知道這些，其在React Native中提供了一些性能優(yōu)化措施幫助開發(fā)者克服這些性能問題:
1. 框架自帶的React基于Virtual Dom的Diff算法保證了UI變動(dòng)時(shí)傳遞的只是變化的UI部分，盡量減少需要同步的數(shù)據(jù)。
2. 通過Direct Manipulation的方式直接在底層更新了Native組件的屬性，從而避免渲染組件結(jié)構(gòu)和同步太多視圖變化所帶來的大量開銷。這樣的確會(huì)帶來一定的性能提升，同時(shí)也會(huì)使代碼邏輯難以理清，而且并沒有解決從JS側(cè)到Native側(cè)的數(shù)據(jù)同步開銷問題。因此這個(gè)方式官方都不再推薦，更推薦的做法是合理使用setState()和shouldComponentUpdate()方法解決這類問題。
3. 在遇到動(dòng)畫性能問題時(shí)，可以使用Annimated類的庫，一次性把如何變化的聲明發(fā)送到Native側(cè)，Native側(cè)根據(jù)接收到的聲明自己負(fù)責(zé)接下來的UI更新。不需要每幀的UI變化都同步一次數(shù)據(jù)。
4. Native和JS混編，把會(huì)大量變化的組件做成Native組件，這樣UI的變更數(shù)據(jù)直接在Native側(cè)自己處理了，無需通過Bridge，而不變的內(nèi)部組件因?yàn)闆]有數(shù)據(jù)更新需要同步，所以也不會(huì)使用到Bridge。框架提供的NavigatorIOS相對(duì)于Navigator的性能提升就是這種做法。
5. 遇到事件響應(yīng)和UI更新同時(shí)發(fā)生導(dǎo)致的性能問題時(shí)，可以使用Interaction Manager把那些耗時(shí)較長(zhǎng)的工作安排到所有互動(dòng)或動(dòng)畫完成之后再進(jìn)行。
四、探求性能和效率平衡的套路
在了解了React Native的性能瓶頸和優(yōu)化措施之后，就可以大概總結(jié)一個(gè)探尋React Native開發(fā)效率和性能平衡點(diǎn)的套路：
***步: 全JS實(shí)現(xiàn)， 從一開始在技術(shù)選型上用React Native就是為了保證開發(fā)的效率，在沒有遇到性能問題之前，***化效率是團(tuán)隊(duì)的一致追求。
第二步: 從JS側(cè)進(jìn)行性能優(yōu)化
- 對(duì)于那些明顯會(huì)涉及Bridge、需大量處理邏輯的場(chǎng)景，比方說動(dòng)畫，復(fù)雜的手勢(shì)操作響應(yīng)等，嘗試使用經(jīng)過優(yōu)化過的庫(比方說：Animated)，一次傳遞動(dòng)畫或者數(shù)據(jù)整個(gè)數(shù)據(jù)的描述給Native，Native側(cè)自己會(huì)按照聲明執(zhí)行下去。
- 使用InteractionManager把耗時(shí)操作遞延到UI響應(yīng)之后，處理那些存在因?yàn)楹臅r(shí)的JS操作導(dǎo)致的UI響應(yīng)性能問題。
第三步：在真機(jī)上實(shí)測(cè)，檢查性能問題點(diǎn)。不要過早優(yōu)化，找到問題點(diǎn)再一一處理。
第四步：如果經(jīng)過JS端的優(yōu)化策略之后，在設(shè)備上還是有性能問題，可以把有問題的部分以Native方式實(shí)現(xiàn)，這也是為什么要推薦React Native團(tuán)隊(duì)中有10%左右的Native Developer。在這個(gè)步驟中，需要注意問題的隔離方式，假設(shè)一個(gè)場(chǎng)景：在移動(dòng)一個(gè)Container時(shí)，Container的UI同時(shí)發(fā)生變化，但是Container內(nèi)部的內(nèi)容并沒有發(fā)生變化，這種情況下，只需要用Native實(shí)現(xiàn)Container，Container內(nèi)部的組件還是以JS實(shí)現(xiàn)。
【本文是專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
網(wǎng)站名稱：ReactNative性能和效率平衡之謎
轉(zhuǎn)載注明：http://www.5511xx.com/article/ccocjge.html
