看沃爾瑪如何玩轉 React Native

• 原文地址：React Native at WalmartLabs
• 原文作者：Keerti
• 譯文出自：掘金翻譯計劃
• 譯者：Draftbk)
• 校對者：marcmoore), DeadLion)

在沃爾瑪，顧客總是第一位的，所以我們一直在尋找方法去改善我們給客戶提供的購物體驗。目前沃爾瑪 app 有許多嵌入式的 Web 網頁，我們發現這樣的實現低於我們和我們的客戶對這個應用程序的要求。即使在高端機上，這種混合 Web 視圖實現的性能也不是很好，並且缺少了原生應用的感覺。不止如此，通過 Web 來訪問非常依賴網路（我們使用伺服器端呈現 Web），網路不好的用戶會有不好的體驗。因此，我們在思考：「有沒有一種方法，能讓我們修改或者替換現在的實現方式，為顧客提供更好更流暢的體驗？」於是我們開始尋找答案。

可能的解決方案

經過一些頭腦風暴，我們想出了以下的解決方案：

1. 純原生實現 (沒有網頁了)
2. 用 React Native

理論上來說使用原生語言實現是很不錯的，但是實際上，我們需要考慮生產力、代碼的共享、發布時間這些因素。這時一個像 React Native 這樣的跨平台框架更勝一籌。當然還有一些其他的跨平台的移動開發框架，例如 PhoneGap、Xamarin 以及 Meteor，但是考慮到我們當前的 Web 使用了 React 以及 Redux，React Native 是我們優先考慮的。更不用說，它現在很穩定並且很可能會繼續流行一段時間。

下面是我們發現使用 React Native 的好處:

效率

• 在 iOS 和 Android 兩個平台上我們有 95% 的代碼是可以共享的
• 不需要知識共享，因為每個功能都由單個團隊實現的
• 開發者體驗很贊。 無需重新編譯就可以看到簡單的更改
• React Native 是用 JavaScript 寫的。 我們可以充分利用整個組織內部的編程技能和資源

代碼共享

• 前端/演示代碼在 iOS 和 Android 之間可以共享
• 業務邏輯（redux store）也可以與 Web 應用共享
• 不同平台間的大量代碼可以復用

應用商店的審批

• 不需要通過應用商店審批流程。我們可以在我們自己的伺服器上託管代碼，並實現 ota 更新

上市時間

• 非常快
• 我們可以控制發布日期
• 這兩個平台可以控制在同一天同一時間發布

性能

• React Native 提供了和原生應用幾乎一樣的性能

動畫

• React Native 提供了非常流暢的動畫，因為代碼在渲染之前轉換為原生視圖（View）

用戶體驗（UX）

• 我們可以有平台特定的 UI 設計

自動化

• 相同的自動化工具可以在 iOS 和 Android 上運行

性能

當我們在 WalmartLabs 進行性能測試時，我們是有一些既定目標的。通過衡量 RAM 使用率、FPS、CPU 利用率等指標，我們希望能夠了解 React Native 是如何在其競爭對手當中脫穎而出的。我們也想研究 React Native 的擴展能力 ——因為 React Native 可能成為整個企業的標準移動技術。既然這個項目是 WalmartLabs 的一次實驗，我們的短期目標是證明這個技術和我們當前的技術有著相當的或者更好的性能。 我們的長期目標就是像 Facebook 那樣用我們的 CI 進行性能測試, 因此我們可以測試我們的每個變化對整體應用程序性能的影響。

美中不足（The trouble with tribbles）

至於現在，性能測試 React Native 仍然讓人頭疼。由於這是兩個不同的平台，有兩套用於收集數據的工具。蘋果為測試提供了工具，為我們提供了我們所需要的大多數測試。安卓系統需要使用多種工具來收集所有我們想要的數據。此外，對於許多測量，沒有簡單的方法來獲得數據流，所以一些測量不得不靠估計。

Facebook 試圖通過在 React Native 開發人員菜單中提供一個性能監視器來減小 Android 和 iOS 性能測試之間的差別。不幸的是，這個解決方案並不完美。在 iOS 上，它提供 RAM 使用，FPS 數據以及一系列與 React Native 相關的測量，但是對於 Android，perf 監視器僅提供 FPS 數據。在未來，如果可能，我希望看到所提供的測量能在兩個平台上標準化。

閉嘴，告訴我 React Native 是怎麼做的!

Ok，好的，但是要注意的是，我們報告的效果是基於我們的 app，可能不能代表你的 app。然而，我還是會嘗試提供可以從我們的測試中得出的一般結論。

我們收集的數據預示著希望。它已經表明，React Native 確實是一個可行的解決方案，適用於大和小的移動應用程序。在圖形性能，RAM 使用和 CPU 方面，我們採取的每一項措施都與我們當前的混合解決方案相當或更好，並且這對兩個平台都是如此。應用程序的整體感覺有顯著改善，並提供了遠勝 Hybird 方案的用戶體驗。

React Native 很快，飛一樣快。雖然我們沒有用一個純粹的原生版本來測試比較，但是可以說，就外觀和感覺，用原生的方式編寫這個應用程序不會提供任何明顯超過 React Native 的優點。總的來說，我們對 React Native 的性能非常滿意，我們希望我們收集的結果將得到業務部門的讚賞，最終獲得用戶的認可。

測試

為了確保我們的 React Native 代碼的質量，我們的目標是 100％ 的測試都進行了單元測試和集成測試。

集成測試

沃爾瑪的 iOS 和 Android 應用程序是由數百名工程師合作開發的。我們使用我們的集成測試，以確保我們的 React Native 代碼能在以後的發展中也保持良好的功能。

在沃爾瑪，我們需要支持各種設備和操作系統。Sauce Labs 使得我們能在不同版本的硬體和操作系統組合的 iOS 和 Android 設備上運行我們的集成測試。在多個設備上運行集成測試需要很長時間，所以我們每天晚上只做一次測試。

我們還使用我們的集成測試來防止回滾。我們已經使用 GitHub Enterprise 連接了我們的 TeamCity CI 以便對每個 pull 請求運行我們的測試。與集成測試不同，在 pull 請求時，我們只在一個設備上運行測試。 但即便這樣也可能需要更長的時間，因此我們採用一些工具來減少所消耗的時間。Magellan 也是一個我們的開源項目，它允許我們並行運行測試，顯著減少了測試時間。

測試本身用 JavaScript 編寫，由 Mocha 運行，並使用 Appium 命令來控制手機模擬器。React Native 允許我們在每個組件上設置一個testID屬性。這些testID作為 CSS 類名。我們方便地使用它們來精確地指定使用 XPath 的組件，並與之交互來達到測試的目的。

單元測試

我們使用單元測試來獨立地運行我們的 React Native 組件，防止無意的更改。

我們使用常用的 React 單元測試工具，如 Mocha、Chai、Sinon 和 Enzyme。但是 React Native 也有一些獨特的挑戰，因為它的組件有環境依賴使得它無法在 Node 上運行。react-native-mock 為我們解決了這個問題，因為它提供了模擬的 React Native 組件，當在 iOS 或 Android 之外運行時不會中斷。當我們發現自己需要模擬額外的依賴時，我們使用 rewire 這樣的 Node 模塊。

復用性

我們利用相同的自動化測試套件在 iOS 和 Android 上運行。

部署

React Native 的一個主要優點是能夠通過 ota 實現快速修復問題，可以繞過應用商店。這意味著 React Native JavaScript 的 bundle 將託管在伺服器上，並由客戶端直接檢索，有點像 web 的工作方式。

然而，React Native 提出的一個挑戰是，為了使 JS bundle 工作，在本地端必須有一個兼容的 React Native 副本。如果將本機端升級到最新的 React Native，並且用戶更新了應用程序，但是他們下載了舊的 bundle，則應用程序將中斷。如果您更新該 bundle 以匹配最新的本機端，並將其提供給尚未更新其應用程序的用戶，則它也會中斷。

像 Microsoft CodePush 之類的工具可用於將 bundles 映射到正確的應用程序版本。但是在決定使用 React Native 時應該考慮到同時支持多個版本的應用程序是也一種開銷。

挑戰

iOS 和 Android 的不同

在 iOS 和 Android 上的 React Native 的功能之間有很多的不一致，使得同時支持這兩個平台變得棘手。一些 React Native 行為和風格在不同的平台實現起來是不同的。例如，iOS 上支持 style 屬性overflow，而 Android 不支持。組件屬性也是在不同平台有不同的特性。在 React Native 文檔中，你可以看到標記為 「Android only」 或 「iOS only」 的許多屬性和功能。自動化測試代碼還需要針對每個平台進行調整。

我們發現 iOS 有比 Android 更多的特性，所以對於一個針對這兩個平台的產品，用「先開發安卓」的方法來開發是有意義的。

開發和調試

在我們的經歷中的一個痛點是 React Native 代碼在調試模式與正常模式下的不同行為，造成這個情況的原因是 React Native 對這兩種模式使用了不同的 JavaScript 引擎。當一個 bug 是常規模式特有時，自然很難調試，因為它在調試模式下是不可重現的。

總結

React Native 的確進行著一些偉大的事情。React Native 的標誌（可以說是其最好的賣點）是它的跨平台 ——允許同一個團隊在 iOS 和 Android 上同時開發，這可以減少大約一半的人工成本。說到團隊， JavaScript 開發人員是很多的，所需的移動端開發的專業技能要求是很少的，這意味著有適合的熟練勞動力是隨時待命的。產品的初始開發以及增加功能非常快，因此您可以比競爭對手更快地滿足客戶的需求。錦上添花的是，以 React Native 編寫的應用程序一般來說具有與原生語言編寫的應用程序性能相當甚至有潛在的優越性。

雖然 React Native 是有一些很棒的賣點，但在開始使用 React Native 的項目之前，還需要記住一些事情。 首先，儘管 React Native 在減小 iOS 和 Android 之間的差距方面做得很好，但是你不會在兩個操作系統之間實現完全的平衡。還是有一些事情其中一個平台可以做，但是另一個平台無法處理，主要涉及到樣式視圖，但是，還有很多需要注意的問題，例如性能測試。雖然開源社區對開發和發布新功能和性能調整非常滿意，但是實際上升級 React Native 版本往往還是給人帶來巨大的煩惱，特別是如果你有一個用 React Native 構建的平台，就比如我們的 Walmart。

我們堅信 React Native 是一個非常棒的框架。它做了我們想要的一切，它是如此令人欽佩。儘管它確實有一些問題，這些問題也被使用它所能得到的好處掩蓋了。從創業公司到世界 500 強公司，如果你考慮開發一個新的移動應用，可以考慮使用 React Native —— 我們覺得你不會後悔的。

貢獻者

本文是由 WalmartLabs 的 React Native 團隊的工程師協作完成的 —— Matt Bresnan、M.K. Safi、 Sanket Patel 和 Keerti。