• 原文地址：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、前端、後端、產品、設計 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃。