按照目前react native的發展，有沒有可能幾年之後原生開發技術不再被使用？

01-06

要到「取代」的水平，必須原生技術的每一個功能，不論是多麼犄角旮旯的功能，都必須在 RN 裡面能夠實現，並且 RN 比 native 至少在一個方面有顯著優勢。

現在顯然沒有嘛。

看來這個話題下回答的時間都是7個月之前，那個時候微信小程序還沒有出，而且RN實際踩坑的回答也不是很多，我這裡從踩坑的角度談一下RN的前景。

前面有人說RN的主力使用者應該是前端的React教徒，但是我認識的前端工程師很少是React全家桶通吃的，且不用說GraphQL，即便是Redux及其衍生品都很少用，但這不是最主要的，完全只有前端開發經驗的工程師來搞RN最主要的障礙是原生開發經驗的不足。

舉個實際開發的例子：

不知道有沒有人用過RN提供的Webview組件。如果使用iOS原生的UIWebview，打開一個網頁，如果想做一個點擊圖片大圖預覽/保存到相冊的功能的話，相信有經驗的工程師都會有自己的辦法。原生下我的做法是拿到整個網頁的字元串（載入通過loadHTMLString），通過正則取出圖片元素，逐個添加一個自定義的JS事件，這樣在點擊圖片的時候，在相關的代理方法中我就能拿到這個圖片的地址，通過NSURLCache提供的方法取出這個圖片的data，接下來想怎麼處理就可以怎麼處理了。

但是在RN下，我發現NSURLCache失效了，取出的data怎樣都是空的。我的解決辦法是添加NSURLProtocol子類，並在對應的代理方法中對圖片類型資源進行緩存處理。

（目前發現GIF格式還是有問題。考慮用SDWebImage提供的ImageManager來搞）

安卓那邊Webview是怎麼情況不清楚，但是聽說圖片用的是fresco，相信也要特殊處理吧。

你覺得只有前端開發經驗的工程師會對iOS的URL Loading System很熟么？更不用說安卓那邊的了。

實際上，很多前端工程師在用RN時都還沒有碰到這種稍微深入點的問題，就被iOS複雜的證書體系、各種三方庫怎樣倒入（是的，即便有些三方庫可以利用rnpm或者react-native-tool提供的link命令就OK了，但iOS上的一些庫就要自己搞了。你也許會說用cocoapods搞定好了。但是大部分前端工程師知道這個么？他們有很多人連npm都玩不好）打敗了。

所以有人戲稱，如果搞RN，請善待你身邊的原生工程師，因為你時不時的要向他們求助。

但是原生的工程師不一定有很大優勢。除了學習React全家桶那些東西外，還有前端經驗不足也是個障礙。很多前端工程師看來很簡單的東西，比如讓字體垂直居中（安卓text組件有這個屬性，iOS沒有），比如讓組件懸浮，我們都要依賴百度。更不用說RN對CSS樣式並不完全，你網上查到的方法不一定有用，各種坑還是需要請教前端工程師。

有些前端工程師有過node-gyp的使用經驗，他們本身可能以前做過C++開發，在有特殊需求需求的時候（比如需要搞一些so庫），我們就要依賴他們。很多原生工程師即便搞過C++，他們也沒有搞過gyp。

除此以外，RN本身還有很多坑。比如Animate的組件如果設置圓角，在安卓上無效；又比如RN的text組件搞富文本簡直麻煩的要死，還有官方提供的組件暴露出來的回調根本不夠用等等。

總的來說，要搞RN，你們團隊裡面最好有個老司機，最好是各個端都有開發經驗，這樣少走很多彎路。知乎我也看過很多回答，他們都因為各種坑，放棄了RN，又轉回了原生。

但是總的來說，RN的生態還是在發展的。現在也開始穩定了，由原來的兩個禮拜一更新，到現在一個月一更新，原生上常見的一些控制項，也有人做好RN版。甚至一些原生都比較難搞的，比如webrtc，都有人搞好RN版供你使用。

這也是RN比微信小程序的優勢之一，就是你可以復用原生和js已經做好的輪子，如果還是不能滿足你的要求，你可以自己造。

（通過在越獄手機使用FLEX查看微信小程序，我們可以看到組件基本都是原生組件，所以猜測微信小程序也是借鑒了RN的一些做法，但是由於具體實現對我們來說完全是黑盒的，可定製性為0）

在FB官網上的showcase來看，BAT都有在用RN，一些大公司，比如京東、攜程，也在用。但是鑒於目前RN還不是很完美，現在基本都是用來做活動頁面了。國內敢用RN做App 的不是很多，餓了嗎的蜂鳥眾包（給騎手用的）是RN做的，但是在App Store上差評如潮…

