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

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

JSX vs HTML

CSS-layout vs css

ECMAScript 6 vs ECMAScript 5

React native View vs DOM

無需編譯，我在第一次編譯了ipa裝好以后，就再也沒更新過app，只要更新云端的js代碼，reload一下，整個界面就全變了。

多數布局代碼都是JSX，所有Native組件都是標簽化的，這對于前端程序員來說，降低了不少學習成本，也大大減少了代碼量。不信你可以看看JSX編譯后的代碼。

復用React系統，也減少了一定學習和開發成本，更重要的是利用了React里面的分層和diff機制。js層傳給Native層的是一個diff后的json，然后由Native將這個數據映射成真正的布局視圖。

css-layout也是點睛之筆，前端可以繼續用熟悉的類css方式來編寫布局，通過這個工具轉換成constrain布局。

系統只有js-objc的單向調用，就是把原生UI組件的方法通過javascritcore或者webview（低版本iOS）映射到js中來，整個調用過程是異步的，這樣的設計令React native可以讓js運行在桌面chrome中，通過websocket連接Native code和桌面chrome，極大地方便了調試。對其中的機制Bang的一篇文章寫得很詳細，我就不拾人牙慧了：React Native通信機制詳解 laquo;  bang’s blog 。但這樣設計也會帶來一些問題，后面說。

點按操作也被抽象成了一組組件（TouchableXXX），這種抽象方式是我在之前做類似工作中沒有想到的。facebook還列出Native為什么和web「手感」不同的原因：實時的點按反饋和取消能力。React Native 這套相應機制設計得很完善，能像Native code那樣控制整個點按操作的所有過程。

Debug相當方便！修改了js以后，通過內建的nodejs watcher編譯成bundle，在模擬器里面按cmd+r就可以看到效果。而且按cmd+d，可以打開一個chrome窗口，所有的js都移到了chrome里面運行，所以什么斷點單步打調用棧，都不在話下。

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

系統仍然（不得不）依賴原生組件暴露出來的組件和方法。舉兩個例子，ScrollView這個組件，在Native層是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，這些事件在現有的版本都沒有暴露，基本上做不了組件聯動效果。另外，這個版本中有大量組件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反過來看，剩余的都是一些抽象程度極強的基本組件。這樣，用戶必須在不同的下寫兩套代碼，而且所有能力仍然強烈依賴 React native 開發人員暴露的接口。

由于最外層是React，初次學習成本高，不像往常的Hybird方案，只要多學幾個JS API就可以開始干活了。當然，React的確讓后續開發變得簡單了一些，這么一套外來的（基于iOS）、殘缺不全的（css-layout）在React的包裝下，的確顯得不那么面目可憎了。

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

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

<TabBarItemIOS

name="blueTab"

icon={_ix_DEPRECATED('favorites')}

.>

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

以上。

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

------------------------簡單粗暴的分割線--------------------

背景和調研手段

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

React Native的核心實現：

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

1. React Native里面沒有webview，這貨不是Hybrid app，里面執行JS是用的

2. JavascriptCore。

3. 2. 再說React Native的核心，iOS Native code提供了十來個最基本核心的類（RCTDeviceEventEmitter、RCTRenderingPerf等）、或組件（RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等），然后由React Native的JS部分，組成二十來個基本組件（Popover、Listview等），交由上層的業務方來使用（THGroupView）。

4. 3. 就如他們在宣傳時所說，他們實現了一套類似css的子集，用來解決樣式問題，相當復雜和強大，靠這個才能將Native的核心組件組成JS層的基本組件再組成業務端的業務組件，應該是采用facebook/css-layout · GitHub的C語言版本實現的（在ppt中我們看到了類似flex-direction: column一類的代碼，這個正是css-layout支持的語法）。

5. 4. 在React Native中，寫JS的工程師解決的是「將基本組件拼裝成可用的React組件」的問題，寫Native Code的工程師解決的是「提供核心組件，提供足夠的擴展性、靈活性和性能」的問題。

React Native的設計考慮：

ReactJS對React Native有著直接的影響（我沒在生產環境中用過React，只看過代碼用過Angular，如果有誤請指出）

ReactJS里面有這樣的設計：

1. ReactJS 的大工廠入口createElement返回的不是某個實體DOM對象，而只是一個數組

2. 2. 通過源碼中 ui/browser/ 目錄中的代碼，將這個數組轉換成DOM

3. 3. 底層的渲染核心是可以更換的

另外，Facebook自己有JSX，css-layout等開源項目，基于這些，如果要做一個用 JS來開發Native app的東西，很自然就想到了一套最有效率的搞法：

1. 將 ui/browser 里面的代碼替換成一套 Native 的橋接JS（實際上，iOS版是通過

2. injectGenericComponentClass方法，將核心組件的方法注入到JS里面 ），就直接復用React的MVVM，自動將數據映射到Native了

3. 2. Native code里面實現三組核心API，一組提供核心組件的API（create、update、delete），一組事件方法（ReactJS里面的EventEmitter ），一組對css進行解析（css-layout）以及返回Style的ComputedStyle（React Native里面叫meatureStyle）。

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

那，React Native是什么看

其實這東西從Native開發來說，相當于重新發明了一個瀏覽器渲染引擎并且套一個React的殼，從Web開發角度來說，就是把原來React的后端換成了Native code來實現，就跟Flipboard最近搞的React Canvas 一樣： Flipboard · GitHubreact-canvas

React Native的優勢和劣勢：：

優勢相對Hybird app或者Webapp：

1. 不用Webview，徹底擺脫了Webview讓人不爽的交互和性能問題

2. 2. 有較強的擴展性，這是因為Native端提供的是基本控件，JS可以自由組合使用

3. 3. 可以直接使用Native原生的「」動畫（在FB Group這個app里面，面板滑出帶一點果凍彈動，面板基于某個點展開這種動畫隨處可見，這種動畫用Native code來做小菜一碟，但是用Web來做就難上加難）。

優勢相對于Native app：

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

劣勢：

1. 擴展性仍然遠遠不如web，也遠遠不如直接寫Native code（這個不用廢話解釋了吧）

2. 2. 從Native到Web，要做很多概念轉換，勢必造成雙方都要妥協。比如web要用一套CSS的閹割版，Native通過css-layout拿到最終樣式再轉換成native原生的表達方式（比如iOS的Constraint\origin\Center等屬性），再比如動畫。另外，若Android和iOS都要做相同的封裝，概念轉換就更復雜了。

更新1：添加了React對React Native的影響。

更新2：基本確定其使用了 css-layout，添加了對React Native的總結

更新3: React native已經開源了： React Native，只有iOS版。我寫了幾個demo，簡單看了看objc代碼并和開源前的我們的一些結論（見后文）交叉驗證。簡單地從前端工程師和系統整體角度說一下React native的特點和優劣吧。

更新4: 補充了幾條優勢和與前端開發的對照