如何評價 React Native Android?

01-06

我是個 iOS 開發，這兩天玩了一下 android，感覺很棒，我們團隊目前沒有 android 開發，認真考慮換到 react-native 中。

react 本身

首先我想說說 react。react 本身對我的衝擊很大，不說 facebook 把這個庫推廣的怎麼樣，這是一個思想上的勝利。

過往寫 UI 最痛苦的事情在於維護狀態，比如一個 boolean 和一個 checkbox 要做到狀態統一，那麼你就一直在關心他們是不是統一，任何用戶操作改變了 checkbox 的狀態，觸發的 event 里要修改那個 boolean，任何數據操作了這個 boolean，也要去改 checkbox。更不要說數據更複雜，狀態更多的時候了。

react 解決了這個問題。他借鑒了遊戲 update -&> render 的思想，讓數據改動和 UI 繪製成為了單向的一個操作。每次 checkbox 的狀態，都是在重繪的時候根據 boolean 的值重新畫的。

那麼問題來了，60fps 的遊戲，一秒里畫面就被 render 了 60 次，而顯示中（比如 iOS）的 UI 是不可能不斷 `removeSubview` `addSubview` 的。於是 react 的做法是引入了一個中間層，叫 virtual DOM。boolean 變化後，重新 render 的是這個 virtual DOM，它本質上是一個 object。react 庫來維護這個 object 和實際界面（也就是例子里的 checkbox）的一致。這個 virtual DOM，會在變化後作一個 diff，只有當改變的部分才會影響界面上實際的 checkbox。如果操作很頻繁，還有 batch update 來「降低幀數」。

然而正因為有了這個中間層，那麼 virtual DOM 下面的表現形式就無所謂了。他可以是傳統意義上的 DOM，也可以是 iOS 的各種 UIControl UIView，也可以是 android 的 native 控制項，甚至是 webkit 內核本身？（我司 CTO @郭達峰在 react-europe 上甚至見到了有人直接做了一個命令行的表現層。）

於是 react 就被意料之外、情理之中的 port 到了 native app 的開發領域。

------

react-native for iOS

react-native，下面簡稱 RN，剛出來的時候，我玩了一下。我司有個面試題，一個小 hangman 的遊戲（joycehan/strikingly-interview-test-instructions at new · GitHub）。我試著用 RN 寫了一個簡單的實現（Arthraim/HangmanReact · GitHub），還是比較簡單的，尤其在維護狀態上的思想，真的是太先進，寫代碼變得容易很多。

第一步，根據 state 和 props 畫界面。（比如 someUISwitch.on = someBoolean）

第二步，用戶在界面上產生的操作，在各個 event 里修改 state。一旦你更新了 state，RN 就乖乖根據第一步把界面也改到正確的狀態了。

RN 最大弊病在於技術棧對 iOS 工程師來說差距太大，權且不說 iOS 工程師本身會不會寫個簡單的網頁，嶄新的 ES6，JSX 的學習曲線，也是夠陡的，如果還要加上理解 babel, webpack 等等工具，對 iOS 開發，比如我，來說，要學的東西真的太多。對 web 前端的同學來說，那個什麼，咳咳，iOS 也是很難學的說。

一大好處是，app 的更新變得方便了，不需要考慮 lua 或者其他的方案，至少某種程度上熱補丁變得簡單很多。（也已經有人跟上做了個平台了呢 ?_? https://apphub.io/）

------

react-native for android

這次 RN-android，出來之後，我按照文檔配置了一下環境。我本身不是 android 開發，對 android 具體怎麼實現它就不清楚了。

我試著把之前 iOS 的那個 demo 給改到 android 來，我發現其實我只做了三件事。

1. 我在原來的項目里執行 react-native android。項目自動加上了 android 的支持。

2. 我把項目里原來主界面的 component，game_ui.ios.js 的文件名改成了 game_ui.js

3. 把 index.android.js 幾乎和 index.ios.js 寫的一模一樣，直接 render 了 GameUI 這個 component。

於是整個 demo 完完整整的在 android 上跑起來了。也就是說，原來 iOS 的代碼真的是一行未改，這雖然不是 RN 的賣點（人家不說自己 code once run everywhere 的），但這個副作用夠誘人，當即我給 CTO 發了 android position 的 application 啊＝。＝