所以結論就是，短期內RN干不掉原生（更不用說殘廢的微信小程序了，不管外面怎麼吹，也改變不了他自己功能有限的事實），目前可以作為Hybrid手段的一種補充。如果生態能夠進一步發展，未來也許也會成為開發的一大主力。而且Apple有將macOS 和iOS合併的趨勢，微軟則是在一直在做移動和桌面的整合。RN可能未來還能像electron、nw.js那樣做桌面開發。個人感覺要比微軟的Xamarian有前途。

瀉藥！

首先，不要把客戶端UI開發等同與客戶端開發

其次，技術判斷上類RN會成為未來1-5年客戶端UI開發的主流之一，不亞於H5模式。

rn本身也需要用原生開發啊，而且有很多功能只能原生做

桌面軟體都沒能做到的事情，移動設備短期更沒法做到。至少在計算資源，電源，網路帶寬上，移動設備的限制只能更多。

不管大家怎麼努力，移動設備的開發，還是有意無意的把當年早期桌面軟體的輪子，和坑，都搞了不少。也許這就是事物發展的必然階段吧。

6月25日補充說明：

預測 RN 未來發展，要看核心開發團隊對其投入的人力物力支持，以及未來會不會有 FB 之外的巨頭來推動。做這方面的判斷可能需要更多的內幕信息或者統計數據來支撐

關於 APP 開發者選擇 RN 是否合適，則要看開發者（或開發團隊）的素質和性格了。RN 目前的完成度可能比較適合追求新技術（所謂 adventurous）、喜歡折騰、自學能力強的開發者。等到發布正式版了之後也許會有更多的前端開發者和單平台開發者投入進來

問題描述的主觀偏嚮導致大部分回答都是偏唱衰，本人以下回答也只是基於個人使用體驗

更多關於 React Native 的具體分析請移步：如何評價 React Native？ - Android 開發

===== 原回答 =====

其實 React Native 是一種非常矛盾的存在

一方面，RN 要跨平台，表面上看是所謂的「learn once, write everywhere」。但是真正要做到 "native" 又需要兼顧到 iOS 和 Android 平台巨大的差異，從 RN 大量的組件名字和屬性帶有 iOS 和 Android 後綴就可以看出來。甚至有時候為了適配兩個平台，工作量比單獨給兩個平台做開發加起來還要多。

另一方面，應用的邏輯代碼主要是 JavaScript (ES6)，而且可以使用 redux、relay 等 react 全家桶，加上 npm 大量的第三方庫、快速的 Hot Reload、Chrome 調試工具無疑都可以加快開發效率。但是，Web 開發和 App 開發畢竟還是有很大的區別，Web 開發中的那些大量的 CSS 框架就沒法用在 RN 上。為了實現原生控制項的效果同時也要方便上層的 JS 調用，RN 造了大量的輪子，但是這還遠遠不夠而且 Bug 似乎永遠修不完，從 RN 數量龐大而且非常活躍的 issue 列表 https://github.com/facebook/react-native/issues/ 可以看出來。

上面提到 RN 本身的坑和 Bug 和需要做的東西太多，要對 RN 進行擴展或二次開發對開發者的技能要求又相對較高（至少要熟練 (Android || iOS) Javascript））。然而現實是這樣的人並不如單獨搞原生開發或者搞前端的人多，這無疑導致 RN 本身的坑不會修復得很及時。另一方面相關文檔的數量和詳細程度、官方 demo 程序、第三方控制項的質量也不盡人意。

RN 當前最新版是 @0.27.x，說明目前 RN 本身就很不穩定，一個 minor 升級就能有可能把你的現有 App 搞崩潰或者幸運一點只是控制項出點小 Bug。同時也正因為不穩定，所以當前最可靠的參考資料就是官方文檔，而上面提到的官方文檔本身就不夠詳細，很多坑需要自己去摸索。

所以結論是，目前還看不到任何取代的跡象。也許未來原生開發會被取代，但是很有可能不會是 React Native

題主可能搞錯了一個事情，RN永遠都不可能完全取代原聲生開發。

說到底RN就好比一個基於原生二次開發的庫，你用js寫的組件，都是通過調用原生的組件實現其功能，這些調用原生的代碼，fb幫你寫好了，你看不見，但並不代表它不存在。

如果你想調用一個RN中沒有的組件，你還是得自己寫對應的代碼，這就和傳統的jsBridge沒有任何區別，而且，一些偏底層的東西，RN還是無能為力的，RN目前還偏向於UI控制項的調用

原生開發者:總有刁民想取代我年年不歇啊

