React Native釋出重構路線圖

xiangzhihong發表於2018-11-03
React Native

React Native作為時下最熱門的跨平臺開發方案，在這兩年的移動跨平臺方案中可謂一枝獨秀，在很多的移動產品中都可以看到它們的影子，相比國內的Weex，RN的迭代更加頻繁，效能上也無限的接近原生應用。不過，RN從效能上來說還是有提升的可能，所以，在今年的6月份，也即是Facebook剛剛釋出了 React Native 0.56後，React工程經理 Sophie Alpert 在其官方部落格上宣佈他們將要重構 React Native，使其更輕量，更適應 JavaScript 生態圈的發展。

React Native宣佈重構

React Native應用現狀

Sophie Alpert 說，在 Facebook 內部，他們比以往任何時候都重視 React Native，它已經被用於 Facebook 許多重要的專案上。包括他們最受歡迎的產品之一 Marketplace，每月有 8 億人使用。

React Native 也開始被應用在應用程式的其他地方，如果讀者上個月觀看了 F8 主題演講，就會發現 Blood Donations、Crisis Response、Privacy Shortcuts 和 Wellness Checks 的所有新功能都是使用 React Native 構建的。

Facebook 主應用以外的專案也在使用 React Native。新的 Oculus Go VR 頭戴式裝置對應的移動應用程式就完全使用 React Native 構建。

Sophie Alpert 表示，React Native 的目標從來都不是替代其他技術，他們專注於 React Native 自身，努力使之變得更好，但他們希望看到其他團隊從 React Native 中得到一些想法或靈感，例如將即時重新載入技術運用到非 JavaScript 程式碼中。

React Native採用的架構

React Native 專案的設計初衷是成為 JavaScript 和原生應用之間的橋樑。React DOM 將 React 的狀態更新變成了命令式、可變的 DOM API 呼叫，如 document.createElement(attrs) 和.appendChild()，而 React Native 則返回一個單獨的 JSON 訊息，它列出了要執行的一些操作，如 [[“createView”, attrs], [“manageChildren”, …]]。

他們將整個系統設計為永不依賴獲取同步響應，並確保列表中所有的內容都可以完全序列化為 JSON，並可以反序列化回來。

這樣做是為了提高靈活性：在這個架構之上，可以構建像 Chrome 偵錯程式之類的工具，這些工具可以通過 WebSocket 連線非同步執行所有的 JavaScript 程式碼。

在過去的 5 年裡，他們發現最初的設計原則加大了某些特性的開發難度。非同步橋接（asynchronous bridge）意味著不能直接將 JavaScript 邏輯與很多原生 API 整合在一起，因為這些原生 API 是同步的。

批量橋接（本地呼叫佇列）意味著 React Native 應用程式呼叫本地函式會更加困難。而且序列化的橋接意味著不必要的複製，因為它不是直接在兩個世界之間共享記憶體。對於完全使用 React Native 構建的應用程式，這些限制通常是可承受的。但對於在 React Native 與現有應用程式程式碼之間進行復雜整合的應用程式，就很糟糕了。

因此，Facebook 正在對 React Native 進行大規模重構，讓框架變得更加靈活，並更好地與 JavaScript / 原生混合應用中的原生基礎設施整合。

通過這個專案，他們將應用在過去 5 年中學到的知識，逐步讓架構走向現代化。他們正在重構 React Native 內部，大部分工作都是在底層進行的，現有的 React Native 應用程式幾乎不需要做出更改。為了使 React Native 更輕量化並能更好地適應現有的原生應用，此次重構主要從三個方面進行。

首先，改變執行緒模型。UI 更新不再需要在三個不同的執行緒上執行，可以在任意執行緒上同步呼叫 JavaScript 進行優先更新，同時將低優先順序工作推出主執行緒，以便保持對 UI 的響應。

其次，將非同步渲染功能引入 React Native 中，允許執行多個渲染並簡化非同步資料處理。

最後，簡化橋接，讓它更快、更輕量。原生和 JavaScript 之間的直接呼叫效率更高，並且可以更輕鬆地構建除錯工具，如跨語言堆疊跟蹤。

完成以上工作之後，就有可能帶來更緊密的整合。現在，如果不通過複雜 hack 的手段就無法讓原生導航和手勢處理或原生元件（如 UICollectionView 和 RecyclerView）一起工作。在對執行緒模型做出更改之後，就可以直接構建這樣的功能。

React Native重構線路

重構的細節

最近，Facebook官方公佈了一些RN專案重構上的細節，主要會從以下一些方面來推動專案的進行。

  1. 讓 RN 的 GitHub 存貯庫更健康，issues 和 pull 請求將及時得到處理；

  • 提高測試覆蓋率

  • 從 Facebook 程式碼儲存庫同步的 Commits 不能違背開源測試的準則

  • 提升社群的貢獻量

  1. 穩定 API，使之更容易與開源依賴項互動；

  • Facebook 使用與開源相同的公共 API

  • React Native 將遵循語義版本標準

  1. 讓生態系統更加有活力，社群將提供高質量的 ViewManagers、native modules、多平臺支援；

  2. 文件優化，專注於幫助使用者建立高質量的體驗，以及最新的 API 參考文件。

RN 團隊的目標是通過刪除非核心和無用的元件來簡化 RN，將非核心元件轉移到社群，讓開發者使用更加便捷，他們目前已經決定將這些元件的所有權為社群所擁有：github.com/react-nativ…

例如，WebView就是其中的一個例項：
WebView元件剝離

同時，為了更好的服務React Native，React Native官方將從以下幾個方面進行優化。

開源內部開發工具

由於 Facebook 內部開發人員用的是內部開發工具，開發體驗與開源的完全不同，在開源社群受歡迎的那些工具可能並沒有被 Facebook 開發人員使用，在某些情況下，Facebook 團隊已經習慣使用僅限 Facebook 內部使用的工具，這種內外差異可能會很大程度影響他們接下來的重構工作。

為此，他們做了如下改進：

  • 開源 JSI，使社群能夠使用自己的 JavaScript VMs，從 RN 的初始版本中替換現有的 JavaScriptCore，有關 JSI 的資訊，他們未來會公佈，現在你可以先通過 React Conf 大會上的演講視訊瞭解：www.youtube.com/watch?v=Ucq…

  • 支援 Android 上的 64 位庫；

  • 新架構下支援除錯；

  • 改進對 CocoaPods、Gradle、Maven 和新 Xcode 構建系統的支援。

改善測試基礎設施

當 Facebook 工程師釋出程式碼時，如果通過所有測試，則認為程式碼可以上線了，這些測試可以判斷某些改動是否會破壞 React Native，由於 Facebook 使用 React Native 的方式與外部存在差異，他們可能在不知不覺中破壞了開源環境中的 React Native。

為此，Facebook 將支援內部測試，確保它們在儘可能接近開源的環境中執行。這將有助於防止被破壞的程式碼開源。同時，他們還將致力於建設測試基礎設施，以便在 GitHub 上更好地測試核心儲存庫，使未來的 pull 請求能夠包含在測試裡。

公共 API

Facebook 將通過公共 API 使用 React Native，和開源一樣，以減少無意間的破壞性更改，他們的目標是融合穩定的公共 API，並在 v1.0 中採用語義版本控制標準。

反饋交流

React Native 是 GitHub 上貢獻者數量最多的開源專案之一（排名第二），未來，Facebook 將繼續致力於貢獻者相關的舉措，例如提高透明度和公開討論。對新手來說，文件將是一個大問題，為此，RN 將建立自動生成的 API 參考文件，改善使用者體驗。

RN 團隊稱，這些專案將在明年完成，其中，JSI 專案已經在進行中，其他的一些改進如簡化 RN，還需要更多的時間去完成，開發者有任何問題可以在提案中討論，以下是連結地址。

注，本文來自於《React Native官網》。如果你對RN有興趣，或者還停留在觀望和入門的邊緣，可以看一些我之前的書《React Native移動開發實戰》，如果有任何技術問題，也可以進群交流：515980159。

相關文章