iOS 開發是否要採用 React Native?

前言

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 在技術上也有諸多風險，好比：

• 第三方依賴。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 相比真是不遑多讓。

React Native 在 UI 上的表現確實驚豔

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 對於複雜動畫的需求、與底層系統的兼容不夠、性能上的優化不足等多個緣由，最終決定放棄使用。

Facebook F8 App，React Native 經典案例

第三種狀況，在原有的 App 中引入新的功能。這種狀況比較複雜，它又分爲如下幾種狀況：

1. 原來的 App 代碼庫是 100% 的 Objective-C/Swift。這種狀況下我我的不推薦引入 React Native。由於技術團隊已經穩定在 iOS 和 Android 兩個技術棧上了，引入第三個技術棧，技術上增長複雜度和維護成本，人員上要組建一個新的 React Native 團隊，開支和組織架構上都有負面影響。除非有足夠的預算，或是後期有大幅採用 React Native 的計劃，不然不推薦引入 React Native。

2. 驗證新功能該不應引入。驗證過程當中公司有時間成本，高層但願的是短時間內就能作出決策。React Native 正是這種狀況的銀色子彈。據我所知 Tesla 的 App 就採用了這種機制。

3. 新功能肯定引入，不是核心功能，並不複雜。這種狀況下固然能夠嘗試 React Native。若是是網頁端類型的 App 或是功能，好比淘寶、攜程、京東之類，他們自己就有大量的網頁端開發經驗，不如直接讓負責的前端工程師來處理相關的移動端業務。即便不成功也不會影響主要業務，同時能夠爲公司的技術積累提供寶貴經驗。Facebook 和 Instagram 的主 App 目前在部分小功能上就用了相似的按部就班得采用 React Native 的策略。

4. 新功能肯定引入，是重要功能，有嚴格的發佈要求和日期。這個同上文說的第二種狀況相同，保險和穩妥起見不推薦採用 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 開發的思路，它們纔是進階成長的關鍵所在。

做者：故胤道長