考慮到系統差異，實踐起來用 react 大一統三個端的話，要不就讓 component 自己知道怎麼分別繪製三個端。要不就是三個端各自維護一個自己的 component。還沒有這麼深入的實踐，未來看看有沒有更深的感悟吧。

------

最後我想說，web 前端世界真是日新月異。有人打趣到，「RN 是前端世界對你們 iOS 開發圈的侵略啊，你們應該抵制才對」。我個人倒是被這種日新月異大大的折服，彷彿 iOS 開發本身都好像顯得落後了。擁抱變化。話說如果 react 有個 swift 的實現，我估計會更開心啊。

------

再啰嗦一個題外話，雖然 react 只解決了 view 的問題，但 facebook 其實提出了 flux 來解決 model 和 controller 存在的問題。針對客戶端開發，它還提出了 GraphQL 來解決 flux 里的 store 和傳統關係型資料庫里 model 之間的矛盾。思想太先進，讓我慢慢跟上。

打個小廣告，Strikingly 現在是這套思想的踐行者，我們整個 web 端已經用 react 重寫了一遍。如果你是個前端，歡迎來開發 android 和 iOS，我們也常年招收各種其他職位（Careers at Strikingly），歡迎來戰！

2015-09-29 更新：What does Apple think of React Native?

2016-09-28 更新：答了一年了…… 我來更新下，我們真的切到 RN 了……

我們 4 個人，一個前端，一個 iOS，一個 android和一個 CTO。花了 3 個月左右的時間，用 React Native 寫了個 app，android 還在最後的 QA 階段，iOS 已經上線了：apple.com 的頁面

今年「寧js」上，dafeng 也就這個經歷做了一次分享：NingJS - JSConf China 2016 （9月23日下午1小時58分處開始）

2016-11-03 更新：不好意思我又來強行廣告一波。我們的 Android 經過了漫長的 QA 終於上架了：應用詳情

更新一下，過了好久了，終於把ReactNative中Js和Native的通訊機制，源碼分析寫完了，感興趣的可以去我的專欄看ReactNativeAndroid源碼分析-Js如何調用Native的代碼 - 程序人生 - 知乎專欄，建議電腦上看，代碼有點多，知乎APP看代碼實在不方便。

======

連夜看了代碼。

主要是在layout中放了個ReactRootView作為根容器，負責分發事件。事件由dispatcher分發給js。調用js是通過JavaScriptCore來實現的。

Js和Java層通訊這一塊，機制其實和微信的JsBridge是一致的，也是目前頁面比較常用的一種方法。通過在Js中維持一個queue來保存module id， method id和參數，JNI層，cpp調用JSC的函數，其實是通過這個queue來獲取函數的調用結果的，cpp層解析完返回的queue之後，會去回調Java層傳遞來的Callback對象，從而實現Js和Java通訊。

先說這麼多，詳細代碼分析以後寫博客吧。

另外，真的能看到js一統大前端了。以後就是web和app用React，伺服器用Node.js，至少組建團隊方便應該是方便了很多。

三駕馬車的最後一駕。

很多人對於ReactNative持觀望狀態因為Android遲遲未出，現在終於出了，應該會有很多小公司開始全面投向React陣營了。

從數據上來看，Facebook宣稱在iOS和Android之間實現了85%的代碼重用。這一點對於小公司來說，吸引力是很大的吧。不過，我是不太指望大公司重新用ReactNative重寫現有的應用。

如果讓我從零開始創業，應該會用Express + React + React Native iOS + React Native Android。這樣子前十個程序員都只要主力寫JavaScript，附帶著寫些其他的語言就可以了。就像是戰爭的時候的機動部隊，如果用這一套，所有的程序員都是機動部隊，想攻堅什麼能把所有的人力都投入。

RN 不是JS工程師可以輕鬆搞定的，

當然不是native工程師可以輕鬆搞定的。

RN是思想的聚合品

即便js統一大前端，甚至UWP，甚至VR和遊戲……

和現在的js工程師也沒有關係

