[譯] 原生 iOS(Swift) 和 React-Native 的性能比較

• 原文地址：Comparing the Performance between Native iOS (Swift) and React-Native
• 原文做者：John A. Calderaio
• 譯文出自：掘金翻譯計劃
• 譯者：Deepmissea
• 校對者：gy134340，Danny1451

原生 iOS(Swift) 和 React-Native 的性能比較

React-Native 是一個混合的移動框架，可讓你僅僅使用 JavaScript 來構建應用。然而，與其餘混合移動開發技術不一樣的是，你構建的並非一個 「移動網頁應用」（把網頁應用封裝到一個原生的容器裏）。在最後，你會獲得一個真正的應用。與使用 Objective-C 編寫的 iOS 以及 Java 編寫的 Android 應用相同，你的 JavaScript 代碼最終會被編譯成一個移動應用。這意味着 React-Native 擁有了原生應用和混合應用的好處，而沒有任何缺點。

個人目標是找出他們是否可以準確地履行他們的承諾。要實現目標的話，我就須要用 Swift 和 React-Native 構建相同的應用。它須要足夠簡單，以便我能夠學習兩種語言並及時完成應用程序，但也須要足夠的複雜，才能比較每一個應用的 CPU、GPU、內存的使用狀況和功耗。應用會有四個 tab。第一個叫作 「Profile」，用來提示用戶登陸 Facebook 來得到用戶我的資料裏的照片和郵箱，並展現在頁面上。第二個 tab 叫作 「To Do List」，是用 NSUserDefaults（iPhone 內部存儲）來作的一個簡單的待辦事項表，它將有添加和刪除條目的功能。第三個 tab 叫作 「Page Viewer」，由一個 PageViewController 組成。PageViewController 有三屏，用戶能夠來回切換（紅、綠、藍三屏）。最後一個 tab 叫 「Maps」，由一個 MapView 組成，放大用戶的當前位置，而後在地圖上的用藍點表示。

Swift 的歷程

第一步是 iOS 和 Swift。學習 Swift 相對比較容易，由於它很像我知道的其餘語言（Java、C++）。然而，學習 Cocoa Touch（iOS 框架）纔是更難的任務。我看了 Udemy.com 上 Rob Percival 的一系列視頻，這讓我從初識 Swift 階段過渡到完成了幾個應用。雖然我在看完介紹視頻後仍是在 Cocoa Touch 上有不少問題。視頻裏大多數的「學習」只是調用複製/粘貼代碼，可是咱們不是很清楚它作了什麼。我感受可能老師也不知道這是啥，只是記住了它。我不喜歡對個人代碼一無所知。

Apple 的 IDE（Xcode）對用戶無疑即先進又友好。你能夠點擊叫作 Storyboard 的東西，按你想要的順序來設置你應用的屏幕，放一個箭頭，指向程序啓動的首屏。在第一個 tab（「Profile」）裏，我要拖一個圖片視圖、姓名標籤和郵箱標籤。而後，我拖住它跟代碼作一個連接，在代碼裏建立一個新變量。接着，以編程的方式，一旦用戶登陸了 Facebook，我就把變量的值改變成 Facebook 裏的值。經過視頻，我花了三週的時間來適應並完成了 Swift/iOS 的代碼。

你能夠在 GitHub 上看一下這個應用的 Swift 版本的代碼，連接在這裏：github.com/jcalderaio/…

Swift Tab 1 (Facebook Login)

Swift Tab 2 (To-Do List)

Swift Tab 3 (Page View)

Swift Tab 4 (Maps)

React-Native 的歷程

第二部分是 React-Native。學習 JavaScript 比 Swift 要難上一點，但也不是很困難。我試着利用我從網上學到的一些零碎的 React-Native 知識來編寫應用，可是還不夠。我須要一些視頻講座。回到 Udemy.com，我看了 Stephen Grider 介紹 React-Native 的精彩演講。一開始的時候，我感到很是不知所措，React-Native 的結構對我一點用也沒有。不過在看了 Stephen Grider 的演講以後的一週，我已經能夠本身編碼了。

我對 React-Native 感到真正喜歡的地方是，你寫的每一行代碼都很說得通，你知道每一行代碼的做用。另外，不像在 iOS 裏（須要調整每一個頁面，讓他們在橫屏或者豎屏時顯示正確的尺寸），在 React-Native 裏，全部的都調整好了。不須要任何設置，我就能讓個人應用看上去很完美。我在一些不一樣尺寸的 iphone 上運行個人程序也跑得很好。由於 React-Native 使用的是 flexbox（有點像 HTML 中的 CSS），它對正在展現的頁面尺寸來講是響應式的。

你能夠在 GitHub 上看一下這個應用的 React-Native 版本的代碼，鏈接在這裏：github.com/jcalderaio/…

