React Native與原生關係理解與對比

##00關係理解

這個是我對RN和原生關係的理解。簡單解釋下這個圖。

RN js編寫完業務代碼後，經過react-native bundle命令，將代碼分別編譯成一個index.ios.bundle和index.android.bundle文件，固然仍是資源文件。而後放到Android、iOS的原生工程裏，經過黃色說明塊裏的示例代碼，將js寫的全部邏輯業務讀成一個View來展現在原生裏，固然這個View須要Activity/Fragment/ViewController來承載。而後原生App打開相應承載的頁面就能夠看到RN寫的業務了。因此，正常狀況下，對於原生來講，全部的RN頁面都是在一個原生頁面裏的。

頂部還有有個node_modules，它其實在工程裏是一個文件夾，裏面存放了全部的js，Android，iOS都須要的一個共同類庫以及源碼，全部的通訊、組件都在這個裏面。因此，三個工程裏都須要讀這個文件夾裏的東西，可是咱們不用關心具體，這個是由npm來自動下載的。只須要安裝文檔提示配置好這個文件夾的路徑就ok了。

01性能問題

這裏，個人理解是，性能必定不如純原生寫的。

關於RN寫出來的應用的性能問題其實一直都是全部開發人員所關心的問題。RN一直說的是全都是調用的是原生的控件，因此理論上和原生寫的App是不存在性能差別的。

原生封裝的控件，在RN這邊以組件的方式來使用。我有一篇文章以WebView爲例講述了一下原生控件和RN組件的關係(React Native Android從源碼看WebView 沒有OverrideUrl解決辦法，以及高度自適應)。用RN調用的全部組件的屬性參數都是通過了js到java/objective-c/swift的轉換後，才最終渲染成原生封裝的控件。而控件在運行中的事件回調也是通過了語言通訊，纔將信息回調給js。我對語言通訊這一塊的性能耗時不太瞭解，可是應該能夠確定的是，原本直接就能夠完成的事情，通過了語言轉換，確定是有損耗的。只是Facebook把這個性能作了很大的優化，再加上如今手機硬件的性能愈來愈強大，因此，在大部分手機上這個損耗能夠忽略。

02我認爲的缺點

• **能作的事情不如原生靈活。**我前面說過，RN用的組件雖然是原生控件，可是是通過原生封裝過的控件，有必定的侷限性。爲了作到跨平臺，他並無把原生該控件的全部屬性參數回調都暴露給js端。

• **坑會比原生開發更多。**原生開發，特別是Android有不少適配問題要考慮，這些大部分都是經驗才能解決的坑，facebook開發人員在封裝控件的時候若是沒遇到過相關的坑，可能會解決的不完全，而js那邊若是不瞭解原生的話，可能不能徹底明白問題出在哪了。因此，原生會遇到的坑，若是facebook沒解決，理論上RN都會遇到。

• **技術棧會要求更高。**這個是確定的，最好是Android/iOS都要有點了解，這樣寫出來的應用纔會更健壯。設計js與原生通訊的方案通用性纔會更強。問題的排查也會更準確。

03我理解的優勢

最後我纔來講優勢，是由於雖然有前面的肯定，但這個技術自己確定是值得學習和發揚的。

• **js與原生的通訊機制比較完善。**注意我說的是比較完善，實際編碼過程當中仍是有不少不如意的地方。可是知足絕大部分業務需求是沒問題的。

• **能夠支持自定義原生控件給RN用。**前面我說到，原生封裝的控件若是不能知足你的業務需求，你能夠本身封裝控件，並選擇性的暴露接口給RN用，固然這個適用於較爲複雜的業務需求，若是大部分都控件都須要從新封裝，還不如直接就原生寫了。

• **支持熱更新。**這無疑是比較重要的一個優勢了，開始我就提到，對於原生了來講，重要的是js編譯的bundle文件，而熱更新的方案也就能夠從這點入手。將bundle文件和資源文件打成包，當成一個普通的文件下載，而後讓原生指定讀取路徑就能夠了。固然這個須要原生支持。

• **跨平臺。**這也是一個很是重要的有點了。可是打包iOS，仍是須要必須的硬件配置，好比mac電腦。

• 可讓更多的前端開發人員來寫App。

04

至此！ 感謝閱讀！