我對 React Native 的理解和看法

React native出來也快一周了，我寫了幾個demo，簡單看了看objc代碼并和開源前的我們的一些結論（見后文）交叉驗證。簡單地從前端工程師和系統整體角度說一下React native的特點和優劣吧。

react native充分利用了非死book的現有輪子，是一個很優秀的集成作品，并且我相信這個團隊對前端的了解很深刻，否則不可能讓Native code「退居二線」。

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

• JSX vs HTML
• CSS-layout vs css
• ECMAScript 6 vs ECMAScript 5
• React native View vs DOM
</ul>

---

1. 無需編譯，我在第一次編譯了ipa裝好以后，就再也沒更新過app，只要更新云端的js代碼，reload一下，整個界面就全變了。
2. 多數布局代碼都是JSX，所有Native組件都是標簽化的XML，這對于前端程序員來說，降低了不少學習成本，也大大減少了代碼量，不信你可以看看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的一篇文章寫得很詳細，我就不拾人牙慧了：http://blog.cnbang.net/tech/2698/ 。但這樣設計也會帶來一些問題，后面說。
6. 點按操作也被抽象成了一組組件（TouchableXXX），這種抽象方式是我在之前做類似工作中沒有想到的。非死book還列出Native為什么和web「手感」不同的原因：實時的點按反饋和取消能力。http://非死book.github.io/react-native/docs/gesture-responder-system.html#content 這套相應機制設計得很完善，能像Native code那樣控制整個點按操作的所有過程。
7. Debug相當方便！修改了js以后，通過內建的nodejs watcher編譯成bundle，在模擬器里面按cmd+r就可以看到效果。而且按cmd+d，可以打開一個chrome窗口，所有的js都移到了 chrome里面運行，所以什么斷點單步打調用棧，都不在話下。
</ol>

上面的既是特點也是優點，下面說說缺點，或者應該說：「仍然遺留的問題」，在我看來，這個方案已經超越了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的包裝下，的確顯得不那么面目可憎了。
</ol>

另外，React Native仍然很不完善。文檔還不全，我基本上是看著他的示例代碼完成的demo，集成到已有app的文檔也是今天才出來。按照官方的說法，Android版本要到半年后才發布： http://非死book.github.io/react/blog/#when-is-react-native-android-coming ，屆時整個系統設計可能還會有很大的變化。

PS，在使用Tabbar的時候，我驚喜的發現他們居然用了iconfont方案，我現在手頭的項目中也有同樣的實現，不過API怎么設計一直很頭疼。結果，我發現他是這么寫的：

<TabBarItemIOS name="blueTab" icon={_ix_DEPRECATED('favorites')}
....>

在_ix_DEPRECATED的定義處，有一句注釋：// TODO(nicklockwood): How can this fit our require system?

HOW?

以上。

下面是一周前，在React native還沒開源的時候，通過反解ipa的一些分析過程，有興趣的可以看看。

---

背景和調研手段

React Native還沒開源，最近和組里兄弟反編譯了非死book Group（這個應用是用React Native實現的）的ipa代碼，出來幾百個JS文件，格式化一下，花了幾天時間讀了一下源碼，對React Native的內部核心機制算是有了一個基本了解。

React Native的核心實現：

先簡單說幾點，詳細的等回頭更新。

1. React Native里面沒有webview，這貨**不是Hybrid app**。
2. 再說React Native的核心，iOS Native code提供了十來個最核心的類（RCTDeviceEventEmitter、RCTRenderingPerf等）、或組件（RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等），然后由React Native的JS部分，組成二十來個基本組件（Popover、Listview等），交由上層的業務方來使用（THGroupView）。
3. 就如他們在宣傳時所說，他們實現了一套類似css的子集，用來解決樣式問題，相當復雜和強大，靠這個才能將Native的核心組件組成JS層的基本組件再組成業務端的業務組件，個人猜測是采用CSSLayout的C語言版本實現的。
4. 在React Native中，寫JS的工程師解決的是「將基本組件拼裝成可用的React組件」的問題，寫Native Code的工程師解決的是「提供核心組件，提供足夠的擴展性、靈活性和性能」的問題。
</ol>

React Native的設計考慮：

ReactJS對React Native有著直接的影響（我沒真正在生產環境中用過React，只用過Angular，下面的觀點可能有偏差）

ReactJS是這么設計的：


1. ReactJS 通過createElement返回的不是某個實體DOM對象，而只是一個數組
   
2. 通過源碼中 ui/browser/ 目錄中的代碼，將這個數組轉換成DOM </p>

   另外，非死book自己有JSX，CSSLayout等開源項目（自己去github上找介紹吧）

   有了React再考慮React Native，很自然就想到了一套最有效率的搞法：
   

3. 將 ui/browser 里面的代碼替換成一套 Native 的橋接JS（實際上，iOS版是通過
   injectGenericComponentClass方法，將核心組件的方法注入到JS里面 ），不就用上React的MVVM，自動將數據映射到Native了么
   
4. Native code里面實現三組核心API，一組提供核心組件的API（create、update、delete），一組事件方法（ReactJS里面的 EventEmitter ），一組對Style進行解析（貌似是用的CSSLayout的C語言版本）以及返回Style的ComputedStyle（React Native里面叫meatureStyle） </p>

   這樣，用上了ReactJS本身的所有核心功能和設計思路，Native的開發也足夠簡單。

   React Native的優勢和劣勢：（非最終結論，可能會更新）：

   React Native的優勢：
   相對Hybird app或者Webapp：

   1. 不用Webview，徹底擺脫了Webview讓人不爽的交互和性能問題
   2. 有較強的擴展性，這是因為Native端提供的是基本控件，JS可以自由組合使用
   3. 可以直接使用Native原生的「牛逼」動畫（在FB Group這個app里面，面板滑出帶一點果凍彈動，面板基于某個點展開這種動畫隨處可見，這種動畫用Native code來做小菜一碟，但是用Web來做就難上加難）。

   相對于Native app：

   1. 可以通過更新遠端JS，直接更新app，不過這快成為各家大型Native app的標配了…

   劣勢：

   1. 擴展性仍然遠遠不如web，也遠遠不如直接寫Native code（這個不用廢話解釋了吧）
   2. 從Native到Web，要做很多概念轉換，勢必造成雙方都要妥協。最終web要用一套CSS的閹割版，Native要費勁地把這個閹割版轉換成native原生的表達方式（比如iOS的Constraint\origin\Center等屬性），兩邊都會不爽。
   </div> 來自：http://div.io/topic/851