一，什么是熱更新

所謂熱更新，也叫做動態(tài)更新，一種類似 Web 的更新方式。相對于 App 的發(fā)版更新而言，熱更新能及時的修復(fù)線上存在的問題，大幅的提升業(yè)務(wù)迭代效率。我們都知道，互聯(lián)網(wǎng)業(yè)務(wù)講究兵貴神速，如果業(yè)務(wù)能夠通過熱更新來快速發(fā)版和迭代，這就相當于在產(chǎn)品和用戶之間搭建了一座能夠隨時通行的橋梁，代替了原來好幾周才能有一次迭代的問題。

那么，熱更新和發(fā)版更新有什么不同呢？為什么熱更新比發(fā)版更新快這么多呢？下面是這兩種更新方式的原理對比圖。

發(fā)版更新，指的是你把 React Native App，當作 Android App 和 iOS App，按照 Android、iOS 上架流程，通過各自的應(yīng)用商店進行更新。通常每個 Native App 都會有一個自己的上架節(jié)奏，可能是兩周，也可能是 4 周。此外，從提交應(yīng)用商店到審核通過，也需要等上幾天時間。甚至，即便新版本上架了，用戶更新到最新版本也需要一個過程，可能需要一個月的時間，新版本才能覆蓋到 90% 的用戶。

所以說，如果你的 React Native App 選擇發(fā)版更新，就會受到發(fā)版節(jié)奏、審核耗時和版本覆蓋耗時的影響，這些都會導(dǎo)致業(yè)務(wù)迭代速度變慢。

不過，React Native 的熱更新就可以繞過應(yīng)用商店直接進行更新。只要你的是集成熱更新功能的 React Native App，在應(yīng)用商店上架過一次之后，后續(xù)你的業(yè)務(wù)都可以走你自己的熱更新流程，再也不用依賴應(yīng)用商店發(fā)版。這樣你的業(yè)務(wù)就能隨時上線，隨時更新了。

二，熱更新方案

雖然官方?jīng)]有提供標準的熱更新方案，不過能夠支持常見熱更新方案有pushy、CodePush、Expo 和自研。

不過，由于國內(nèi)網(wǎng)絡(luò)環(huán)境的原因，訪問國外的云服務(wù)速度比較慢，所以我不太推薦直接使用 Code Push 和 Expo。Code push 是微軟 App Center 的服務(wù)之一，它底層用的是微軟自家的 Azure 云服務(wù)；Expo 使用的是亞馬遜的 AWS 和 Google Cloud 云服務(wù)。

不過，大家也可以基于 Code Push 或 Expo 自行搭建熱更新服務(wù)。如果你嫌自己搭建太麻煩，你也可以看看 React Native 中文網(wǎng)提供的 Pushy 熱更新方案。它使用的是國內(nèi)的阿里云服務(wù)，且有比前兩者更省流量的差量更新方案，應(yīng)該是國內(nèi)目前市面上唯一可以直接使用的開源熱更新方案了。

三，熱更新原理

說到自研熱更新平臺，如果你沒有接觸過，可能會認為很難，但事實上并非如此。其實，自研熱更新平臺的難度主要體現(xiàn)在如何大規(guī)模應(yīng)用上，還有到達率上。對于規(guī)模小的應(yīng)用來說，搭建一個自研熱更新平臺本身并不是很難。總的來說，一個自研熱更新平臺，主要包括這兩個部分：

• 打包服務(wù)：Bundle Server；
• 靜態(tài)資源服務(wù)：Static Server。

所謂的打包服務(wù)，是將 React Native 項目中的所有 JavaScript 代碼打包成一個 Bundle 文件的服務(wù)。而所謂的靜態(tài)資源服務(wù)，是將 Bundle 文件分發(fā)給客戶端的服務(wù)；當客戶端拿到 Bundle 代碼后，執(zhí)行 加載Bundle 文件就能渲染 React Native頁面了。

其實，這和我們本地的npm start的流程是一樣的。即我們在本地通過 npm start 啟動的 Metro 服務(wù)時，Metro 服務(wù)就同時具備了打包和靜態(tài)資源下發(fā)兩種功能，再配合框架默認的代碼加載功能就完成了熱更新。

也就是說，找臺服務(wù)器把 React Native 代碼放上去，然后運行 npm start 命令，然后在客戶端配置對應(yīng)的 ip 和端口號，并把相關(guān)的調(diào)試開關(guān)給關(guān)了，接著訪問服務(wù)器就能把 React Native 頁面渲染出來。