React-Native Tab 1 (Facebook Login)

React-Native Tab 2 (To-Do List)

React-Native Tab 3 (Page View)

React-Native Tab 4 (Maps)

數據

如今是時候來對比一下看看哪一個應用性能更出色了。我會經過 Apple Instruments（Xcode 裏的工具包）工具，測試兩個應用的三個主要類別：CPU（「Time Profiler Tool」）、GPU（「Core Animation Tool」）和內存使用 （「Allocations Tool」）。Apple Instruments 容許我鏈接手機，而後選擇手機上的任何應用，再選擇我要用的測試工具，而後記錄測試。

每一個應用有 4 個 tab，每一個 tab 都有一個「任務」，我在每一個類別裏測試。首先是 「Profile」，它的功能是登錄 Facebook。在代碼裏的表現形式是請求 Facebook 服務器，返回我的信息圖片、郵箱以及姓名。第二個（「To Do List」）任務是從列表裏添加或刪除一個「代辦項」。第三個（「Page View」）任務是在三個頁面間來回滑動。第四個(「Maps」)任務是點擊 tab 後，代碼會讓 GPS 來放大我當前的位置，在個人位置上放一個藍色的放射形標記。

CPU 測試

Swift VS React-Native 的 CPU 用量

讓咱們來看看各個類別的狀況：

Profile: React-Native 在這裏略勝一籌，它比 Swift 更有效地利用了 1.86% 的 CPU。在執行任務並記錄數據的過程當中，當我按下 「Log in with Facebook」 按鈕的時候能夠明顯觀察到有一個峯值。

To Do List: React-Native 一樣以微弱的優點勝出，它比 Swift 節省了 1.53% 的 CPU 的使用。在執行任務並記錄數據的過程當中，當我添加完(added) 一項以及刪除完(deleted) 一項的時候，能夠明顯觀察到有一個峯值。

Page View: 這一次，Swift 用 8.82% 的 CPU 使用率戰勝了 React-Native。在執行任務並記錄數據的過程當中，當我滑動到另外一個不一樣的頁面時候能夠明顯觀察到有一個峯值。當我停留在一個頁面時，CPU 的使用會減小，可是若是我再次滑動頁面，CPU 的使用就會增長。

Maps: Swift 再次以 13.68% 的優點勝出。在執行任務並記錄數據的過程當中，當我按下 「Maps」 這個 tab 的時候能夠明顯觀察到有一個峯值，這會促使 MapView 找到我當前位置，並顯示一個顯眼的藍色脈衝點。

是的，Swift 和 React-Native 都贏得了兩個 tab 的勝利，可是總體而言 Swift 更高效的使用了 17.58% 的 CPU。若是我讓本身不專一於單個任務執行與中止，而是在各個應用長時間運行，那結果可能會不一樣。而我也注意到了在切換不一樣的 tab 時，CPU 使用並無變化。

GPU 測試

咱們要繪製的第二個數據表是 GPU 用量狀況。 我將爲 Swift 和 React Native 的項目中的每一個 tab 執行一個任務並記下測量結果。Y 軸的高度是 60 幀/秒。每秒，我執行每一個 tab 的任務的時候，一個測量就會被 「Core Animation」 工具記錄下來。我會取這些數據的平均值，而後繪製成下面的圖表。

Swift VS React-Native 的 GPU 用量
讓咱們看看每一個類別的狀況：

Profile: Swift 以比 React Native 高出 1.7 幀/秒的幀率的微弱優點，贏得了這個 tab 的勝利。在執行任務並記錄數據的過程當中，當我按下 「Log in with Facebook」 按鈕的時候能夠明顯觀察到有一個峯值。

To Do List: React-Native 以比 Swift 高出 6.25 幀/秒的幀率贏得了這個類別的勝利。在執行任務並記錄數據的過程當中，當我添加完(added) 一項以及刪除完(deleted) 一項的時候，能夠明顯觀察到有一個峯值。

Page View: Swift 在這個 tab 上以 3.6 幀/秒的幀率擊敗了 React-Native。在執行任務並記錄數據的過程當中，我觀察到，若是我快速滑動兩個頁面，幀率會急升到 50。若是我停留在一個頁面，那幀率會降低，可是若是我從新再頁面之間滑動，幀數又會急升。

Maps: React-Native 贏得了這個類別的勝利，由於它的幀率比 Swift 高出 3 幀/秒。在執行任務並記錄數據的過程當中，當我按下 「Maps」 這個 tab 的時候，能夠明顯觀察到有一個峯值，且這會促使 MapView 會找到我當前位置，並顯示一個顯眼的藍色脈衝點。

