00關系理解
這個是我對RN和原生關系的理解。簡單解釋下這個圖。
RN js編寫完業(yè)務代碼后，通過react-native bundle命令，將代碼分別編譯成一個index.ios.bundle和index.android.bundle文件，當然還是資源文件。然后放到Android、iOS的原生工程里，通過黃色說明塊里的示例代碼，將js寫的所有邏輯業(yè)務讀成一個View來展示在原生里，當然這個View需要Activity/Fragment/ViewController來承載。然后原生App打開相應承載的頁面就可以看到RN寫的業(yè)務了。所以，正常情況下，對于原生來說，所有的RN頁面都是在一個原生頁面里的。
頂部還有有個node_modules，它其實在工程里是一個文件夾，里面存放了所有的js，Android，iOS都需要的一個共同類庫以及源碼，所有的通信、組件都在這個里面。所以，三個工程里都需要讀這個文件夾里的東西，但是我們不用關心具體，這個是由npm來自動下載的。只需要安裝文檔提示配置好這個文件夾的路徑就ok了。
01性能問題
這里，我的理解是，性能一定不如純原生寫的。
關于RN寫出來的應用的性能問題其實一直都是所有開發(fā)人員所關心的問題。RN一直說的是全都是調用的是原生的控件，所以理論上和原生寫的App是不存在性能差異的。
原生封裝的控件，在RN這邊以組件的方式來使用。我有一篇文章以WebView為例講述了一下原生控件和RN組件的關系(React Native Android從源碼看WebView 沒有OverrideUrl解決辦法，以及高度自適應)。用RN調用的所有組件的屬性參數(shù)都是經(jīng)過了js到java/objective-c/swift的轉換后，才最終渲染成原生封裝的控件。而控件在運行中的事件回調也是經(jīng)過了語言通信，才將信息回調給js。我對語言通信這一塊的性能耗時不太了解，但是應該可以肯定的是，本來直接就可以完成的事情，經(jīng)過了語言轉換，肯定是有損耗的。只是Facebook把這個性能做了很大的優(yōu)化，再加上現(xiàn)在手機硬件的性能越來越強大，所以，在大部分手機上這個損耗可以忽略。
02我認為的缺點
能做的事情不如原生靈活。我前面說過，
RN用的組件雖然是原生控件，但是是經(jīng)過原生封裝過的控件，有一定的局限性。為了做到跨平臺，他并沒有把原生該控件的所有屬性參數(shù)回調都暴露給js端。坑會比原生開發(fā)更多。原生開發(fā)，特別是
Android有很多適配問題要考慮，這些大部分都是經(jīng)驗才能解決的坑，facebook開發(fā)人員在封裝控件的時候如果沒遇到過相關的坑，可能會解決的不徹底，而js那邊如果不了解原生的話，可能不能完全明白問題出在哪了。所以，原生會遇到的坑，如果facebook沒解決，理論上RN都會遇到。技術棧會要求更高。這個是肯定的，最好是
Android/iOS都要有點了解，這樣寫出來的應用才會更健壯。設計js與原生通信的方案通用性才會更強。問題的排查也會更準確。
03我理解的優(yōu)點
最后我才來說優(yōu)點，是因為雖然有前面的確定，但這個技術本身肯定是值得學習和發(fā)揚的。
js與原生的通信機制比較完善。注意我說的是比較完善，實際編碼過程中還是有很多不如意的地方。但是滿足絕大部分業(yè)務需求是沒問題的。
可以支持自定義原生控件給RN用。前面我說到，原生封裝的控件如果不能滿足你的業(yè)務需求，你可以自己封裝控件，并選擇性的暴露接口給
RN用，當然這個適用于較為復雜的業(yè)務需求，如果大部分都控件都需要重新封裝，還不如直接就原生寫了。支持熱更新。這無疑是比較重要的一個優(yōu)點了，開始我就提到，對于原生了來說，重要的是
js編譯的bundle文件，而熱更新的方案也就可以從這點入手。將bundle文件和資源文件打成包，當成一個普通的文件下載，然后讓原生指定讀取路徑就可以了。當然這個需要原生支持。跨平臺。這也是一個非常重要的有點了。但是打包
iOS，還是需要必須的硬件配置，比如mac電腦。可以讓更多的前端開發(fā)人員來寫App。
04
至此！
感謝閱讀！
