前言
React Native 是 Facebook 2015年開源的 Javascript 框架，旨在使用 Javascript 高效開發手機端 App。配合著多個顯而易見的優勢和 Facebook 強大的宣傳機器，它立刻成為國內外大小公司的明星開發框架。開源社群的參與激情、各方部落格的宣傳追捧，從其 Github 上 56000+ 星和 13000+ Fork 就可見一斑。
對於 React Native，iOS 開發者社群也是褒貶不一。有人認為 React Native 更快更好，蘋果原生那套要完，不趕快學習就晚了；也有人認為 React Native 不過是 Facebook 的又一個玩具，以它現在的稚嫩還難以對原生的 Swift/Objective-C 造成足夠威脅。
筆者希望就這幾年親身開發 React Native 和原生 iOS 的經驗，以及在矽谷的所見所聞，對這個問題提出一點自己的看法。對於一門新技術，我個人認為，評判其是否值得采用有以下兩個標準：
- 該技術本身是否具備足夠的優點
- 該技術是否符合目前的開發需求
下面就將從技術和開發需求兩個角度出發，談一談 React Native。
React Native 的技術特點
React Native 的優點很明顯。官網的醒目位置有簡單介紹，開發者們也在各種場合做了相關說明，總結如下：
跨平臺開發。同一段 Javascript 程式碼可以被用於 iOS 和 Android 兩個平臺。相比於以前 iOS 和 Android App 各維護一套邏輯大同小異的程式碼，React Native 的開發、測試和維護成本要低很多。
快速編譯。比起 Xcode 中漫長的編譯，React Native 採用了熱載入（Hot Reload）的即時編譯機制，使得 App UI 的開發體驗大幅改善，幾乎到了和網頁開發一樣隨改隨變的效果。
快速釋出。通過 JSBundle，React Native 可以即時更新 App。相比原來冗長的稽核和上傳過程，釋出和測試新功能的效率大幅提高。
渲染和佈局更加高效。React Native 可以直接套用網頁開發的 CSS 和 flex 機制，擺脫了 autolayout 和 frame 佈局中繁瑣的數學計算，更加直接簡便。
簡單易學。相比於 iOS 和 Android 的一整套複雜的知識體系，React Native 從本質上來講就是狀態機，對於開發者來講理解不難，且實際操作可謂入門容易、上手輕鬆。如果是前端開發者，那麼對於 Javascript 本來就有相應瞭解，用 React Native 開發手機應用更是水到渠成。
當然，看上去很完美的 React Native 在技術上也有諸多風險，比如：
第三方依賴。React Native 嚴重依賴於 Facebook 的維護。蘋果在 iOS 上每次技術的更新、政策的改變都會讓原來使用了 React Native 程式碼庫受到影響，等待 Facebook 和社群的修復會妨礙 App 的更新和使用者體驗。前段時間，百度和開發者們棄用
React Native 而迫使的 Facebook 修改開發者許可權（License）事件，證明了開發依賴於第三方的風險確實存在。邏輯上的額外開銷。直到今天， React Native 依然只是0.49版本，僅僅支援簡單的 UI 製作，其不成熟的 API 連複雜的動畫都難以實現，更別提 iOS 的底層優化和相容操作。同時因為作業系統和裝置的不同，React Native 得分別進行鍼對性處理，這對程式碼庫的維護又是一個挑戰。
聯調的困難。對於原生的 iOS 和 Android App 引入 React Native，會增加整個程式碼庫的複雜度，在深入底層原生程式碼進行 debug 時也是困難重重，可以說是在開發和維護上的成本都有所增加。
另外，有很多人覺得 React Native 的效能不如原生的 Objective-C/Swift 好。筆者自己嘗試過，覺得差別不大。與矽谷很多開發者的交流中得知，React Native 的效能與原生相比只有毫秒只差，根本不會對使用者體驗造成影響。對此感興趣的朋友可以閱讀此文Comparing the Performance between Native iOS (Swift) and React-Native，文中在 CPU、GPU、記憶體3個維度上進行了多個 API 的比較，React Native 與原生的 Swift 相比真是不遑多讓。
App 所面對的開發需求
作為 iOS 開發者，脫離了應用談技術，好比鏡中花、水中月——空談而已。實際 App 開發中，有以下幾種情況。我們來一一分析適不適合引入 React Native。
第一種情況，從零開始開發一款簡單的 App。它很有可能是獨立開發者的小試牛刀，或是初創公司的第一代產品。我個人認為這種情況下是非常適合用 React Native 的。此時，App 的UI 和業務邏輯都比較簡單，React Native 可以滿足絕大多數情況。而且，開發者時間有限，沒時間系統學習兩大平臺的知識體系；初創公司的成本有限，需要在 iOS 和 Android 兩個平臺上釋出產品，以便用最短時間、最小成本迅速積累第一波使用者，拿到投資。React Native 的技術特點非常符合這些要求。
符合這種的產品就如 Facebook 的 F8 App，這是一款專為其年度開發者大會打造的 App。因為它只有日曆、地圖、推送等簡單功能，React Native 再適合不過——1個工程師花了2周就完成了全部的開發，現已開源在 Github 上。
第二種情況，從零開始開發一款比較複雜的 App。這有可能是一個公司新的產品線，也有可能是一個成熟 App 的重構。在這種情況下，質量、口碑、以及日後的維護就是首要考慮因素，原生的 Swift/Objective-C 在面對實際問題時解決方案更加成熟多樣，React Native 發揮不了其技術優勢，故而原生開發是更為穩妥的選擇。
舉個例子，Uber 在去年推出了他們新的 App。內部也嘗試了 React Native，但因為無法滿足 App 對於複雜動畫的需求、與底層系統的相容不夠、效能上的優化不足等多個原因，最終決定放棄使用。
第三種情況，在原有的 App 中引入新的功能。這種情況比較複雜，它又分為以下幾種情況：
原來的 App 程式碼庫是 100% 的 Objective-C/Swift。這種情況下我個人不推薦引入 React Native。因為技術團隊已經穩定在 iOS 和 Android 兩個技術棧上了，引入第三個技術棧，技術上增加複雜度和維護成本，人員上要組建一個新的 React Native 團隊，開支和組織架構上都有負面影響。除非有足夠的預算，或是後期有大幅採用 React Native 的計劃，否則不推薦引入 React Native。
驗證新功能該不該引入。驗證過程中公司有時間成本，高層希望的是短期內就能做出決策。React Native 正是這種情況的銀色子彈。據我所知 Tesla 的 App 就採用了這種機制。
新功能確定引入，不是核心功能，並不複雜。這種情況下當然可以嘗試 React Native。如果是網頁端型別的 App 或是功能，比如淘寶、攜程、京東之類，他們本身就有大量的網頁端開發經驗，不如直接讓負責的前端工程師來處理相關的移動端業務。即使不成功也不會影響主要業務，同時可以為公司的技術積累提供寶貴經驗。Facebook 和 Instagram 的主 App 目前在部分小功能上就用了類似的循序漸進得采用 React Native 的策略。
新功能確定引入，是重要功能，有嚴格的釋出要求和日期。這個同上文說的第二種情況相同，保險和穩妥起見不推薦採用 React Native。
總結
單純從技術角度來講，React Native 絕對是移動端不可多得的優秀框架。它狀態機的思路可以被借鑑用來寫原生的 View Controller，其 UI 佈局上的機制也對我們平日在效能上的優化提供了靈感。
目前矽谷對於 React Native 也普遍持保守態度，採用 React Native
的科技巨頭也只有 Facebook，Amazon，Uber，Airbnb 四家，而且都是區域性小功能、小App採用。好訊息是，Facebook 對於 React Native 的投入不遺餘力，圈內開發者也是對此頗為積極。更多細節可以閱讀官方的開發日程表：React Native Scheduling
筆者認為，只有在快速開發、節約成本的考慮之下，React Native 才能發揮出巨大的優勢。對於 iOS 開發者，React Native 只可作為適當補充，我們還是應該多多鑽研 Swift / Objective-C 以及 App 開發的思路，它們才是進階成長的關鍵所在。