Unity熱更新介紹和測試方法

最近項目中增加了熱更新了功能，程序也完成了相應的開發，接下來就需要對這個模塊進行相應的測試工作了，在測試開始之前，了解下其原理總是很有好處的。

1.什么是熱更新

簡單的理解就是：用戶重啟客戶端就能實現客戶端更新的需求或者功能；或者也可以這樣說：不需要通過在應用商店更新應用，就可以實現新的需求和功能。

2.為什么要熱更新

能夠縮短用戶取得新版客戶端的流程，改善用戶體驗。

就拿iOS來說，如果你需要更新應用，需要經過一系列的蘋果提審流程，少則幾天，多則一個月，審核周期比較難控制。試想下，如果你的上線游戲出現了一個嚴重的bug，此時如果沒有熱更新，那么只有兩種選擇：

第一種：提交更新包到應用商店，等審查（時間不受自己控制）

第二種：坐視不管

無論哪種方式，你都應該清楚，可以提前準備簡歷和打包行李了。

還有一個原因，對于大型游戲來說，玩家更新成本太大。App Store上，你更新一個應用，其實是重新下載一次，而不是增量的更新。

如果有了熱更新機制會怎么樣呢？你可以通過熱更新推送給每一個用戶，在較短的時間（自己控制）內解決這個bug。領導對你十分肯定，走上人生巔峰指日可待了。

3.熱更新分類

熱更新一般可以分為美術資源熱更新和代碼熱更新。美術資源熱更新的方案一般就是采用AssetBundle方式。代碼熱更新方案一般可以分為以下兩種方法：

第一種方案：

（1）項目開發中，可以將部分邏輯提取至一個單獨的代碼庫工程中，打包為DLL；

（2）將DLL打包為AssetBundle；

（3）Unity程序動態加載AssetBundle中的DLL文件，使用Reflection機制來調用代碼。

這個方案看起來很完美，能支持C#級別的代碼熱更新，但是它有限制：蘋果官方禁止Ios下的程序熱更新；JIT在Ios下無效。所以這個方案在Android下還是可以用用的。但是一般情況下，一個項目不可能為Android和Ios開發兩套不同的熱更新方案，所以這個方案實際上也就無法應用到項目之中了。

-- ---------

ps：稍微解釋下AssetBundle這個概念，因為這個不是本文的主要目的，今后如果大家有興趣的話，我再對AssetBundle進行詳細的解釋。

AssetBundle：Unity支持的一種文件儲存格式，也是Unity官方推薦的資源存儲與更新方式，它可以對資源(Asset)進行壓縮，分組打包，動態加載，以及實現熱更新，但是AssetBundle無法對Unity腳本進行熱更新，因為其需要在打包時進行編譯。

-----------

第二種方案：

lua插件。在Unity環境里內嵌一個lua虛擬機，經常變動的和對執行效率沒要求的邏輯用Lua實現，游戲啟動時加載服務器上最新的lua字節碼來執行游戲。lua代碼都是運行時才編譯的，不運行的時候就如同一張圖片、一段音頻一樣，都是文件資源；所以更新邏輯只需要更新腳本，不需要再編譯，因而lua能輕松實現“熱更新”。

按照這個邏輯來說，其實諸如python，javascript等腳本語言的話，都是可以實現這個功能的。只不是目前幾個開源的、成熟的熱更新方案都是基于lua的。

-----------

ps：這里你可能需要對腳本語言和編譯性語言的區別進行一個大致的了解。這個網上解釋很多，自行google就好。

-----------

4.熱更新的原理

熱更新主要的原理有2個：

（1）lua是一種腳本語言，不需要事先進行編譯，而是直接讀取文本文件，一邊解釋一邊執行；

（2）Application.persistentDataPath目錄是一個可讀寫目錄，可以將需要熱更新的資源和代碼下載到這個目錄中，當游戲中使用這個對象的時候，首先檢查是否在這個目錄中存在，存在的話，則運用這個新的資源，不存在的話就是使用原先的。

5.熱更新基本流程

簡要說下目前我們項目的一個熱更新基本流程：檢測補丁—>下載補丁—>應用補丁。

檢測補?。喊ㄊ欠裥枰?，需要更新哪些文件；

下載補?。焊鶕a丁檢測的結果，到patch服務器下載對應的更新zip包；

應用補?。航鈮簔ip包，將補丁運用到游戲中。

-----------

ps：這里要特別說明下，lua文件的存放位置：

一般情況下我們將lua文件存在放StreamingAssets文件夾中。在不同的平臺上面(Windows, Ios ,Android)，StreamingAssets目錄最終發布的位置不同，所以讀取的方法也不同。

在iOS中，我們可以通過文件流的方式讀取lua腳本，但在Android下，不支持C# IO流方式讀取StreamingAssets下的文件，因為Android手機中StreamingAssets下的文件都包含在壓縮的.jar文件中（這基本上與標準的zip壓縮文件的格式相同），這意味著，如果你不使用Unity中的www類去檢索文件，那么你需要使用額外的軟件去查看.jar的存檔并獲取該文件。但是unity項目中，我們需要盡量減少www的使用，www的使用會增大mono內存池。那么怎么辦呢？所以在Android下，我們進行了特殊處理，將所有的lua腳本都提前復制到Application.persistentDataPath目錄下，然后再通過IO流去訪問。這里再啰嗦一句，剛提到的StreamingAssets目錄是一個只讀的文件，Application.persistentDataPath目錄是一個可讀寫的目錄，熱更新的實現原理也主要是用到了Application.persistentDataPath目錄可讀寫的特性。

此外你可能還需要了解unity項目中，一些基本目錄的含義。

-----------

6.熱更新測試

這次測試我采取了白盒測試和黑盒測試相結合的測試方案。

白盒測試：通過review熱更新的相關代碼，在各個判斷條件處加入debug log，同時根據if的判斷條件，構建不同的測試環境，保證每一個路徑都覆蓋到。例如：各種網絡狀態不對的提示是否正確；patch服務器各種狀態的提示是否正確；patch文件各種狀態的提示是否正確；

黑盒測試：模擬玩家正常的操作流程，同時結合中途打斷，斷網等異常的操作。

還有一個測試的時候的小技巧：當通過補丁構造腳本完成補丁構造后，怎么通過實際的運行游戲查看補丁是否被正確應用呢？這里我采取了一個猥瑣的方法，就是通過手動解開patch包，然后在其中塞入自己手動的lua腳本和bundle，再手動壓縮成patch包，供下載更新。其中自己手動加入的lua和bundle就可以很方便的實現加入一些調試用的log信息等，這樣在運行游戲的時候，就能方便的識別出熱更新是否成功了。

7.提外話

值得注意的是，即使是使用lua，仍然是不符合appstore的政策，依然存在被下架的風險。

目前發生的JSPacth事件，就是很好的說明。3月8號左右，不少開發者都收到了蘋果的警告郵件，在郵件中，蘋果稱開發者使用了動態代碼更新技術，要求開發者刪除相關代碼，并重新提交一個新的App版本以供審核。雖然最后是虛驚一場，只是針對使用了JSPatch的相關應用。那為什么同樣是熱更新，JSPatch就收到了蘋果的警告呢？JSPatch可以理解為所有的Objective-C的API進行了映射，允許開發者在JS端調用任意原生代碼，這顯然是極其危險的。假設這段代碼是通過熱更新技術下載執行的，如果在中間存在黑客，把這段代碼動態替換掉，比如修改為獲取用戶通訊錄并上傳到黑客的服務器，就會造成重大的安全問題。

那諸如我們使用的lua熱更新為什么就可以被理解為是安全的呢？與JSPatch不同的是，lua熱更新技術主要的實現方式是把動態腳本下載之后，讓動態腳本調用游戲引擎提供的接口實現缺陷修復。與JSPatch不同的是，動態腳本并不能任意調用全部原生代碼，而是只能根據游戲引擎提供的接口調用相關功能。在這個過程中，游戲引擎的原生端作為一個安全沙箱，提供了一個安全的保護層，只要游戲引擎不要對外提供獲取通訊錄的接口，黑客就無法通過替換動態腳本的方式獲取用戶的隱私資料。進而可以被認為是安全的，自然不在蘋果的禁止范圍內。

本文來自網易實踐者社區作者：朱潔