看沃爾瑪如何玩轉 React Native
在沃爾瑪，顧客總是第一位的，所以我們一直在尋找方法去改善我們給客戶提供的購物體驗。目前沃爾瑪 app 有許多嵌入式的 Web 網頁，我們發(fā)現(xiàn)這樣的實現(xiàn)低于我們和我們的客戶對這個應用程序的要求。即使在高端機上，這種混合 Web 視圖實現(xiàn)的性能也不是很好，并且缺少了原生應用的感覺。不止如此，通過 Web 來訪問非常依賴網絡（我們使用服務器端呈現(xiàn) Web），網絡不好的用戶會有不好的體驗。因此，我們在思考：“有沒有一種方法，能讓我們修改或者替換現(xiàn)在的實現(xiàn)方式，為顧客提供更好更流暢的體驗？”于是我們開始尋找答案。
可能的解決方案
經過一些頭腦風暴，我們想出了以下的解決方案：
- 純原生實現(xiàn) (沒有網頁了)
- 用 React Native
理論上來說使用原生語言實現(xiàn)是很不錯的，但是實際上，我們需要考慮生產力、代碼的共享、發(fā)布時間這些因素。這時一個像 React Native 這樣的跨平臺框架更勝一籌。當然還有一些其他的跨平臺的移動開發(fā)框架，例如 PhoneGap、Xamarin 以及 Meteor，但是考慮到我們當前的 Web 使用了 React 以及 Redux，React Native 是我們優(yōu)先考慮的。更不用說，它現(xiàn)在很穩(wěn)定并且很可能會繼續(xù)流行一段時間。
下面是我們發(fā)現(xiàn)使用 React Native 的好處:
效率
- 在 iOS 和 Android 兩個平臺上我們有 95% 的代碼是可以共享的
- 不需要知識共享，因為每個功能都由單個團隊實現(xiàn)的
- 開發(fā)者體驗很贊。 無需重新編譯就可以看到簡單的更改
- React Native 是用 JavaScript 寫的。 我們可以充分利用整個組織內部的編程技能和資源
代碼共享
- 前端/演示代碼在 iOS 和 Android 之間可以共享
- 業(yè)務邏輯（redux store）也可以與 Web 應用共享
- 不同平臺間的大量代碼可以復用
應用商店的審批
- 不需要通過應用商店審批流程。我們可以在我們自己的服務器上托管代碼，并實現(xiàn) ota 更新
上市時間
- 非?？?/li>
- 我們可以控制發(fā)布日期
- 這兩個平臺可以控制在同一天同一時間發(fā)布
性能
- React Native 提供了和原生應用幾乎一樣的性能
動畫
- React Native 提供了非常流暢的動畫，因為代碼在渲染之前轉換為原生視圖（View）
用戶體驗（UX）
- 我們可以有平臺特定的 UI 設計
自動化
- 相同的自動化工具可以在 iOS 和 Android 上運行
性能
當我們在 WalmartLabs 進行性能測試時，我們是有一些既定目標的。通過衡量 RAM 使用率、FPS、CPU 利用率等指標，我們希望能夠了解 React Native 是如何在其競爭對手當中脫穎而出的。我們也想研究 React Native 的擴展能力 ——因為 React Native 可能成為整個企業(yè)的標準移動技術。既然這個項目是 WalmartLabs 的一次實驗，我們的短期目標是證明這個技術和我們當前的技術有著相當的或者更好的性能。 我們的長期目標就是像 Facebook 那樣用我們的 CI 進行性能測試, 因此我們可以測試我們的每個變化對整體應用程序性能的影響。
美中不足（The trouble with tribbles）
至于現(xiàn)在，性能測試 React Native 仍然讓人頭疼。由于這是兩個不同的平臺，有兩套用于收集數據的工具。蘋果為測試提供了工具，為我們提供了我們所需要的大多數測試。安卓系統(tǒng)需要使用多種工具來收集所有我們想要的數據。此外，對于許多測量，沒有簡單的方法來獲得數據流，所以一些測量不得不靠估計。
Facebook 試圖通過在 React Native 開發(fā)人員菜單中提供一個性能監(jiān)視器來減小 Android 和 iOS 性能測試之間的差別。不幸的是，這個解決方案并不完美。在 iOS 上，它提供 RAM 使用，F(xiàn)PS 數據以及一系列與 React Native 相關的測量，但是對于 Android，perf 監(jiān)視器僅提供 FPS 數據。在未來，如果可能，我希望看到所提供的測量能在兩個平臺上標準化。
閉嘴，告訴我 React Native 是怎么做的!
Ok，好的，但是要注意的是，我們報告的效果是基于我們的 app，可能不能代表你的 app。然而，我還是會嘗試提供可以從我們的測試中得出的一般結論。
我們收集的數據預示著希望。它已經表明，React Native 確實是一個可行的解決方案，適用于大和小的移動應用程序。在圖形性能，RAM 使用和 CPU 方面，我們采取的每一項措施都與我們當前的混合解決方案相當或更好，并且這對兩個平臺都是如此。應用程序的整體感覺有顯著改善，并提供了遠勝 Hybird 方案的用戶體驗。
React Native 很快，飛一樣快。雖然我們沒有用一個純粹的原生版本來測試比較，但是可以說，就外觀和感覺，用原生的方式編寫這個應用程序不會提供任何明顯超過 React Native 的優(yōu)點。總的來說，我們對 React Native 的性能非常滿意，我們希望我們收集的結果將得到業(yè)務部門的贊賞，最終獲得用戶的認可。
測試
為了確保我們的 React Native 代碼的質量，我們的目標是 100％ 的測試都進行了單元測試和集成測試。
集成測試
沃爾瑪的 iOS 和 Android 應用程序是由數百名工程師合作開發(fā)的。我們使用我們的集成測試，以確保我們的 React Native 代碼能在以后的發(fā)展中也保持良好的功能。
在沃爾瑪，我們需要支持各種設備和操作系統(tǒng)。Sauce Labs 使得我們能在不同版本的硬件和操作系統(tǒng)組合的 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 也有一些獨特的挑戰(zhàn)，因為它的組件有環(huán)境依賴使得它無法在 Node 上運行。react-native-mock 為我們解決了這個問題，因為它提供了模擬的 React Native 組件，當在 iOS 或 Android 之外運行時不會中斷。當我們發(fā)現(xiàn)自己需要模擬額外的依賴時，我們使用 rewire 這樣的 Node 模塊。
復用性
我們利用相同的自動化測試套件在 iOS 和 Android 上運行。
部署
React Native 的一個主要優(yōu)點是能夠通過 ota 實現(xiàn)快速修復問題，可以繞過應用商店。這意味著 React Native JavaScript 的 bundle 將托管在服務器上，并由客戶端直接檢索，有點像 web 的工作方式。
然而，React Native 提出的一個挑戰(zhàn)是，為了使 JS bundle 工作，在本地端必須有一個兼容的 React Native 副本。如果將本機端升級到最新的 React Native，并且用戶更新了應用程序，但是他們下載了舊的 bundle，則應用程序將中斷。如果您更新該 bundle 以匹配最新的本機端，并將其提供給尚未更新其應用程序的用戶，則它也會中斷。
像 Microsoft CodePush 之類的工具可用于將 bundles 映射到正確的應用程序版本。但是在決定使用 React Native 時應該考慮到同時支持多個版本的應用程序是也一種開銷。
挑戰(zhàn)
iOS 和 Android 的不同
在 iOS 和 Android 上的 React Native 的功能之間有很多的不一致，使得同時支持這兩個平臺變得棘手。一些 React Native 行為和風格在不同的平臺實現(xiàn)起來是不同的。例如，iOS 上支持 style 屬性overflow，而 Android 不支持。組件屬性也是在不同平臺有不同的特性。在 React Native 文檔中，你可以看到標記為 “Android only” 或 “iOS only” 的許多屬性和功能。自動化測試代碼還需要針對每個平臺進行調整。
我們發(fā)現(xiàn) iOS 有比 Android 更多的特性，所以對于一個針對這兩個平臺的產品，用“先開發(fā)安卓”的方法來開發(fā)是有意義的。
開發(fā)和調試
在我們的經歷中的一個痛點是 React Native 代碼在調試模式與正常模式下的不同行為，造成這個情況的原因是 React Native 對這兩種模式使用了不同的 JavaScript 引擎。當一個 bug 是常規(guī)模式特有時，自然很難調試，因為它在調試模式下是不可重現(xiàn)的。
總結
React Native 的確進行著一些偉大的事情。React Native 的標志（可以說是其最好的賣點）是它的跨平臺 ——允許同一個團隊在 iOS 和 Android 上同時開發(fā)，這可以減少大約一半的人工成本。說到團隊， JavaScript 開發(fā)人員是很多的，所需的移動端開發(fā)的專業(yè)技能要求是很少的，這意味著有適合的熟練勞動力是隨時待命的。產品的初始開發(fā)以及增加功能非常快，因此您可以比競爭對手更快地滿足客戶的需求。錦上添花的是，以 React Native 編寫的應用程序一般來說具有與原生語言編寫的應用程序性能相當甚至有潛在的優(yōu)越性。
雖然 React Native 是有一些很棒的賣點，但在開始使用 React Native 的項目之前，還需要記住一些事情。 首先，盡管 React Native 在減小 iOS 和 Android 之間的差距方面做得很好，但是你不會在兩個操作系統(tǒng)之間實現(xiàn)完全的平衡。還是有一些事情其中一個平臺可以做，但是另一個平臺無法處理，主要涉及到樣式視圖，但是，還有很多需要注意的問題，例如性能測試。雖然開源社區(qū)對開發(fā)和發(fā)布新功能和性能調整非常滿意，但是實際上升級 React Native 版本往往還是給人帶來巨大的煩惱，特別是如果你有一個用 React Native 構建的平臺，就比如我們的 Walmart。
我們堅信 React Native 是一個非常棒的框架。它做了我們想要的一切，它是如此令人欽佩。盡管它確實有一些問題，這些問題也被使用它所能得到的好處掩蓋了。從創(chuàng)業(yè)公司到世界 500 強公司，如果你考慮開發(fā)一個新的移動應用，可以考慮使用 React Native —— 我們覺得你不會后悔的。
貢獻者
本文是由 WalmartLabs 的 React Native 團隊的工程師協(xié)作完成的 ——Matt Bresnan、M.K. Safi、 Sanket Patel 和 Keerti。
