對應到前端開發，整個系統結構是這樣：
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通信機制詳解 ? 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是用的
JavascriptCore。
2. 再說React Native的核心，iOS Native code提供了十來個最基本核心的類（RCTDeviceEventEmitter、
RCTRenderingPerf等）、或組件（RCTView、RCTTextField、RCTTextView、
RCTModalFullscreenView等），然後由React Native的JS部分，組成二十來個基本組件（Popover、Listview等），交由上層的業務方來使用（THGroupView）。
3. 就如他們在宣傳時所說，他們實現了壹套類似css的子集，用來解決樣式問題，相當復雜和強大，靠這個才能將Native的核心組件組成JS層的基本組件再組成業務端的業務組件，應該是采用facebook/css-layout · GitHub的C語言版本實現的（在ppt中我們看到了類似flex-direction: column壹類的代碼，這個正是css-layout支持的語法）。
4. 在React Native中，寫JS的工程師解決的是「將基本組件拼裝成可用的React組件」的問題，寫Native Code的工程師解決的是「提供核心組件，提供足夠的擴展性、靈活性和性能」的問題。
React Native的設計考慮：
ReactJS對React Native有著直接的影響（我沒在生產環境中用過React，只看過代碼&用過Angular，如果有誤請指出）
ReactJS裏面有這樣的設計：
1. ReactJS 的大工廠入口createElement返回的不是某個實體DOM對象，而只是壹個數組
2. 通過源碼中 ui/browser/ 目錄中的代碼，將這個數組轉換成DOM
3. 底層的渲染核心是可以更換的
另外，Facebook自己有JSX，css-layout等開源項目，基於這些，如果要做壹個用 JS來開發Native app的東西，很自然就想到了壹套最有效率的搞法：
1. 將 ui/browser 裏面的代碼替換成壹套 Native 的橋接JS（實際上，iOS版是通過
injectGenericComponentClass方法，將核心組件的方法註入到JS裏面 ），就直接復用React的MVVM，自動將數據映射到Native了
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. 有較強的擴展性，這是因為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通過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: 補充了幾條優勢和與前端開發的對照