我們是如何構建自己的 React Native App 的

去年，我們推出了 PWA ，旨在改善用戶在使用緩慢而不穩定的網路時的連接體驗。這是我們努力打造產品質量的第一步。 我們收到了社區和客戶非常積極的回應，並希望能複製我們的成功。

挑戰

我們需要在三種不同的平台上構建：Android，iOS 還有 Web 端（pc和手機）。

這意味著重複的業務邏輯要維護4個代碼庫，重複造輪子並非是一個最好的選擇。

這也意味著引進新的特性或者修改已有的代碼必須在4個單獨的代碼庫重複進行。這樣的平台根本不具可擴展性並且很快會因平台間失去同步而走想終點。

最終，我們不得不針對3個平台分別建立1個單獨的開發小組。

目標

為了攻克這些挑戰，我們決定把賭注壓在最新興起的由時髦的前端語言 JavaScript 構建的跨平台原生應用。為此，我們開始圍繞下面的主要目標來構建應用：

儘管這些應用是由 JavaScript 編寫的，但是它們在用戶體驗，用戶交互響應等方面應該不遜色於原生應用。簡單來說，假如你是用戶，你使用這些應用的感受應當和那些來自蘋果應用商店或者谷歌應用商店的原生應用相同。

這個應用應該能夠跨 Android 和 iOS 並最大限度的復用代碼。這是符合"DRY"原則的。這樣也意味著維護代碼將會很便捷，同時添加/修改/刪除產品特性涉及的改動會最小化。

最後但同樣重要的是，我們的產品工程師團隊應該熟悉整個代碼的運作並且減少對特定平台原生開發人員的依賴。這也符合軟體工程中「增加公共因子"的原則。

堆棧

react-navigation ?—— 仍處於早期階段，但它以聲明使用 Animated API 的方式解決了頗有爭議的導航問題。它也很適合用於處理我們基於 redux 的狀態管理系統，因為它是一個純粹的基於 JS 的解決方案。同時，我們也正在探討其他本地和混合導航的解決方案。

redux-observable? —— JS 生態系統仍然致力於為非同步狀態管理找出最佳解決方案，但說到底，它更多是「每部分自身」的問題。我們決定使用 redux-observable，因為它可以幫助我們很好的分離副作用，並使用簡潔有力的 RxJS 操作處理它們。同時，這種方法還允許我們以相對孤立的方式測試處理我們的副作用代碼。

immutable —— 所面臨的不愉快的事情是，我們難以在以前的平台上發現由我們的 reducer 突變引起的錯誤。為了一勞永逸地解決這個問題，我們決定在整個應用程序中使用不可變數據結構。這是通過定製的 reducer factory 實現的，它可以在不可變的和普通的JS數據結構之間進行轉換。

ramda? —— 儘可能地使用處理我們大部分業務邏輯的純函數，使其成為一個功能強大的聲明代碼範例。 Ramda JS 在這方面對我們來說是不可替代的。

redux-persist? —— 與網頁端應用程序不同，本機應用程序有離線模式和持久狀態的需求。這個庫與 redux-persist-migrate 很好地用一個後備 AsyncStorage 層滿足了這樣的需求。

工具

除了這些常用的工具 ?—? yarn, prettier, eslint和husky，我們還依賴於下列工具：

storybook?—它為開發獨立的本地組件提供了極好的支持。因此，我們可以將我們的 UI 組件編碼為與我們的設計指南的一一對應。我們正在尋求內部部署的可能，以便設計人員也可以訪問實際的組件。

codepush?—?這是一個 react 本地應用程序真正閃耀的領域。我們在向用戶發布更新時使用 codepush 多於 air update，因為它擁有完整的回滾百分比和目標版本。

fastlane?—?在 fastlane 中，管理不同的環境（暫存，開發，產品）和自動化構建很簡單。我們在內部的 Jenkins CI 中發布一個參數化的構建面板，它管理著從應用程序秘密、代碼簽名、Test Flight、Crashlytics Beta 上傳、內部測試構建的設備註冊、通過 codepush 等方式發布 OTA 更新等所有內容。

jest 和 detox?—?這個組合為我們的應用程序帶來了一個不錯的測試平台。鑒於我們必須為原生模塊編寫 mock，Jest 被證明在配置 react native 開始時確實有點麻煩的，但這麼做是值得的。Wix 工程組的屬下人員設計的 Detox 為我們簡化了端到端的測試流程。

sentry?—sentry.io 的工作人員在一定程度上引入了對 react-nativce 應用程序的支持。新的 SDK 添加了大量有用的設備相關數據的錯誤報告，並提供了本機和 JS 堆棧跟蹤的整體報告。

超過 90％ 的應用程序的源代碼是 JavaScript，並且不會影響其性能和質量。

學習收穫

React Native 是一個相對新的平台。其周邊的社區仍然在探討最佳實踐以及完成某些事情的正確方法。官方文檔是我們發現的作為起步學習的最好資源。以下是我們在深入學習過程中的一些收穫：

InteractionManager ?— 當涉及到 perf，InteractionManager 必不可少。由於 JS 是單線程，社區已經付出了相當大的努力，將開銷高昂的任務放到本地線程上運行。有時候你需要在 JS 中執行開銷大的任務，並且不能影響你 animation/transition/ 用戶交互的 perf。InteractionManager 提供了一套不錯的調度 API 來延遲這些高開銷的任務，直到所有的 animation/transition/ 交互完成。

requestAnimationFrame ?—? 此概念是從網路上借鑒來的，工作原理類似。一個特定的用例是 Android 設備的漣漪效應。在 apt onPress 處理程序中使用 TouchableNativeFeedback 的常規方法在這裡並不一定適用。有時候，你可能看不到「漣漪」。相反，如果你在 requestAnimationFrame 塊中封裝你的 onPress 處理程序，你會觀察到動畫是完美可見的。

MessageQueue ?—? React native 是通過橋接實現 JS 和本地程序之間的通信的。因此，在此橋接上會有持續的通信，如果調整不當，可能會影響性能。顧名思義，MessageQueue 上的 spy 方法，讓你可以獲知此聊天，並查看具體發送的內容。這可能有助於你了解實際發生的情況並提高性能。

setNativeProps? —? 來自官方文檔中顯示，「setNativeProps 在 React Native 中的作用等同於直接在 DOM 節點上設置屬性」。有時候，處於某些只有你自己知道的原因，你可能需要操縱支持 JS 視圖的底層本地視圖，以使得 React 渲染進入周期短路。我們只在幾個地方使用這種方法，因為其他的一切機制都不能很好完成任務。避免使用該介面或在必要情況下，非常明智地使用它。

Structuring? —? 從一開始，我們就在代碼庫中遵循一個簡單的組織結構的原則。 我們將 dumb UI 組件與狀態視圖分開。狀態管理都在我們的 epic s和 reducer 中得到處理。我們觀察到，隨機分散的副作用所生成代碼成為保證代碼庫高性能和可測試性的阻礙。我們使用 redux-observable 的方法幫助我們減少一些類似的痛苦。請看以下示例：

構建 Pipeline

官方文檔對 API 和平台本身提供了大量的解讀。最後，你需要部署新的嶄新的應用程序。這也包括維護用於測試和暫存的多個環境、以非入侵方式混合不同的憑證、生成發行說明並通知所有相關者（產品經理、測試人員和設計人員）等挑戰。經過一系列不同策略的嘗試和反覆，我們遷移到了 Fastlane 上，這樣可以使整個過程實現自動化。以下是我們在 iOS 上的 beta 發布循環中的刪減版：

這段代碼處理了代碼簽名、註冊用於測試的設備、增加內部編號、構建應用程序、上傳到 Crashlytics Beta 中、生成發行說明、在 code-push 上推送發布代碼和將 sourc-maps 上傳到 sentry 、通知 slack channel ，以及最後在 GitHub 上添加發布標籤。你可以把本該用於構建的時間做任何其他事情。該代碼位於主應用程序代碼旁。由於 CI 在每次構建之前都引入了一個新的版本，所以在不破壞 CI 的前提下修改構建 pipeline 是非常容易的。

進階貼士

閱讀此文檔和發布說明。

在你安裝某些軟體，但無法正常工作或無法找到時，yar n需使用- -reset-cache 選項啟動。

react-native-debugger?—?基於 React Native 的官方調試器的獨立應用程序，包含 React Inspector / Redux DevTools。

使捆綁式 Perf Monitor 成為你的良師益友。

總是在真實設備上測試。

前提條件是熟知 React。

腳註

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！