Swift 和 React-Native 再一次的各自贏得了兩個 tab 的勝利。可是，React-Native 以 0.95 幀/秒在總體上勝出。Facebook 從 React-Native 的代碼中榨出的果汁量讓人很是吃驚 — 目前爲止，React-Native 彷佛和 iOS（Swift）不相上下。

內存測試

咱們要繪製的第三個數據表是內存的使用狀況。我將爲 Swift 和 React Native 的項目中的每一個 tab 執行一個任務並記下測量結果。Y 軸（內存）的高度是我測量數據的最高值。CPU 的使用率採集間隔是 1 毫秒。在每毫秒，我執行每一個 tab 的任務的時候，「Allocations」 工具就會記錄一個測量。我會取這些數據的平均值，而後繪製成下面的圖表。

Swift VS React-Native 內存使用
讓咱們看看每一個類別的狀況：

Profile: Swift 以節省 0.02 MiB 的內存使用，稍微贏得這個 tab 的勝利。在執行任務並記錄數據的過程當中，當我按下 「Log in with Facebook」 按鈕的時候能夠明顯觀察到有一個峯值。

To Do List: React-Native 以比 Swift 節省 0.83 MiB 的內存贏得了這個 tab 的勝利。在執行任務並記錄數據的過程當中，當我向列表添加完(added) 一項以及刪除完(deleted) 一項的時候，能夠明顯觀察到有一個峯值。

Page View: 在這個 tab 中，React-Native 以節省 0.04 MiB 的內存用量擊敗了 Swift。在執行任務並記錄數據的過程當中，我發現我在 PageView 切換頁面的時，內存的峯值並無改變。字面上沒變。

Maps: React-Native 節省了 61.11 MiB 的內存，以巨大優點贏得了這個類別的勝利。在執行任務並記錄數據的過程當中，我按下 「Maps」 這個 tab 的時候能夠明顯觀察到一個峯值，並且這會促使 MapView 會找到我當前位置，並顯示一個顯眼的藍色脈衝點。在兩個 app 裏，內存都在持續的增長，但最終都中止了。

React-Native 贏得了 3 個 tab 的勝利，而 Swift 贏得了 1 個。總體而言，React-Native 比 Swift 節省了 61.96 MiB 的內存。若是我讓本身不專一於單個任務執行與中止，而是在各個應用長時間運行，那結果可能會不一樣。我在 「Maps」 的 tab 注意到，當我縮放地圖或者移動地圖的時候，內存呈指數地增加。「Maps」 消耗的內存要遠遠高於其餘狀況。

結論

我用 Swift 和 React-Native 寫的移動應用程序外觀看上去幾乎相同。從我在 4 個 tab 的任務中，測試應用程序的 CPU、GPU 和內存所收集的數據能夠看出，應用程序的性能也幾乎相同。Swift 在 CPU 這一類別總體勝出，React-Native 在 GPU 這一類別（略微）勝出，而在內存上以巨大的優點勝出。我能夠從這個數據推測出，在 iPhone 上，Swift 比 React-Native 更有效的利用了 CPU，而 React-Native 比 Swift 略微有效的利用了 GPU，並且 React-Native 在某種程度上更有效的利用了 iphone 的內存。React-Native 在平臺上的性能更好，贏得了三個類別中的兩個。

我並無考慮原生的 Android 應用。iOS 是我優先選擇的平臺，因此這是我最關心的。可是，我也會盡快的在 Android 上完成一樣的實驗。我很好奇結果會是什麼，可是我敢打賭，若是 React-Native 能比原生的 iOS 性能好，那它也必定比原生的 Android 的性能要好。

我如今更加確信 React-Native 是將來的框架 - 它有這麼多的優勢，那麼少的缺點。React-Native 能夠用Javascript 編寫（許多開發人員已經知道的語言），它的代碼庫能夠部署到 iOS 和 Android 平臺，製做應用程序的速度更快、成本更低，並且開發人員能夠直接推送更新，而用戶沒必要再下載更新。最棒的是，在剛推出一年的時候，React-Native 的性能已經超越了原生的 iOS Swift 應用程序。

引用

Abed, Robbie. 「Hybrid vs Native Mobile Apps — The Answer Is Clear.」 Y Media Labs, 10 Nov. 2016, www.ymedialabs.com/hybrid-vs-n… is-clear/. Accessed 5 December 2016.

M, Igor. 「IOS App Performance: Instruments &Amp; Beyond.」 Medium, 2 Feb. 2016, medium.com/@mandrigin/ios-app-performance-instruments-beyond- 48fe7b7cdf2#.6knqxp1gd. Accessed 4 Dec 2016.

「React Native | A Framework for Building Native Apps Using React.」 React Native, facebook.github.io/react-native/releases/next/. Accessed 5 Dec 2016.

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃。