前言

本文主要引用cocos關于熱更的官方文檔，并在此基礎上，總結sprout當前熱更流程。

什么是熱更

熱更（新）本質上是從服務器下載需要的資源到本地，并且可以執行新的游戲邏輯，讓新資源可以被游戲所使用，它可以使開發者在不發布新版本的情況下，修復 BUG 和發布功能，讓開發者得以繞開蘋果的審核機制，避免長時間的審核等待以及多次被拒造成的成本。

Cocos 默認的熱更新機制并不是基于補丁包更新的機制，傳統的熱更新經常對多個版本之間分別生成補丁包，按順序下載補丁包并更新到最新版本。Cocos 的熱更新機制通過直接比較最新版本和本地版本的差異來生成差異列表并更新。

cocos熱更概述

manifest

了解cocos熱更之前，先要了解manifest。在cocos中，manifest是一種文件格式，其對應的文件簡稱資源描述文件，是用來描述本地或遠程包含的資源列表及資源版本。

manifest格式是仿照json格式，其關鍵字段的含義如下 :

Manifest 文件可以通過 Cocos Creator 熱更新范例中的 Version Generator腳本 來自動生成。

工程資源和游戲包內資源的區別

大家在創建一個 Cocos Creator 工程的時候，可以看到它的目錄下有 assets 目錄，里面保存了你的場景、腳本、prefab 等，對應編輯器中的 assets 面板。但是這些工程資源并不等同于打包后的資源，在使用構建面板構建原生版本時，我們會在構建目錄下找到 res 和 src 文件夾，這兩個文件夾內保存的才是真正讓游戲運行起來的游戲包內資源。其中 src 包含所有腳本，res 包含所有資源。

所以我們的資源熱更新自然應該更新構建出來的資源，而不是工程的 assets 目錄。

在creator2.4.3中，重構了資源管理模塊，采用bundle模塊化管理資源。這里分享一個通過uuid來獲取資源路徑的API

searchPaths搜索路徑

在談到熱更之前，關于searchPaths的概念，有必要先了解一下。在大多數的時候，我們描述一個文件的路徑，都會基于一個”根目錄“去給到對應的”相對路徑“，并不會直接寫死成”絕對路徑“，這樣更利于維護、遷移。在游戲開發中，其實我們”根目錄“也是很難保證其確定性、唯一性。就拿熱更功能而言，我們有一個圖片，假設其對應bundle目錄（默認是resources）的相對路徑是 ”./png/icon1.png“，當我們游戲版本更新，需要更新該圖片的時候，由于包內的資源是不可寫的，那我們只能讓其從另外一個地方讀取到新的圖片，為了保證代碼的一致性，如果我們可以改變其對應的”根目錄“，那代碼中之前的相對路徑都不需要修改，就能找到新的圖片。

在creator中，其維護勒一套搜索路徑的策略。對應的API可以查閱jsb.fileUtils.getSearchPaths、jsb.fileUtils.fullPathForFilename等。這里簡述其原理。FileUtils中保存勒一個”根目錄“數組，index越低的優先級越高，在查找資源的時候，我們如果指定的是”相對路徑“，則其會按照searchPaths里面的”根目錄“的優先級，去拼接成”絕對路徑“去查找資源，如果路徑有效，找到勒文件，則會停止繼續尋找。

在游戲包的安裝目錄，肯定有一個目錄是存放我們打包后的各種腳本、資源，我們這里稱之為”游戲包目錄“，在熱更邏輯中，我們需要指定一個”熱更目錄“來存放我們熱更的內容，這兩個目錄都應該設為搜索路徑，并且需要控制版本，使優先級更高的目錄，對應的搜索路徑優先級也要越高，這樣，我們才能找到最新的文件。一般而言，”熱更目錄“的優先級需要高于”游戲包目錄“。

cocos的基礎熱更流程

這是cocos官網資料的流程圖，注意，當前流程是用戶安裝好 app 后，第一次檢查到服務端的版本更新的情況，完整的熱更流程會更為復雜一些，后面我們再慢慢補充。

本文主要幫助大家理解熱更本身的流程邏輯，其各個細節，如斷點續傳、下載進度、并發下載、錯誤檢測、解壓縮、錯誤恢復等細節問題，暫不討論。所以，把上訴流程圖，可簡單概況為：

根據當前包內的manifest的remoteVersionUrl字段，去下載其當前的版本描述文件，然后根據與本地的版本對比，若需要更新則更新到對應最新版本，不然就不需要更新，繼續后續流程。

這里需要對其幾個關鍵點，再細化剖析一下：

_localManifest：當前包內的manifest