當然，這個最簡單的熱更新流程是不能跑在線上的，畢竟 npm start 的本意是用于調(diào)試的，它的首次加載耗時太長，扛不住高并發(fā)，而且服務(wù)可用性也是問題。

四，CDN 熱更新方案

不過，使用npm start 的熱更新方案不太靠譜，那有沒有靠譜點的熱更新方案呢？有，那接下來我們看另一種比較簡單的熱更新方案：CDN 熱更新方案。

在 npm start 方案中，Metor Server 提供了代碼打包和 Bundle 下發(fā)的功能。而在 CDN 方案中，代碼打包是通過 react-native bundle 命令提供的，Bundle 下發(fā)的能力是通過 CDN 提供的。

下面是使用CDN熱更新方案的流程：

首先，通過 react-native bundle 命令把 JavaScript 代碼打包成一個 Bundle文件，命令如下：

npx react-native bundle --entry-file index.tsx --dev false --minify false --bundle-output ./build/index.bundle --assets-dest ./build

通過上述命令打包出來的是 index.bundle 文件，本質(zhì)是一個可執(zhí)行的 JavaScript 文件。如果你使用的是 Hermes，那么還需要把 JavaScript 文件轉(zhuǎn)成相應(yīng)的字節(jié)碼文件。Hermes 提供了把 JavaScript 文件轉(zhuǎn)成字節(jié)碼文件的方案，你可以先按照官方文檔 搭建 Hermes 環(huán)境，然后執(zhí)行如下命令進行轉(zhuǎn)換：

hermes -emit-binary -out ./build/index.hbc ./build/index.bundle

接下來，就是將包上傳到 CDN 上，國內(nèi)比較出名的有阿里云、騰訊云，或者使用公司內(nèi)部的提供的 OSS 和 CDN 服務(wù)也是可以的。

以阿里云為例，在第一次使用時，你可以先將包文件上傳到 OSS，然后開啟 CDN 加速。 完成文件上傳 CDN 這一步后，你將會得到一個 CDN 地址，我們可以使用該地址來訪問你的文件，例如：

https://static001.geekbang.org/resource/rn/index.bundle

拿到包地址后，熱更新最后一步是，在客戶端請求和加載該地址的 .bundle 文件或 .hbc 文件，這樣就完成熱更新的整個流程了。

如果需要執(zhí)行熱更新，我們只需要用新包把老包給覆蓋掉即可，當客戶端在加載的時候，會自動加載最新的包，從而完成熱更新。

五，純 CDN 方案的弊端

但是對于大流量業(yè)務(wù)，我并不推薦你用純 CDN 方案，為什么呢？因為純 CDN 方案，會存在幾分鐘的更新延遲的問題。在小流量業(yè)務(wù)中，這種幾分鐘的更新延遲不是什么問題，但是對于大流量業(yè)務(wù)來說，如果線上出現(xiàn)了一個重大 BUG，需要等幾分鐘才能完全回滾，那么對用戶或者收入的影響會很大。

下圖演示了CDN 方案的時序圖：

上述時序圖中，涉及 React Native App、CDN 邊緣節(jié)點和 OSS 源站，以及 index.bundle 包文件的兩個版本。舊版本包是綠色的，新版包是藍色的。將舊版本更新為新版本的本質(zhì)是：刪除 CDN 中緩存的舊版資源，當 CDN 中沒有緩存了，這時來自用戶的請求才不會命中 CDN 中的緩存，而是到 OSS 上拉取最新的資源，返回給 React Native App。

然而，我們都知道 CDN 指的并不是某一臺具體的機器，它指的是上千個分布在全國各地的節(jié)點網(wǎng)絡(luò)。當我們使用 CDN 的刷新能力時，實際上是刪除上千個節(jié)點中的緩存。一位負責 CDN 的同學(xué)告訴我，要把這上千個節(jié)點的緩存都刪除干凈的時間，最長可能需要個 5 分鐘吧，而且還不敢保證 5 分鐘的時效性。因此，在這 5 分鐘內(nèi)，會存在三種情況：情況一，命中老版緩存；情況二，未命中緩存重新拉取新版資源；情況三，命中新版緩存；

六，線上方案

可以看到，不管是npm start 還是CDN方案，都存在一定的缺陷，那有什么比較完整的方案嗎。其實仔細思考一下，只需要在CDN 方案解決延遲問題即可達到線上運行的需求，那如果改進CDN 方案呢。

解決方案就是多發(fā)一次版本請求：既然上千個節(jié)點 CDN 更新有延遲，那么就自己搭建一個版本服務(wù)，資源依舊上傳 CDN，然后用我們自己的版本服務(wù)來控制更新。此時，熱更新的時序圖變成如下：