世界是優秀工程師的

優秀的工程師，只不過是不停選擇對的，放棄錯的

還沒實際上手，從文檔得到一些主觀感受：

跟iOS那套基本一致。但是開發體驗可能不如for iOS。

設置步驟比iOS那套複雜。而且Android的模擬器會是個大坑。還是老老實實真機調試吧。
不要妄想一套代碼兩處運行了。UI設計語言不同，所以基礎控制項不同。雖然ReactNative在類庫命名上感覺要極力彌合差距，但他們是為了幫助你學習的。絕非追求一次編寫，多處運行。
不要妄想在一個工程里包含兩個平台的客戶端源碼。哪怕只有UI也不行。

ReactNative只是UI框架。作為客戶端，還包含了大量的其他本地化代碼。如果你是一個本分的前端工程師，不要妄想光靠這個就get到客戶端開發的新技能。

其他等上手做了再補充。

研習React Native Android 時間過短，如果理解的有偏差，歡迎指正。

看了React Native Android的介紹，自己也嘗試著寫了個Demo，先說下總體感受：

集成麻煩
學習成本高
將java和xml代碼改寫成react需要很大人力
增加的包體積額外體積（大概增加了4m左右）
性能相比與Webview提升不明顯
我嘗試跟蹤下內存，發現內存會佔用很大，而且相應的Activity銷毀的時候沒有自動回收，多次打開直到內存超過虛擬機限制，才會被gc（簡單測試，沒有多次確認，不為可靠數據）

再說下我自己對React Native Android的粗淺理解：

看官方的性能對比，React Native Android是介於Webview和Native之間的。通過自己寫demo，讓我感覺這就是FB為了解決Webview的性能問題寫的一個小型瀏覽器。（Webview漏洞多性能差，Native可變動性差，那我們做個中間的。）

而為了使用React Native Android又要保證安裝包的體積，你就不得不使用它所依賴的庫，比如fresco、OKHttp，JacksonJson等，雖然這些都是最主流的庫，但是想要在一個已經成熟和完善的工程中，引用他們並不是一件輕鬆的事（比如要把我們的網路庫換成OkHttp，需要的開發和測試人力都不是一個小數字）。

綜上，如果只為了增加一個代替Webview的模塊，就在一個已經成熟的工程中引入React Native Android成本過高。

最近工作需求在研究RNA(React-Native Android)，說下遇到的問題吧。

目前RNA還非常不成熟，僅僅是demo可以獨立運行。gradle的plugin也沒有開放，集成到現有項目也沒有方案，scroll list里的android崩潰，二次開發控制項不支持等。

內存消耗只是在啟動時會出現峰值，頁面的載入後內存消耗平穩，在內存佔用這點比ios要好。

RNA用到了大量的第三方lib，什麼v4、v7、nineold等，如果你的現有項目有對這些依賴的二次更改，這是一個坑。需要修改gradle依賴。

然後是so，目前so只是32位編譯的，這個在issue里有說明，而且jsc目前只有armeabi-v7a，x86沒有其它的，這個如果你現有項目有armeabi 的so ，那麼集成時會有so找不到的android bug，這個需要重新編譯，是目前遇到的最大的坑。

當然如果是重新開發一個新app，那麼就簡單多了。

總之，目前遠沒有ios版成熟，需要改動地方非常多。

去年初開始創業做比特幣app，公司的幾個開發都是做了十幾年的老傢伙。按理說原生開發是第一選擇，但第一個版本我們選擇了cordova（其實也趟了很多坑，不提）。

之所以選擇cordova的原因是。當時正是比特幣最火的時候，市面上還沒有相關的app,我們用2個月做了第一個跨平台版本，成功圈住了用戶。

cordova出了幾個版本後，我們做了第一個原生版本，用的是兩大平台各自的原生語言。這麼選擇是因為當時陸續出來很多跟風的app，有些app體驗做的比我們的還好，如果不關注體驗，我們的先發優勢就會逐漸喪失掉。

用rn開發的問題在於

1,rn優化的再好，在體驗上也做不過原生應用。當產品面臨競爭的時候，用戶體驗是一個需要認真計較的地方。