首先，”游戲包目錄“內應該有一個默認的manifest文件，描述當前游戲版本（"version"字段），這個manifest一般隨游戲包卸載、安裝來更新。然后在”熱更目錄“也會有一個manifest文件，描述當前熱更目錄下的版本信息。我們每次啟動游戲的時候都應該判斷一下，當前環境下，到底是”游戲包目錄“，還是”熱更目錄“才是最新的版本，來調整其對應在searchPaths的優先級，較新的manifest也就稱為當前包內的manifest，代碼中用_localManifest來記錄。
注意，上述cocos基礎熱更流程中，并沒有這一步，是因為其表示流程是包第一次安裝的情況，熱更目錄下是沒有manifest文件，所以_localManifest就是”游戲包目錄“，完整的熱更流程是需要做這一步判斷的。
上訴邏輯對應的代碼，請參閱：AssetsManagerEx的init、loadLocalManifest等函數。

先請求遠端版本manifest

在manifest的”remoteVersionUrl“字段中，其對應的是遠端服務器的版本文件，下面給到官方demo的一個version.manifest，便于大家理解

從上面可以看到，version.manifest有一個“version”字段，這也是我們快速進行版本對比的依據。下載version.manifest，然后再與本地_localManifest的版本對比，來檢測當前包是否需要更新，這個過程代碼上一般命名為checkUpdate。

臨時文件夾的必要性

在熱更過程中，因為我們是多個資源依次下載的，這期間很可能出現各種問題，所有，我們需要一個臨時文件夾來暫存我們的下載，等到全部文件下載結束后，還需要檢測文件是否完整，才能去替換“熱更目錄”下的舊資源，不要直接在“熱更目錄”上下載，一旦出現問題，自己也搞不清那部分是新的，那部分是還是舊的。這種思路在程序設計中也可以借鑒體會，我們負責的一些數據、字段的維護，盡量能做到整體的替換更新，而不是到處隨意的去修改、賦值。

熱更是熱更差異化文件，是怎么做到這點的

在manifest文件中，"assets"字段下，記錄每個資源的key和md5信息，只需要遠端的_remoteManifest下記錄的資源進行對比，新的key則是新增資源，沒有的key則是需要刪除的資源，md5不同的就是需要更新的文件。
對應的代碼，請參閱：Manifest的genDiff等函數。

熱更好之后，怎么讓其生效

當我們熱更好了新的資源后，怎么在不需要調整代碼的情況下，讓其生效？哈哈，剛剛上文已經介紹過了，我們調整我們的searchPaths，讓“熱更目錄”優先級高于“游戲包目錄”即可。
上面的流程圖中，cocos推薦的是用cc.sys.localStorage把_localManifest對應的路徑存儲起來，并在后續app啟動的開始階段，就從cc.sys.localStorage讀取對應路徑，設置到searchPaths中。
上訴方案固然可行，但是就一個完善的客戶端框架而言，尤其是針對多子項目的大廳類游戲，個人認為這種動態存儲路徑、設置路徑并不是比較合適的方案。在架構設計上，我們需要先確定好整個客戶端的“熱更目錄”，并確定好優先級，即整個項目的searchPaths都是按照我們設定的邏輯固定好，而不是動態的去調整，這樣的好處是，在唯一的地方確定好searchPaths邏輯，之后僅需要根據邏輯，增刪對應路徑下的資源即可，這樣應該是更利于擴展和維護的。但同樣需要注意，這種固定好searchPaths的方案，在app安裝替換的時候，要維護好新的“游戲包目錄”的版本與之前“熱更目錄”下的版本對比情況，如，app本地安裝升級后的版本比之前“熱更目錄”的版本更高，可以考慮把之前“熱更目錄”下的資源都清空掉，另外一種更麻煩的邏輯是，app安裝升級后的版本還是比“熱更目錄”版本低，這是要注意，“熱更目錄”存儲的是相對于升級前“游戲包目錄”的差異化文件，升級后“游戲包目錄”下的文件發生變化，那“熱更目錄”下的差異化文件就不一定能兼容當前的“游戲包目錄”，這種情況也可以把“熱更目錄”情況，讓其重新去對比、熱更差異化文件。

舊的版本資源怎么處理

cocos的熱更的雖然是差異化文件，但是其manifest腳本是記錄勒對應bundle所有的資源，我們是能知道哪些資源已經不需要的，上文genDiff函數也提到過，但是個人認為，舊資源的刪除需要謹慎，至少也是確保新資源更新好后，再去刪除舊資源。

總結

如果讀者在消化勒上訴的一些知識后，利用cocos提供的基礎功能函數，是完全可以徹底定制自己的熱更流程的。熱更，一言以蔽之，下載最新的遠端資源替換當前包體內的就資源而已。比如一些小項目，完全可以整包的下載、替換，可以忽略其中版本對比、searchPath調整、文件校驗等細節。

以上就是全面講解CocosCreator熱更新的詳細內容，更多關于CocosCreator熱更新的資料請關注服務器之家其它相關文章！

原文鏈接：https://blog.csdn.net/qq_41211553/article/details/111559869