不可能，React Native不是銀彈，短時間內也不會有銀彈。RN及類似的技術以後確實會取代大部分原生開發工作，但是如果說原生開發是100分得話，RN現在能做的事也就剛及格的水平，要想用得爽，還是要掌握一些原生開發知識來處理一些問題。況且RN本身也僅僅是過度技術之一，最終還會回歸到web上。短時間內，Web Assembly是比較有盼頭的技術。

杞人憂天，RN的基礎也是Native代碼，本身RN只能做UI，退一步講那些硬體特性也做成插件了，所有的Native功能都RN插件化，FB肯定不會出，還是要靠社區，社區的能拿來用在商業產品中？不需要自己的一些優化，或再組裝？那你還是要寫Native代碼。

React Native 你用 JSX 寫的組件，也都是原生技術寫的，你之所以不寫，是因為有人（Facebook）已經給你封裝好了

兩個星期前我從沒寫過native app 一直寫web前端代碼的

兩個星期內一次性把公司的web app擼到iOS和Android 當然只有一些基本的功能

半年內一大波Javascript程序員來襲你怕不怕

現在改簡歷去 精通移動開發

總有各種框架想要取代原生，別累著。RN的出現只是多了一個框架，一種開發方式。本身就是調用Native的方法，如果組件不滿足開發條件、Native層出現問題、RN很難開發的場景，還是要用Native開發來解決問題。況且Android又不是只應用於手機端，替代那是不可能的。未來可能出現的問題，就是有一種新框架替代RN，而不是框架替代Native。

還有什麼webApp，什麼H5是趨勢，都趨勢了多少年，桌面端都沒完全替代，跑移動端更是難上加難，本來就是一個配角的實力老想當主角。未來的時代是精品時代，用戶才不會在乎你用什麼技術，只要你的體驗是頂級的，你才會有立足之地，就這一點Native永遠不會被取代，除非Android被取代了。

汗，提這種問題說明沒用過RN

原聲永不過時，框架只是武功，原生是一招一式，萬變不離其中。原生用的6學任何新知識都不會吃力。So，我就是支持原生王道論！

取代，這是基本上不會的，因為每一種語言都會不斷的吸取，進步，並不是只有RN在成長。

不過，就從利益上來講，原生開發者會減少三分之一，也就是純應用層開發者，就拿我們公司來說，我們是做藍牙智能家居的。你說RN能搞么？還有很多其它各種各樣的嵌套了安卓，你見過快遞員手中那個機器么？那就是一個安卓設備，我們也做運行上面的APP。

另外就是，做為一位開發者，我們理當不斷地學習，不斷地進步，不斷地積累。不要害怕，不要迷茫，堅定自己。

清醒而論，手機端目前的限制還是比較大的。技術都是業務驅動，能實現業務的技術才是真諦，目前來看，還是原生功能最強，h5有自己的優勢，RN目前還不敢用，至於手機上以後的發展，我覺得h5還要有發展，需要安卓系統要有更好的支持，看谷歌的準備怎麼發展了。

至於原生開發嘛，你想想看連編譯器都能熱修補，熱更新了。app還會遠嗎？ h5在發展，原生也在發展。想不被時代淘汰，就多學習一把，別指望一門手藝能一統江湖，一門手藝的人已經不在了

至於RN代替原生，沒原生哪來的RN? 樓主睡醒了嗎?

有幾個是真正用rn寫過項目的？不了解不要強答

應該期待android和ios在原生webview中持續優化，rn只是這段時期內的過度品，會隨著os底層對h5支持的越來越好而走向消亡

React Native 的google trends

先說廣義上RN有沒有可能替代原生開發技術？

當然不行！

《王者榮耀》就不可以用 RN 開發。——遊戲、數據可視化、加密、人工智慧等等場景，RN就不適合，甚至不知道如何去做。不單單RN不適合，react也不適合。

RN有沒有可能替代普通UI的製作？

比如說淘寶客戶端中的大部分功能，可不可以用RN開發。

啟動屏（不可以，太需要性能， RN不知道怎麼做）
瀏覽商品，瀑布流，虛擬化（可以，RN也可以實現虛擬化技術——即超大列表流暢）
直播（NO！或者說80%需要原生開發)
掃碼（NO！需要原生提供組件。用個開源組件替代下行不行？你想多了，人家是淘寶，非常在意性能，這種體量的APP不可能這樣做。）
購物車，個人中心（OK）

...

不多分析了，很多體驗還是需要Native；這樣說很明顯了吧？

工程師有沒有可能完成整個APP開發？

開發一個APP需要原生技術——IOS+Android；需要H5技術，部分頁面用H5比較方便；需要RN技術，有一些頁面很適合RN。

這些技術都有自己擅長的點，那麼一個工程師能不能夠全部掌握？

當然可以，只是對人才要求太高，招聘太有難度。