2,iOS/Android兩個系統設計上有很多不同，反映到代碼的組織，界面設計，事件機制等都有很多不一樣的地方。rn能否將兩個平台用一個邏輯統一，個人持懷疑態度。這需要巨大的時間人力成本。

3,還是體驗的問題，iOS一直有詳細的界面設計規範。Android現在也有了（martial design)，兩個很多不一致。如果用rn,會面臨做一個另類的iOS應用還是做一個另類的Android應用的選擇。

4，隨著應用版本迭代，早晚會遇到rn解決不了的問題，此時還是要了解原生系統的種種，逃不過去。

所以，如果想快速開發應用，rn是個不錯的選擇，但是最終你可能還是逃不過原生開發。結合當前情況選擇合適的方案方為明智之舉。

另外針對樓上有些知友的評論多說幾句:遠程下載js代碼執行是違法蘋果審核政策的，我們的cordova版本因為這個被拒絕過，後來直接把js打包到本地才讓過。

其實蘋果這個政策很好理解，如果能隨意修改代碼，那麼就很容易跳過蘋果的支付渠道，蘋果還怎麼抽成呢。

sublime寫js跑android，感覺還不錯。

Sample React Native App

The focus of React Native is on developer efficiency across all the platforms you care about.

官網首頁原文。。直接說支持所有主流平台不就好了么，不支持 WinPhone 就算了。。你們不在乎 WinPhone 就算了。。為什麼要說成是我們不在乎 WinPhone。。

又得熬夜寫demo了

今年年初公司開始正式在業務上推廣React Native，前幾天的技術分享會上也給公司的研發團隊做了關於React Native實現原理的分享，總體感覺坑還是有的，尤其是在與業務團隊的對接上，但是好處也是明顯的，跨端開發，快速發布。

這裡貼一下React Native技術分享的文章與PPT，希望對大家理解原理有幫助O(∩_∩)O~

React Native實現原理分析文章

guoxiaoxing/react-native

註：好吧，好像知乎手機端識別不了上面這個github鏈接，ppt末尾給的有文章地址，也可以直接去github上搜索guoxiaoxing/react-native。

1ReactNative源碼篇：源碼初識
2ReactNative源碼篇：代碼調用
3ReactNative源碼篇：啟動流程
4ReactNative源碼篇：渲染原理
5ReactNative源碼篇：線程模型
6ReactNative源碼篇：通信機制

React Native實現原理分析PPT

react代碼移植到native，好麻煩。框架難道都只能用來新項目，或者推倒重來

之前不是有Titanium了么，又出來新玩具了，2年前ti 用過感覺還不錯，至少魯出來個項目，痛苦也不少，希望這個能好好發展。

React Native在IOS和Android方面性能都還不錯，開發入門也比較簡單。

具體如何評價，要看公司如何使用。目前越來越多公司轉向React Native開發。

非常建議大家學習一下，尤其是看本書React Native移動開發實戰系統學習一下。

作為正在用React Native開發一個巨型電商項目的開發人員來講，選擇React Native開發簡單的比如簡單兒科的小應用還可以，雖然已經有卡的體驗了，如果做大項目，沒有成熟團隊，簡直是噩夢！！！！

選擇React Native開發，只能是頁面簡單，交互兒科的小項目

小白膜拜大神們

剛剛用rn做了一個安卓端項目，感覺一開始的時候，坑還是比較多，facebook官方對內部缺陷的解釋是，項目太火，有時候，讓他們不知所措。比如一個至今沒解決的問題，scrollview在多記錄的情況下，初次render太慢，建議用listview。

總體的使用體驗還是不錯，值得一試！！

目前React Native只支持在OS X系統上面進行開發，其他系統的筒靴們請掩淚飄過，同時，使用React Native開發的app只能運行在&>= Android 4.1 (API 16) 和&>= iOS 8.0的手機操作系統上面。

正在學占坑將來答

樓主您好，我是一個剛剛開始學習RN的前端，遇到了一個您可能感覺很幼稚的問題，但是這個問題對於我真的很蛋疼，如果您有時間可以幫我解答一下么， Cannot find entry file index.ios.js in any of the roots