React Native

做者：雷志興-Berg
連接：https://www.zhihu.com/question/27852694/answer/41704172
來源：知乎
著做權歸做者全部，轉載請聯繫做者得到受權。

React native充分利用了Facebook的現有輪子，是一個很優秀的集成做品，而且我相信這個團隊對前端的瞭解很深入，不然不可能讓Native code「退居二線」。

對應到前端開發，整個系統結構是這樣：

• JSX vs HTML
• CSS-layout vs css
• ECMAScript 6 vs ECMAScript 5
• React native View vs DOM

1. 無需編譯，我在第一次編譯了ipa裝好之後，就再也沒更新過app，只要更新雲端的js代碼，reload一下，整個界面就全變了。
2. 多數佈局代碼都是JSX，全部Native組件都是標籤化的，這對於前端程序員來講，下降了很多學習成本，也大大減小了代碼量。不信你能夠看看JSX編譯後的代碼。
3. 複用React系統，也減小了必定學習和開發成本，更重要的是利用了React裏面的分層和diff機制。js層傳給Native層的是一個diff後的json，而後由Native將這個數據映射成真正的佈局視圖。
4. css-layout也是點睛之筆，前端能夠繼續用熟悉的類css方式來編寫佈局，經過這個工具轉換成constrain佈局。
5. 系統只有js-objc的單向調用，就是把原生UI組件的方法經過javascritcore或者webview（低版本iOS）映射到js中來，整個調用過程是異步的，這樣的設計令React native可讓js運行在桌面chrome中，經過websocket鏈接Native code和桌面chrome，極大地方便了調試。對其中的機制Bang的一篇文章寫得很詳細，我就不拾人牙慧了：React Native通訊機制詳解 « bang’s blog 。但這樣設計也會帶來一些問題，後面說。
6. 點按操做也被抽象成了一組組件（TouchableXXX），這種抽象方式是我在以前作相似工做中沒有想到的。facebook還列出Native爲何和web「手感」不一樣的緣由：實時的點按反饋和取消能力。React Native 這套相應機制設計得很完善，能像Native code那樣控制整個點按操做的全部過程。
7. Debug至關方便！修改了js之後，經過內建的nodejs watcher編譯成bundle，在模擬器裏面按cmd+r就能夠看到效果。並且按cmd+d，能夠打開一個chrome窗口，全部的js都移到了chrome裏面運行，因此什麼斷點單步打調用棧，都不在話下。

上面的既是特色也是優勢，下面說說缺點，或者應該說：「仍然遺留的問題」，在我看來，這個方案已經超越了Hybird方案。

1. 系統仍然（不得不）依賴原生組件暴露出來的組件和方法。舉兩個例子，ScrollView這個組件，在Native層是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，這些事件在現有的版本都沒有暴露，基本上作不了組件聯動效果。另外，這個版本中有大量組件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反過來看，剩餘的都是一些抽象程度極強的基本組件。這樣，用戶必須在不一樣的平臺下寫兩套代碼，並且全部能力仍然強烈依賴 React native 開發人員暴露的接口。
2. 因爲最外層是React，初次學習成本高，不像往常的Hybird方案，只要多學幾個JS API就能夠開始幹活了。固然，React的確讓後續開發變得簡單了一些，這麼一套外來的（基於iOS）、殘缺不全的（css-layout）在React的包裝下，的確顯得不那麼面目可憎了。

另外，React Native仍然很不完善。文檔還不全，我基本上是看着他的示例代碼完成的demo，集成到已有app的文檔也是今天才出來。按照官方的說法，Android版本要到半年後才發佈：Blog | React ，屆時整個系統設計可能還會有很大的變化