增加一個版本服務(wù)后，可以看到整體流程發(fā)生了一些變化。純 CDN 方案的更新方式采用的是覆蓋更新，版本服務(wù)方案會提前告知更新，從而保持代碼的最新。那接下來，我們梳理下這種方案的完整流程。

1，上傳 Bundle 到源站，也就是 OSS
先在將本地打包好 Bundle 文件，并將文件命名為 “MD5”.bundle 上傳到 OSS 源站。此時理論上，只要 Bundle 內(nèi)容發(fā)生了變化，那么生成 MD5 值就是不一樣的，用 MD5 作為文件的命名能保證文件的唯一性。

2，正式發(fā)版上線
當需要正式上線時，我們只需要上傳前面生成的bundle包，然后將服務(wù)最新的線上 Bundle 的名字修改成最新的，這時版本服務(wù)會在內(nèi)部通過 mysql 或 redis 把線上最新文件名給記錄下來。

3，React Native App 發(fā)起版本請求
由于只有一個版本服務(wù)，不會存在 CDN 上千個節(jié)點在某一時刻不同步的問題，版本服務(wù)會直接把最新的 Bundle 名字告訴 React Native 應(yīng)用。

4，React Native 發(fā)起 CDN 資源請求
資源請求會先詢問某個 CDN 的邊緣節(jié)點，如果該邊緣節(jié)點沒有緩存，則會去源站拉??；如果該邊緣節(jié)點有緩存，則直接返回。

七、整體方案梳理

事實上，無論是 CDN 熱更新方案，還是官方的版本方案，它們都不是完整的自研熱更新方案，只是提供了一種解決基礎(chǔ)資源更新的問題。因為自研熱更新平臺的核心難點在于，它需要你對前端、Node.js、React Native，甚至 Java 都有所了解，特別是在熱更新服務(wù)這一塊要特別的擅長。涉及的難點包括：

• 如何支持多人的并行打包；
• 如何支持多人的并行測試；
• 如何保障 CDN 資源更新成功；
• 如何保障版本服務(wù)的高并發(fā)、高可用。

依據(jù)多年的經(jīng)驗，我們設(shè)計了一張熱更新平臺的全貌圖。

可以看到，熱更新平臺整體上包括以下幾個部分：

• 熱更新平臺后臺服務(wù)：一般兩臺機器就行，它提供打包、測試、上線、權(quán)限管理和相應(yīng)的前端頁面展示等能力。
• MySQL、Redis持久能力：MySQL 提供持久化存儲能力，Redis 用于緩存用來抗高并發(fā)，這里推薦用成熟的相關(guān)服務(wù)就行，不要自行搭建。
• 打包集群：獨立集群，至少兩臺機器，具體看情況而定，用于支持多人的并行打包。把它獨立出來的原因是，打包是非常消耗 CPU、內(nèi)存資源的任務(wù)，和其他服務(wù)混在一起容易導(dǎo)致其他服務(wù)卡頓。
• 版本服務(wù)集群：獨立集群，用于提供能支持高并發(fā)的版本服務(wù)。如果你有 node.js 抗高并發(fā)的經(jīng)驗，可以使用 node.js 來做，或者直接找 Java 同學(xué)開發(fā)。

接下來，就是搭建熱更新平臺，我推薦的技術(shù)棧有：

• NestJS ：它是一個 Node.js 框架 ，它能提供高效、可靠和可擴展的后端服務(wù)。
• Bull：它一個任務(wù)隊列庫，它能幫你解決熱更新平臺后臺集群如何向打包集群發(fā)布打包任務(wù)的難題，讓你的平臺可以支持多人并行打包。

八，總結(jié)

要實現(xiàn) React Native 熱更新功能，有四種思路 Code Push、Pushy、Expo 和自研。如果你選擇自研 React Native 熱更新功能，這就需要 React Native 熱更新平臺和 Native 熱更新模塊的緊密配合。

自研 React Native 熱更新功能，并不一定需要搭建一個熱更新平臺，你也可以采用純 CDN 方案，比如你可以利用阿里云提供的靜態(tài)資源部署能力和對應(yīng)的 CDN 服務(wù)。如果決心要完全自研一個熱更新平臺，那么你最好找一個對后端技術(shù)比較了解同學(xué)一起來設(shè)計，我也為你提供了一個熱更新平臺的全貌圖，你可以用它來幫你進行整體設(shè)計。

到此這篇關(guān)于搭建React Native熱更新平臺的文章就介紹到這了,更多相關(guān)React Native熱更新內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論