：原理、接入順序與真機排坑)
我到現(xiàn)在都記得第一次線上事故的場景一個已經(jīng)過審上架的手游運營活動發(fā)獎勵的數(shù)值公式少取了一次隨機數(shù)玩家領到的獎勵高了兩倍。服務端立刻封住漏洞但已經(jīng)安裝的客戶端代碼是死的發(fā)新版要走渠道審核少則一天多則一周那幾天項目組每個人臉上都寫著焦慮。那次之后我們整個團隊把“代碼熱更新”從“以后再說”提到了“下周必須驗證”的優(yōu)先級。最后選型、驗證、接入的方案就是今天這篇要聊的 Unity HybridCLR 熱更新。如果只用一句話介紹HybridCLR 是一個基于 IL2CPP 的 C# 熱更新方案它能讓你的 Unity 項目在不重新打包上架、玩家不重新下載安裝包的情況下通過加載一段新的 C# 程序集來更新游戲邏輯。這篇文章是我自己從零把一個 Demo 工程接入 HybridCLR再逐步推進到真實項目的完整記錄。重點不是重復官方文檔而是告訴你接入順序、依賴方向、AOT 泛型問題這些文檔里不容易一次講透的東西以及我踩過的坑長什么樣。如果你是想評估熱更新方案的技術負責人、正在給老項目接熱更的 Unity 客戶端同學或者剛被分配要驗證 HybridCLR 可行性的新手這篇應該能幫你省下不少試錯時間。讀完你應該能知道它和 Lua 熱更、和 IDE 里的熱重載到底什么關系接入前工程要做什么體檢真機上跑通一個最小熱更工程需要哪幾步以及第一輪真機崩潰該怎么查。1. 為什么是 HybridCLR而不是 Lua 或者熱重載1.1 IL2CPP 把代碼焊死在哪里要理解 HybridCLR 的價值先得知道 Unity 的 IL2CPP 到底做了什么。在沒有 IL2CPP 的 Mono 時代C# 代碼會被編譯成 IL運行時由 Mono 虛擬機解釋或 JIT 編譯執(zhí)行。那個年代想在 iOS 上做熱更新很麻煩因為蘋果明確禁止應用在自己的沙盒里動態(tài)生成可執(zhí)行代碼JIT 這條路在 iOS 上基本是堵死的。IL2CPP 是把 C# 先編譯成 IL再在構建階段把 IL 轉成 C最后隨原生工程一起編譯成目標平臺的機器碼。好處是啟動快、性能好、代碼不容易被直接反編譯成原始 C#壞處也藏在這里所有 C# 邏輯都在編譯期被翻譯并“焊死”進了原生二進制運行時已經(jīng)沒有一套能把新 IL 編譯成機器碼的機制了。這就好比你把菜譜都刻成了石碑讀者只能照著石碑做菜現(xiàn)在你拿到一張新菜譜卻沒有火源也沒有翻譯想按新菜譜做菜根本無從下手。HybridCLR 做的是在 IL2CPP 旁邊補了一個“解釋執(zhí)行器”讓新拿到的 C# 程序集也就是熱更 dll里的 IL 字節(jié)碼不經(jīng)過 JIT 也能被逐條解釋執(zhí)行。1.2 它和 xLua、ILRuntime 的本質差異很多團隊第一次聊熱更新聽到的往往是 xLua、tolua或者純 C# 的 ILRuntime。這里我直接按實際感受做個比較。Lua 方案的核心是“換語言”業(yè)務邏輯不寫在 C# 里而是寫 Lua運行時由 C# 側的虛擬機解釋執(zhí)行。好處是生態(tài)成熟、很多老項目都在用代價是整個項目的核心玩法可能要從 C# 平移成 Lua維護一套雙語言邏輯團隊里每個人都要會 Lua出問題時要跨語言查堆棧代碼補全和重構也不夠舒服。ILRuntime 是純 C# 的解釋器方案不需要換語言但它和 Unity 的 AOT 世界之間隔了一層自己的運行時對某些 C# 特性的支持以及對 Unity 引擎調(diào)用、泛型、值類型結構的處理需要開發(fā)者額外注意。性能和兼容性一直在進步但遇到冷門邊界總有“為什么這里不行”的疑惑。HybridCLR 選擇的是另一條路線盡可能貼近原生 CLR 的實現(xiàn)方式在 IL2CPP 的 AOT 基礎上加一個解釋器模塊并且用“補充元數(shù)據(jù)”的方式解決 AOT 泛型缺失的經(jīng)典問題。用下來最直觀的感受是它不是讓你把邏輯翻譯成另一種語言而是讓熱更 dll 里的 C# 代碼自己跑起來和主工程的 C# 代碼寫法差別不大。對比項Lua 系方案ILRuntimeHybridCLR業(yè)務語言Lua C#C#C#與 IL2CPP 關系獨立虛擬機獨立解釋器基于 IL2CPP 補充解釋能力學習成本需要掌握 Lua較低但邊界概念多較低重點是理解 AOT 與熱更分界泛型等邊界問題不受 IL2CPP 泛型影響有自己的處理通過補充元數(shù)據(jù)解決大多數(shù)社區(qū)活躍度高但偏向舊項目中高近幾年增長很快需要客觀說的是HybridCLR 本質上是修改了 Unity 的 IL2CPP 構建鏈路Unity 版本升級、IL2CPP 內(nèi)部實現(xiàn)調(diào)整都有可能影響它。所以它不是一個“裝一次永遠不用管”的方案每次 Unity 升級或 HybridCLR 升級都要做回歸驗證。這點后面章節(jié)會細說。1.3 先理清“熱更新”和“熱重載”不是一回事熱搜詞里出現(xiàn)了不少和熱更新相關的詞比如 Flutter 熱重載、IDEA 修改代碼熱更新、Nacos 配置熱更新。這些詞經(jīng)常被混在一起但它們解決的問題完全不同。Flutter 的熱重載本質是開發(fā)期工具改完代碼按一下 R開發(fā)進程把新的 widget 樹推給正在運行的調(diào)試 App幫開發(fā)者快速看 UI 效果。它不面向線上玩家代碼改動只在開發(fā)環(huán)境里生效。IDEA 里修改 Java 代碼后的熱更新是讓本地開發(fā)服務器不用重啟就能加載新類屬于開發(fā)效率工具的范圍。Nacos 配置熱更新更新的是配置項不是程序邏輯本身。而 Unity 項目里說的“代碼熱更新”指的是已經(jīng)安裝到玩家手機上的 App在不發(fā)新包的前提下從服務器拉取新的 C# 程序集并在本地執(zhí)行新邏輯。這是玩家可見的能力直接關系到線上事故的處理速度和上面那些開發(fā)期工具完全不是一個維度。所以有些同學問“我項目里用 IDE 熱重載很順是不是就不用 HybridCLR 了”答案顯然是否定的。2. 接入前先給工程“體檢”程序集、依賴方向、泛型用法2.1 依賴方向熱更代碼能引用什么不能引用什么接入 HybridCLR 最容易犯的錯是直接拿一個已經(jīng)寫了兩三年的老工程把所有代碼都掃進熱更程序集然后開始打包。正確的第一步是給工程劃分程序集邊界。Unity 項目里用 asmdef 把代碼分成多個程序集主工程里有一套專門給熱更代碼用的接口和公共代碼熱更代碼所在的程序集可以引用主工程的公共程序集但主工程的 AOT 代碼絕對不能反過來引用熱更程序集里的類型。一旦主工程靜態(tài)引用了熱更代碼里的類打 IL2CPP 包時就會把熱更代碼一起編進去后續(xù)想替換邏輯就會非常別扭。我在項目里習慣的分層是這樣的AOT 主程序集啟動流程、SDK 對接、資源管理、渲染相關、游戲的底層框架。AOT 公共接口層純接口和 DTO 定義比如戰(zhàn)斗結算接口、活動模板接口供熱更代碼實現(xiàn)或調(diào)用。熱更程序集賽季玩法、活動界面、數(shù)值表現(xiàn)、任務系統(tǒng)這類需要頻繁調(diào)整的邏輯。依賴方向是熱更層可以引用 AOT 公共接口層AOT 公共接口層不能引用熱更層。因為熱更層是運行時才被加載的AOT 側的代碼在編譯期根本不知道它的存在兩者之間只能靠接口或反射溝通。2.2 重點檢查一遍泛型使用習慣體檢時另一個重點是泛型。C# 泛型在 AOT 編譯下有個天然矛盾IL2CPP 編譯器在打包時只會為主工程代碼里“顯式出現(xiàn)過的泛型實例化”生成機器碼。如果熱更代碼運行時突然出現(xiàn)一個 AOT 模塊里從未實例化過的泛型組合比如DictionaryMyStruct, intIL2CPP 那邊并沒有對應的目標代碼運行時就會報類似AOT generic method can not be instantiated的錯誤。HybridCLR 的解法是“補充元數(shù)據(jù) 解釋器兜底”。打包時項目會帶上 AOT 必需 dll比如 mscorlib、System、UnityEngine.CoreModule 這些的元數(shù)據(jù)運行時先加載這些元數(shù)據(jù)讓解釋器能夠自己解析泛型方法的 IL 并執(zhí)行而不是必須依賴 IL2CPP 現(xiàn)成的機器碼。這并不代表你可以完全無視泛型。我建議在接入前把項目里“值類型 泛型容器混用”的地方掃一遍。比如大量使用Listint、Dictionaryint, MyEnum、Dictionarylong, MyStruct尤其是這些結構體是活動邏輯里臨時定義的時候要格外留意。這里不是說不能用而是你要意識到這類代碼會觸發(fā) AOT 泛型補充機制線上報錯后排查成本會高一些。2.3 確認版本兼容與目標平臺體檢還包括兩個基礎問題項目用的 Unity 版本以及 Scripting Backend 是否已經(jīng)是 IL2CPP。HybridCLR 只支持 IL2CPPMono 后端不在討論范圍內(nèi)。Android 項目由于現(xiàn)在 Google Play 和國內(nèi)渠道對 Target API Level 的要求越來越高很多項目把target API level提到了 33、34、35這個過程中只要正常使用 IL2CPP 并勾選 ARM64不會和 HybridCLR 產(chǎn)生直接沖突。但如果是很老的項目一直跑在 ARMv7 或 Mono 上最好先把構建鏈路切干凈再談熱更。Unity 版本建議盡量用 LTS比如 2021.3 LTS、2022.3 LTS 或官方文檔當前明確支持的版本。HybridCLR 的發(fā)布節(jié)奏通常能跟上主流 LTS用非 LTS 版本容易遭遇兼容性盲區(qū)。安裝時下載的是focus-creative-games/hybridclr_unity這份 Unity 側工程代碼版本要和項目 Unity 版本匹配別隨手拉最新版就往老項目里塞。3. 真機跑通全流程一個最小可熱更工程的搭建記錄3.1 安裝包和 Installer 到底做了什么接入時首先通過 Unity Package Manager 用 Git URL 把 HybridCLR 的 Unity 包加到工程里。拉取成功后菜單欄會出現(xiàn) HybridCLR 相關的入口。接下來執(zhí)行的是 HybridCLR - Installer這一步會往工程里寫一些必要的代碼更關鍵的是它會修改本地的 IL2CPP把解釋器相關模塊合入 il2cpp 的構建鏈。也就是說它不只是往 Assets 里加幾個腳本還動到了 Unity 編輯器安裝目錄下的 il2cpp 相關文件。這里有兩個容易踩的點。第一Installer 執(zhí)行時如果 Unity 正在占用相關文件或者殺毒軟件攔截了對安裝目錄的修改安裝可能“假成功”。我遇到過安裝后 Generate 時各種詭異報錯重裝一次 HybridCLR 就好了。建議執(zhí)行完 Installer 后先做一次簡單的生成操作驗證而不是直接開始打大包。第二升級 Unity 小版本后最好重新執(zhí)行 Installer。IL2CPP 內(nèi)部文件結構會隨版本變化舊的補丁不一定還能用。我們項目從 Unity 2021.3.16 升到 2021.3.31 時因為漏了這一步打出來的包初始化階段直接崩潰排查了半天才發(fā)現(xiàn)是 installer 沒重跑。3.2 創(chuàng)建熱更程序集并在 Settings 里登記HybridCLR 需要知道哪些程序集要被當作熱更程序集處理。官方推薦用 asmdef 組織但不是把文件夾命名為 HotUpdate 就行而是在工程里建一個真正的 Assembly Definition。我的做法是在 Assets 下建兩個目錄Assets/Scripts/Main主工程邏輯里面放Main.asmdef。Assets/Scripts/HotUpdate熱更邏輯里面放HotUpdate.asmdef。由于 HotUpdate 需要引用 Main 里定義的類型和接口在HotUpdate.asmdef的 Assembly Definition References 里加上 Main反之 Main 里不要引用 HotUpdate。這樣主工程干凈熱更程序集可以隨意引用它依賴的 AOT 庫。創(chuàng)建好 asmdef 后打開菜單HybridCLR - Settings把 HotUpdate 加進熱更新程序集列表。Install 時官方腳本會自動生成一套默認配置里面通常已經(jīng)預設了 compile 用的 AOT 程序集列表和補充元數(shù)據(jù)列表。新工程用默認配置其實就能跑通不需要一開始就手動維護一堆列表。3.3 初始化的核心代碼補充元數(shù)據(jù)再加載熱更程序集接入代碼最核心的只有兩步先補充 AOT 元數(shù)據(jù)再Assembly.Load熱更 dll。補充元數(shù)據(jù)這一步是用HybridCLR.RuntimeApi.LoadMetadataForAOTAssembly把 AOT dll 的元數(shù)據(jù)喂給解釋器。注意每個 dll 要單獨調(diào)用一次不能把多個 dll 拼成一個 byte 數(shù)組一次性傳進去。這里直接放一份可運行的初始化思路using System; using System.Reflection; using HybridCLR; using UnityEngine; public static class HotfixBootstrap { // 假設這些 dll 都已經(jīng)被打進同一個 AssetBundle // 并且以 TextAsset 形式加載 private static readonly string[] AotDllNames { mscorlib.dll, System.dll, System.Core.dll, UnityEngine.CoreModule.dll, Main.dll, }; private const string HotUpdateDllName HotUpdate.dll; public static void Start() { try { LoadAotMetadata(); LoadHotUpdateAssembly(); } catch (Exception e) { Debug.LogError($[Hotfix] 熱更啟動失敗走 AOT 兜底邏輯. {e}); FallbackToAOT(); } } private static void LoadAotMetadata() { AssetBundle ab AssetBundle.LoadFromFile(GetBundlePath()); foreach (string dllName in AotDllNames) { TextAsset ta ab.LoadAssetTextAsset(dllName); if (ta null) { Debug.LogError($[Hotfix] 缺少 AOT 元數(shù)據(jù): {dllName}); continue; } // 補充元數(shù)據(jù)必須發(fā)生在熱更代碼調(diào)用相關 AOT 泛型之前 RuntimeApi.LoadMetadataForAOTAssembly(ta.bytes, HomologousImageMode.SuperSet); } ab.Unload(false); } private static void LoadHotUpdateAssembly() { AssetBundle ab AssetBundle.LoadFromFile(GetBundlePath()); TextAsset dll ab.LoadAssetTextAsset(HotUpdateDllName); Assembly hotUpdateAssembly Assembly.Load(dll.bytes); Type entry hotUpdateAssembly.GetType(HotUpdate.GameMain); if (entry null) { Debug.LogError([Hotfix] 熱更入口類型不存在); return; } MethodInfo start entry.GetMethod(StartEntry); start?.Invoke(null, null); ab.Unload(false); } private static string GetBundlePath() { // 首包資源在 StreamingAssets后續(xù)更新資源在 persistentDataPath // 這里根據(jù)項目策略自行切換 return Application.streamingAssetsPath /hotupdate; } private static void FallbackToAOT() { // 你原有的啟動邏輯 AOTMain.Start(); } }有幾個細節(jié)需要說明。HomologousImageMode.SuperSet是官方示例里很常用的模式意思是用包含超集信息的方式加載元數(shù)據(jù)對裁剪后的 dll 兼容性更好。如果你的 dll 完全沒裁剪可以用 Consistent 模式但項目一旦開了 Strip Engine Code經(jīng)常會出現(xiàn)某些類型被裁掉的情況所以用 SuperSet 在實際項目里更省心。補充元數(shù)據(jù)的順序一定要在加載熱更 dll 之前。你在熱更 dll 里寫的代碼可能用到了主工程的泛型方法解釋器在執(zhí)行時如果 AOT 側沒有現(xiàn)成函數(shù)實現(xiàn)就需要通過補充元數(shù)據(jù)去解析對應 IL。這個動作發(fā)生得越晚越容易在詭異的位置拋出異常。不要直接在主工程里靜態(tài)調(diào)用熱更程序集里的類。上面代碼用反射拿HotUpdate.GameMain再調(diào)方法是我推薦的最小實現(xiàn)。真實項目里可以把這個入口抽象成一個接口放到 AOT 公共層熱更代碼提供一個實現(xiàn)這樣主工程只需要按需求反射加載熱更程序集再轉換成約定接口去調(diào)用比純反射更舒服。3.4 從 Generate/All 到 Android 打包代碼寫好后HybridCLR 的構建流程不是直接點 Unity 的 Build Player而是先執(zhí)行HybridCLR - Generate/All。這一步會完成幾件事把熱更程序集編譯成 dll、掃描代碼生成必要的橋接代碼、生成 AOT 泛型補充列表。也就是說橋接代碼和泛型列表不是純手工維護的而是在 Generate 階段自動生成的。每次修改熱更代碼后如果你直接打包而忘了重新執(zhí)行 Generate/All很可能打出來的包運行后行為異常因為橋接信息沒有同步過來。命令行構建時也需要在打包前調(diào)用對應接口常見寫法是using HybridCLR.Editor.Commands; using UnityEditor; using UnityEditor.Build; public static class BuildEntry { public static void BuildAndroid() { PrebuildCommand.GenerateAll(); BuildPlayerOptions options new BuildPlayerOptions(); options.scenes new[] { Assets/Scenes/Main.unity }; options.locationPathName Build/Android/demo.apk; options.target BuildTarget.Android; options.options BuildOptions.None; BuildPipeline.BuildPlayer(options); } }真機驗證時Player Settings 里注意三點Scripting Backend 必須選 IL2CPPTarget Architecture 要勾選 ARM64很多中低端新機也已經(jīng)只有 64 位庫了至少你要保證包含 ARM64Strip Engine Code 可以暫時開著但首輪驗證如果出現(xiàn)異常建議先關掉一次對比排查確認是熱更鏈路問題還是裁剪問題。3.5 驗證一次真正的不重裝更新首包裝完后寫一個最簡單的熱更驗證入口在熱更程序集里做這樣一件事在屏幕中央顯示HotUpdate Version 1。裝到手機上確認顯示正確。然后把代碼里的版本號改成HotUpdate Version 2重新 Generate/All重新打 AssetBundle但不要重新打 APK。把新的 AB 放到下載源手機 App 啟動后下載新 AB再次加載時如果屏幕顯示Version 2說明熱更已經(jīng)跑通。這一步是整個接入的“成人禮”。只要這個鏈路通了后面要做的就是把下載、校驗、解壓、加載打磨成正式框架。我見過不少項目卡在“編輯器里改了代碼直接運行是新的但熱更鏈路沒通”核心原因就是忘了驗證從 AB 里加載的還是不是最新那版 dll。打包 AB 之前建議在 AB 文件名或 dll 里寫入版本號標識啟動時打印出來避免新舊資源混淆。4. 首包之后躲不開的坑元數(shù)據(jù)缺失、AOT 泛型與裁剪4.1 真機 MissingMethodException 的排查路徑能把 Demo 跑通只代表最小鏈路沒問題。真實項目的第一個坎往往出現(xiàn)在把一部分業(yè)務代碼挪進熱更程序集之后。我印象最深的一次報錯是 Android 真機進入某個界面直接拋ExecutionEngineException: Attempting to call method xxx for which no ahead of time (AOT) code was generated。在編輯器里怎么跑都沒事一上 IL2CPP 就崩。遇到這類錯誤第一反應不要只盯著報錯的那一行函數(shù)而是按照這個順序排查初始化代碼是否真的執(zhí)行了。真機上熱更初始化可能被 SDK 或啟動順序問題跳過先打日志確認LoadMetadataForAOTAssembly每個 dll 都成功了。元數(shù)據(jù)列表是否完整。報錯類型如果是System.Collections.Generic.Dictionaryint, MyStruct之類的 AOT 泛型先查 System.dll、mscorlib.dll 的元數(shù)據(jù)是否被加載。報錯方法是不是定義在熱更 dll 里但實現(xiàn)需要調(diào)用 AOT 側的泛型特化。這是最常見的情況。是否開啟了代碼裁剪裁剪把需要用到的元數(shù)據(jù)當成“無用數(shù)據(jù)”干掉了。不要一上來就想著用“AOT 泛型引用列表”硬補。先搞清楚報錯方法屬于哪個程序集、是不是泛型、泛型參數(shù)是不是值類型排查方向會清晰很多。4.2 AOT 泛型為什么不能靠事前祈禱規(guī)避AOT 泛型問題的本質是編譯期和運行期的信息不對等。IL2CPP 打包時只會把主工程代碼里實際引用過的泛型特化編譯出來。假如你有一個MyStruct只在熱更 dll 里出現(xiàn)了ListMyStruct而主工程從來沒有實例化過這個組合那么在 AOT 的機器碼里就真的沒有ListMyStruct的實現(xiàn)。程序運行時發(fā)現(xiàn)需要它無論怎么找都找不到現(xiàn)成代碼。HybridCLR 給出的路徑是你想不到那我們就在運行時讓解釋器去現(xiàn)讀 IL、現(xiàn)解釋執(zhí)行。所以補充元數(shù)據(jù)不只是湊個數(shù)它是給解釋器提供了“原料”。只要元數(shù)據(jù)里包含那個泛型方法的 IL解釋器就能自己把它跑起來不依賴 IL2CPP 現(xiàn)成機器碼。但在實際項目里我遇到過需要補充的元數(shù)據(jù)太多導致啟動階段加載耗時上升的情況。后來我們做了個折中對性能敏感、且只在固定幾個類型之間使用的泛型盡量在主工程的 AOT 側提前打一次“引用錨點”讓它被 IL2CPP 編譯出來對業(yè)務里零散的泛型用法交給補充元數(shù)據(jù)解釋執(zhí)行。這樣既不出錯性能也可控。4.3 link.xml 裁剪與混淆帶來的一連串問題元數(shù)據(jù)有了但如果構建時裁剪器把 dll 里的元數(shù)據(jù)當成“沒被引用”的垃圾裁掉加載元數(shù)據(jù)時一樣會失敗。HybridCLR 官方工程里通常會帶一份 link.xml 或者在 Installer 時配置好 keep 規(guī)則如果你是自己創(chuàng)建的新工程注意保留 AOT 程序集的相關節(jié)點。我們的教訓是某次為了減包重打開 Strip Engine Code結果線上部分低端機開始隨機出現(xiàn)加載失敗。后來檢查發(fā)現(xiàn)裁剪配置沒有把第三方 SDK 里被熱更代碼反射調(diào)用的類型排除出去反射調(diào)用在 IL2CPP 裁剪后找不到類型。排查時可以先試著把Managed Stripping Level調(diào)到最低確認問題消失再逐步調(diào)高裁減等級定位是哪個規(guī)則誤傷了類型。如果項目用了混淆或加固尤其是對 dll 做二次處理的方案要和熱更鏈路分開對待。熱更 dll 自己可以加密混淆運行時解密再Assembly.Load沒問題但 AOT 元數(shù)據(jù)那批 dll 盡量不要做會影響元數(shù)據(jù)結構的混淆否則LoadMetadataForAOTAssembly時的模式校驗可能直接不通過。排查這類問題有個技巧關閉混淆打一個包如果不再報錯基本就是混淆規(guī)則或順序的問題。4.4 一次真實排查字典泛型在熱更里爆炸當初我們把任務系統(tǒng)挪進熱更程序集時熱更代碼里有這么一段Dictionaryint, TaskReward rewardMap new Dictionaryint, TaskReward();TaskReward是熱更程序集里的一個普通類int是值類型。這個寫法在 C# 里再普通不過但在 IL2CPP 熱更環(huán)境下它是一個典型的泛型特化組合主工程 AOT 側從來沒寫過Dictionaryint, TaskReward所以沒有現(xiàn)成 AOT 代碼。最終是靠補充元數(shù)據(jù)解決的。我們在 AOT 元數(shù)據(jù)列表里帶上 System.dll字典泛型的實現(xiàn)定義在這里并在加載熱更 dll 之前調(diào)用LoadMetadataForAOTAssembly加載它解釋器拿到元數(shù)據(jù)后就能自己解釋執(zhí)行這個泛型方法。如果你也想臨時驗證某個泛型問題是不是補充元數(shù)據(jù)能解決可以寫一段只包含該泛型操作的測試熱更代碼真機跑一次比在論壇上猜快得多。5. 與項目框架配套AB 打包、啟動更新和版本保護5.1 熱更 dll 放 AssetBundle元數(shù)據(jù)放哪里熱更 dll 本質上是一個二進制文件你可以直接放服務器讓客戶端下載后寫到 persistentDataPath也可以塞進 AssetBundle。實戰(zhàn)上我更推薦塞 AssetBundle原因不是放不下一個 dll而是項目本來就有資源更新鏈路復用同一套下載、校驗、加載邏輯比另起一套文件下載穩(wěn)定得多。有一點經(jīng)驗很重要不要把熱更 dll 用 Unity 的 TextAsset 直接打進 ResourcesResources 里的東西在包發(fā)布后是不能動態(tài)替換的只適合放“永遠不會變的 AOT 兜底版本”或某個基礎元數(shù)據(jù)。真正要更新的是放在 AssetBundle 里的那份 dll首包時可以把這個 AB 同時放到 StreamingAssets Unity HybridCLR熱更新實戰(zhàn)：原理、接入順序與真機排坑
我到現(xiàn)在都記得第一次線上事故的場景一個已經(jīng)過審上架的手游運營活動發(fā)獎勵的數(shù)值公式少取了一次隨機數(shù)玩家領到的獎勵高了兩倍。服務端立刻封住漏洞但已經(jīng)安裝的客戶端代碼是死的發(fā)新版要走渠道審核少則一天多則一周那幾天項目組每個人臉上都寫著焦慮。那次之后我們整個團隊把“代碼熱更新”從“以后再說”提到了“下周必須驗證”的優(yōu)先級。最后選型、驗證、接入的方案就是今天這篇要聊的 Unity HybridCLR 熱更新。如果只用一句話介紹HybridCLR 是一個基于 IL2CPP 的 C# 熱更新方案它能讓你的 Unity 項目在不重新打包上架、玩家不重新下載安裝包的情況下通過加載一段新的 C# 程序集來更新游戲邏輯。這篇文章是我自己從零把一個 Demo 工程接入 HybridCLR再逐步推進到真實項目的完整記錄。重點不是重復官方文檔而是告訴你接入順序、依賴方向、AOT 泛型問題這些文檔里不容易一次講透的東西以及我踩過的坑長什么樣。如果你是想評估熱更新方案的技術負責人、正在給老項目接熱更的 Unity 客戶端同學或者剛被分配要驗證 HybridCLR 可行性的新手這篇應該能幫你省下不少試錯時間。讀完你應該能知道它和 Lua 熱更、和 IDE 里的熱重載到底什么關系接入前工程要做什么體檢真機上跑通一個最小熱更工程需要哪幾步以及第一輪真機崩潰該怎么查。1. 為什么是 HybridCLR而不是 Lua 或者熱重載1.1 IL2CPP 把代碼焊死在哪里要理解 HybridCLR 的價值先得知道 Unity 的 IL2CPP 到底做了什么。在沒有 IL2CPP 的 Mono 時代C# 代碼會被編譯成 IL運行時由 Mono 虛擬機解釋或 JIT 編譯執(zhí)行。那個年代想在 iOS 上做熱更新很麻煩因為蘋果明確禁止應用在自己的沙盒里動態(tài)生成可執(zhí)行代碼JIT 這條路在 iOS 上基本是堵死的。IL2CPP 是把 C# 先編譯成 IL再在構建階段把 IL 轉成 C最后隨原生工程一起編譯成目標平臺的機器碼。好處是啟動快、性能好、代碼不容易被直接反編譯成原始 C#壞處也藏在這里所有 C# 邏輯都在編譯期被翻譯并“焊死”進了原生二進制運行時已經(jīng)沒有一套能把新 IL 編譯成機器碼的機制了。這就好比你把菜譜都刻成了石碑讀者只能照著石碑做菜現(xiàn)在你拿到一張新菜譜卻沒有火源也沒有翻譯想按新菜譜做菜根本無從下手。HybridCLR 做的是在 IL2CPP 旁邊補了一個“解釋執(zhí)行器”讓新拿到的 C# 程序集也就是熱更 dll里的 IL 字節(jié)碼不經(jīng)過 JIT 也能被逐條解釋執(zhí)行。1.2 它和 xLua、ILRuntime 的本質差異很多團隊第一次聊熱更新聽到的往往是 xLua、tolua或者純 C# 的 ILRuntime。這里我直接按實際感受做個比較。Lua 方案的核心是“換語言”業(yè)務邏輯不寫在 C# 里而是寫 Lua運行時由 C# 側的虛擬機解釋執(zhí)行。好處是生態(tài)成熟、很多老項目都在用代價是整個項目的核心玩法可能要從 C# 平移成 Lua維護一套雙語言邏輯團隊里每個人都要會 Lua出問題時要跨語言查堆棧代碼補全和重構也不夠舒服。ILRuntime 是純 C# 的解釋器方案不需要換語言但它和 Unity 的 AOT 世界之間隔了一層自己的運行時對某些 C# 特性的支持以及對 Unity 引擎調(diào)用、泛型、值類型結構的處理需要開發(fā)者額外注意。性能和兼容性一直在進步但遇到冷門邊界總有“為什么這里不行”的疑惑。HybridCLR 選擇的是另一條路線盡可能貼近原生 CLR 的實現(xiàn)方式在 IL2CPP 的 AOT 基礎上加一個解釋器模塊并且用“補充元數(shù)據(jù)”的方式解決 AOT 泛型缺失的經(jīng)典問題。用下來最直觀的感受是它不是讓你把邏輯翻譯成另一種語言而是讓熱更 dll 里的 C# 代碼自己跑起來和主工程的 C# 代碼寫法差別不大。對比項Lua 系方案ILRuntimeHybridCLR業(yè)務語言Lua C#C#C#與 IL2CPP 關系獨立虛擬機獨立解釋器基于 IL2CPP 補充解釋能力學習成本需要掌握 Lua較低但邊界概念多較低重點是理解 AOT 與熱更分界泛型等邊界問題不受 IL2CPP 泛型影響有自己的處理通過補充元數(shù)據(jù)解決大多數(shù)社區(qū)活躍度高但偏向舊項目中高近幾年增長很快需要客觀說的是HybridCLR 本質上是修改了 Unity 的 IL2CPP 構建鏈路Unity 版本升級、IL2CPP 內(nèi)部實現(xiàn)調(diào)整都有可能影響它。所以它不是一個“裝一次永遠不用管”的方案每次 Unity 升級或 HybridCLR 升級都要做回歸驗證。這點后面章節(jié)會細說。1.3 先理清“熱更新”和“熱重載”不是一回事熱搜詞里出現(xiàn)了不少和熱更新相關的詞比如 Flutter 熱重載、IDEA 修改代碼熱更新、Nacos 配置熱更新。這些詞經(jīng)常被混在一起但它們解決的問題完全不同。Flutter 的熱重載本質是開發(fā)期工具改完代碼按一下 R開發(fā)進程把新的 widget 樹推給正在運行的調(diào)試 App幫開發(fā)者快速看 UI 效果。它不面向線上玩家代碼改動只在開發(fā)環(huán)境里生效。IDEA 里修改 Java 代碼后的熱更新是讓本地開發(fā)服務器不用重啟就能加載新類屬于開發(fā)效率工具的范圍。Nacos 配置熱更新更新的是配置項不是程序邏輯本身。而 Unity 項目里說的“代碼熱更新”指的是已經(jīng)安裝到玩家手機上的 App在不發(fā)新包的前提下從服務器拉取新的 C# 程序集并在本地執(zhí)行新邏輯。這是玩家可見的能力直接關系到線上事故的處理速度和上面那些開發(fā)期工具完全不是一個維度。所以有些同學問“我項目里用 IDE 熱重載很順是不是就不用 HybridCLR 了”答案顯然是否定的。2. 接入前先給工程“體檢”程序集、依賴方向、泛型用法2.1 依賴方向熱更代碼能引用什么不能引用什么接入 HybridCLR 最容易犯的錯是直接拿一個已經(jīng)寫了兩三年的老工程把所有代碼都掃進熱更程序集然后開始打包。正確的第一步是給工程劃分程序集邊界。Unity 項目里用 asmdef 把代碼分成多個程序集主工程里有一套專門給熱更代碼用的接口和公共代碼熱更代碼所在的程序集可以引用主工程的公共程序集但主工程的 AOT 代碼絕對不能反過來引用熱更程序集里的類型。一旦主工程靜態(tài)引用了熱更代碼里的類打 IL2CPP 包時就會把熱更代碼一起編進去后續(xù)想替換邏輯就會非常別扭。我在項目里習慣的分層是這樣的AOT 主程序集啟動流程、SDK 對接、資源管理、渲染相關、游戲的底層框架。AOT 公共接口層純接口和 DTO 定義比如戰(zhàn)斗結算接口、活動模板接口供熱更代碼實現(xiàn)或調(diào)用。熱更程序集賽季玩法、活動界面、數(shù)值表現(xiàn)、任務系統(tǒng)這類需要頻繁調(diào)整的邏輯。依賴方向是熱更層可以引用 AOT 公共接口層AOT 公共接口層不能引用熱更層。因為熱更層是運行時才被加載的AOT 側的代碼在編譯期根本不知道它的存在兩者之間只能靠接口或反射溝通。2.2 重點檢查一遍泛型使用習慣體檢時另一個重點是泛型。C# 泛型在 AOT 編譯下有個天然矛盾IL2CPP 編譯器在打包時只會為主工程代碼里“顯式出現(xiàn)過的泛型實例化”生成機器碼。如果熱更代碼運行時突然出現(xiàn)一個 AOT 模塊里從未實例化過的泛型組合比如DictionaryMyStruct, intIL2CPP 那邊并沒有對應的目標代碼運行時就會報類似AOT generic method can not be instantiated的錯誤。HybridCLR 的解法是“補充元數(shù)據(jù) 解釋器兜底”。打包時項目會帶上 AOT 必需 dll比如 mscorlib、System、UnityEngine.CoreModule 這些的元數(shù)據(jù)運行時先加載這些元數(shù)據(jù)讓解釋器能夠自己解析泛型方法的 IL 并執(zhí)行而不是必須依賴 IL2CPP 現(xiàn)成的機器碼。這并不代表你可以完全無視泛型。我建議在接入前把項目里“值類型 泛型容器混用”的地方掃一遍。比如大量使用Listint、Dictionaryint, MyEnum、Dictionarylong, MyStruct尤其是這些結構體是活動邏輯里臨時定義的時候要格外留意。這里不是說不能用而是你要意識到這類代碼會觸發(fā) AOT 泛型補充機制線上報錯后排查成本會高一些。2.3 確認版本兼容與目標平臺體檢還包括兩個基礎問題項目用的 Unity 版本以及 Scripting Backend 是否已經(jīng)是 IL2CPP。HybridCLR 只支持 IL2CPPMono 后端不在討論范圍內(nèi)。Android 項目由于現(xiàn)在 Google Play 和國內(nèi)渠道對 Target API Level 的要求越來越高很多項目把target API level提到了 33、34、35這個過程中只要正常使用 IL2CPP 并勾選 ARM64不會和 HybridCLR 產(chǎn)生直接沖突。但如果是很老的項目一直跑在 ARMv7 或 Mono 上最好先把構建鏈路切干凈再談熱更。Unity 版本建議盡量用 LTS比如 2021.3 LTS、2022.3 LTS 或官方文檔當前明確支持的版本。HybridCLR 的發(fā)布節(jié)奏通常能跟上主流 LTS用非 LTS 版本容易遭遇兼容性盲區(qū)。安裝時下載的是focus-creative-games/hybridclr_unity這份 Unity 側工程代碼版本要和項目 Unity 版本匹配別隨手拉最新版就往老項目里塞。3. 真機跑通全流程一個最小可熱更工程的搭建記錄3.1 安裝包和 Installer 到底做了什么接入時首先通過 Unity Package Manager 用 Git URL 把 HybridCLR 的 Unity 包加到工程里。拉取成功后菜單欄會出現(xiàn) HybridCLR 相關的入口。接下來執(zhí)行的是 HybridCLR - Installer這一步會往工程里寫一些必要的代碼更關鍵的是它會修改本地的 IL2CPP把解釋器相關模塊合入 il2cpp 的構建鏈。也就是說它不只是往 Assets 里加幾個腳本還動到了 Unity 編輯器安裝目錄下的 il2cpp 相關文件。這里有兩個容易踩的點。第一Installer 執(zhí)行時如果 Unity 正在占用相關文件或者殺毒軟件攔截了對安裝目錄的修改安裝可能“假成功”。我遇到過安裝后 Generate 時各種詭異報錯重裝一次 HybridCLR 就好了。建議執(zhí)行完 Installer 后先做一次簡單的生成操作驗證而不是直接開始打大包。第二升級 Unity 小版本后最好重新執(zhí)行 Installer。IL2CPP 內(nèi)部文件結構會隨版本變化舊的補丁不一定還能用。我們項目從 Unity 2021.3.16 升到 2021.3.31 時因為漏了這一步打出來的包初始化階段直接崩潰排查了半天才發(fā)現(xiàn)是 installer 沒重跑。3.2 創(chuàng)建熱更程序集并在 Settings 里登記HybridCLR 需要知道哪些程序集要被當作熱更程序集處理。官方推薦用 asmdef 組織但不是把文件夾命名為 HotUpdate 就行而是在工程里建一個真正的 Assembly Definition。我的做法是在 Assets 下建兩個目錄Assets/Scripts/Main主工程邏輯里面放Main.asmdef。Assets/Scripts/HotUpdate熱更邏輯里面放HotUpdate.asmdef。由于 HotUpdate 需要引用 Main 里定義的類型和接口在HotUpdate.asmdef的 Assembly Definition References 里加上 Main反之 Main 里不要引用 HotUpdate。這樣主工程干凈熱更程序集可以隨意引用它依賴的 AOT 庫。創(chuàng)建好 asmdef 后打開菜單HybridCLR - Settings把 HotUpdate 加進熱更新程序集列表。Install 時官方腳本會自動生成一套默認配置里面通常已經(jīng)預設了 compile 用的 AOT 程序集列表和補充元數(shù)據(jù)列表。新工程用默認配置其實就能跑通不需要一開始就手動維護一堆列表。3.3 初始化的核心代碼補充元數(shù)據(jù)再加載熱更程序集接入代碼最核心的只有兩步先補充 AOT 元數(shù)據(jù)再Assembly.Load熱更 dll。補充元數(shù)據(jù)這一步是用HybridCLR.RuntimeApi.LoadMetadataForAOTAssembly把 AOT dll 的元數(shù)據(jù)喂給解釋器。注意每個 dll 要單獨調(diào)用一次不能把多個 dll 拼成一個 byte 數(shù)組一次性傳進去。這里直接放一份可運行的初始化思路using System; using System.Reflection; using HybridCLR; using UnityEngine; public static class HotfixBootstrap { // 假設這些 dll 都已經(jīng)被打進同一個 AssetBundle // 并且以 TextAsset 形式加載 private static readonly string[] AotDllNames { mscorlib.dll, System.dll, System.Core.dll, UnityEngine.CoreModule.dll, Main.dll, }; private const string HotUpdateDllName HotUpdate.dll; public static void Start() { try { LoadAotMetadata(); LoadHotUpdateAssembly(); } catch (Exception e) { Debug.LogError($[Hotfix] 熱更啟動失敗走 AOT 兜底邏輯. {e}); FallbackToAOT(); } } private static void LoadAotMetadata() { AssetBundle ab AssetBundle.LoadFromFile(GetBundlePath()); foreach (string dllName in AotDllNames) { TextAsset ta ab.LoadAssetTextAsset(dllName); if (ta null) { Debug.LogError($[Hotfix] 缺少 AOT 元數(shù)據(jù): {dllName}); continue; } // 補充元數(shù)據(jù)必須發(fā)生在熱更代碼調(diào)用相關 AOT 泛型之前 RuntimeApi.LoadMetadataForAOTAssembly(ta.bytes, HomologousImageMode.SuperSet); } ab.Unload(false); } private static void LoadHotUpdateAssembly() { AssetBundle ab AssetBundle.LoadFromFile(GetBundlePath()); TextAsset dll ab.LoadAssetTextAsset(HotUpdateDllName); Assembly hotUpdateAssembly Assembly.Load(dll.bytes); Type entry hotUpdateAssembly.GetType(HotUpdate.GameMain); if (entry null) { Debug.LogError([Hotfix] 熱更入口類型不存在); return; } MethodInfo start entry.GetMethod(StartEntry); start?.Invoke(null, null); ab.Unload(false); } private static string GetBundlePath() { // 首包資源在 StreamingAssets后續(xù)更新資源在 persistentDataPath // 這里根據(jù)項目策略自行切換 return Application.streamingAssetsPath /hotupdate; } private static void FallbackToAOT() { // 你原有的啟動邏輯 AOTMain.Start(); } }有幾個細節(jié)需要說明。HomologousImageMode.SuperSet是官方示例里很常用的模式意思是用包含超集信息的方式加載元數(shù)據(jù)對裁剪后的 dll 兼容性更好。如果你的 dll 完全沒裁剪可以用 Consistent 模式但項目一旦開了 Strip Engine Code經(jīng)常會出現(xiàn)某些類型被裁掉的情況所以用 SuperSet 在實際項目里更省心。補充元數(shù)據(jù)的順序一定要在加載熱更 dll 之前。你在熱更 dll 里寫的代碼可能用到了主工程的泛型方法解釋器在執(zhí)行時如果 AOT 側沒有現(xiàn)成函數(shù)實現(xiàn)就需要通過補充元數(shù)據(jù)去解析對應 IL。這個動作發(fā)生得越晚越容易在詭異的位置拋出異常。不要直接在主工程里靜態(tài)調(diào)用熱更程序集里的類。上面代碼用反射拿HotUpdate.GameMain再調(diào)方法是我推薦的最小實現(xiàn)。真實項目里可以把這個入口抽象成一個接口放到 AOT 公共層熱更代碼提供一個實現(xiàn)這樣主工程只需要按需求反射加載熱更程序集再轉換成約定接口去調(diào)用比純反射更舒服。3.4 從 Generate/All 到 Android 打包代碼寫好后HybridCLR 的構建流程不是直接點 Unity 的 Build Player而是先執(zhí)行HybridCLR - Generate/All。這一步會完成幾件事把熱更程序集編譯成 dll、掃描代碼生成必要的橋接代碼、生成 AOT 泛型補充列表。也就是說橋接代碼和泛型列表不是純手工維護的而是在 Generate 階段自動生成的。每次修改熱更代碼后如果你直接打包而忘了重新執(zhí)行 Generate/All很可能打出來的包運行后行為異常因為橋接信息沒有同步過來。命令行構建時也需要在打包前調(diào)用對應接口常見寫法是using HybridCLR.Editor.Commands; using UnityEditor; using UnityEditor.Build; public static class BuildEntry { public static void BuildAndroid() { PrebuildCommand.GenerateAll(); BuildPlayerOptions options new BuildPlayerOptions(); options.scenes new[] { Assets/Scenes/Main.unity }; options.locationPathName Build/Android/demo.apk; options.target BuildTarget.Android; options.options BuildOptions.None; BuildPipeline.BuildPlayer(options); } }真機驗證時Player Settings 里注意三點Scripting Backend 必須選 IL2CPPTarget Architecture 要勾選 ARM64很多中低端新機也已經(jīng)只有 64 位庫了至少你要保證包含 ARM64Strip Engine Code 可以暫時開著但首輪驗證如果出現(xiàn)異常建議先關掉一次對比排查確認是熱更鏈路問題還是裁剪問題。3.5 驗證一次真正的不重裝更新首包裝完后寫一個最簡單的熱更驗證入口在熱更程序集里做這樣一件事在屏幕中央顯示HotUpdate Version 1。裝到手機上確認顯示正確。然后把代碼里的版本號改成HotUpdate Version 2重新 Generate/All重新打 AssetBundle但不要重新打 APK。把新的 AB 放到下載源手機 App 啟動后下載新 AB再次加載時如果屏幕顯示Version 2說明熱更已經(jīng)跑通。這一步是整個接入的“成人禮”。只要這個鏈路通了后面要做的就是把下載、校驗、解壓、加載打磨成正式框架。我見過不少項目卡在“編輯器里改了代碼直接運行是新的但熱更鏈路沒通”核心原因就是忘了驗證從 AB 里加載的還是不是最新那版 dll。打包 AB 之前建議在 AB 文件名或 dll 里寫入版本號標識啟動時打印出來避免新舊資源混淆。4. 首包之后躲不開的坑元數(shù)據(jù)缺失、AOT 泛型與裁剪4.1 真機 MissingMethodException 的排查路徑能把 Demo 跑通只代表最小鏈路沒問題。真實項目的第一個坎往往出現(xiàn)在把一部分業(yè)務代碼挪進熱更程序集之后。我印象最深的一次報錯是 Android 真機進入某個界面直接拋ExecutionEngineException: Attempting to call method xxx for which no ahead of time (AOT) code was generated。在編輯器里怎么跑都沒事一上 IL2CPP 就崩。遇到這類錯誤第一反應不要只盯著報錯的那一行函數(shù)而是按照這個順序排查初始化代碼是否真的執(zhí)行了。真機上熱更初始化可能被 SDK 或啟動順序問題跳過先打日志確認LoadMetadataForAOTAssembly每個 dll 都成功了。元數(shù)據(jù)列表是否完整。報錯類型如果是System.Collections.Generic.Dictionaryint, MyStruct之類的 AOT 泛型先查 System.dll、mscorlib.dll 的元數(shù)據(jù)是否被加載。報錯方法是不是定義在熱更 dll 里但實現(xiàn)需要調(diào)用 AOT 側的泛型特化。這是最常見的情況。是否開啟了代碼裁剪裁剪把需要用到的元數(shù)據(jù)當成“無用數(shù)據(jù)”干掉了。不要一上來就想著用“AOT 泛型引用列表”硬補。先搞清楚報錯方法屬于哪個程序集、是不是泛型、泛型參數(shù)是不是值類型排查方向會清晰很多。4.2 AOT 泛型為什么不能靠事前祈禱規(guī)避AOT 泛型問題的本質是編譯期和運行期的信息不對等。IL2CPP 打包時只會把主工程代碼里實際引用過的泛型特化編譯出來。假如你有一個MyStruct只在熱更 dll 里出現(xiàn)了ListMyStruct而主工程從來沒有實例化過這個組合那么在 AOT 的機器碼里就真的沒有ListMyStruct的實現(xiàn)。程序運行時發(fā)現(xiàn)需要它無論怎么找都找不到現(xiàn)成代碼。HybridCLR 給出的路徑是你想不到那我們就在運行時讓解釋器去現(xiàn)讀 IL、現(xiàn)解釋執(zhí)行。所以補充元數(shù)據(jù)不只是湊個數(shù)它是給解釋器提供了“原料”。只要元數(shù)據(jù)里包含那個泛型方法的 IL解釋器就能自己把它跑起來不依賴 IL2CPP 現(xiàn)成機器碼。但在實際項目里我遇到過需要補充的元數(shù)據(jù)太多導致啟動階段加載耗時上升的情況。后來我們做了個折中對性能敏感、且只在固定幾個類型之間使用的泛型盡量在主工程的 AOT 側提前打一次“引用錨點”讓它被 IL2CPP 編譯出來對業(yè)務里零散的泛型用法交給補充元數(shù)據(jù)解釋執(zhí)行。這樣既不出錯性能也可控。4.3 link.xml 裁剪與混淆帶來的一連串問題元數(shù)據(jù)有了但如果構建時裁剪器把 dll 里的元數(shù)據(jù)當成“沒被引用”的垃圾裁掉加載元數(shù)據(jù)時一樣會失敗。HybridCLR 官方工程里通常會帶一份 link.xml 或者在 Installer 時配置好 keep 規(guī)則如果你是自己創(chuàng)建的新工程注意保留 AOT 程序集的相關節(jié)點。我們的教訓是某次為了減包重打開 Strip Engine Code結果線上部分低端機開始隨機出現(xiàn)加載失敗。后來檢查發(fā)現(xiàn)裁剪配置沒有把第三方 SDK 里被熱更代碼反射調(diào)用的類型排除出去反射調(diào)用在 IL2CPP 裁剪后找不到類型。排查時可以先試著把Managed Stripping Level調(diào)到最低確認問題消失再逐步調(diào)高裁減等級定位是哪個規(guī)則誤傷了類型。如果項目用了混淆或加固尤其是對 dll 做二次處理的方案要和熱更鏈路分開對待。熱更 dll 自己可以加密混淆運行時解密再Assembly.Load沒問題但 AOT 元數(shù)據(jù)那批 dll 盡量不要做會影響元數(shù)據(jù)結構的混淆否則LoadMetadataForAOTAssembly時的模式校驗可能直接不通過。排查這類問題有個技巧關閉混淆打一個包如果不再報錯基本就是混淆規(guī)則或順序的問題。4.4 一次真實排查字典泛型在熱更里爆炸當初我們把任務系統(tǒng)挪進熱更程序集時熱更代碼里有這么一段Dictionaryint, TaskReward rewardMap new Dictionaryint, TaskReward();TaskReward是熱更程序集里的一個普通類int是值類型。這個寫法在 C# 里再普通不過但在 IL2CPP 熱更環(huán)境下它是一個典型的泛型特化組合主工程 AOT 側從來沒寫過Dictionaryint, TaskReward所以沒有現(xiàn)成 AOT 代碼。最終是靠補充元數(shù)據(jù)解決的。我們在 AOT 元數(shù)據(jù)列表里帶上 System.dll字典泛型的實現(xiàn)定義在這里并在加載熱更 dll 之前調(diào)用LoadMetadataForAOTAssembly加載它解釋器拿到元數(shù)據(jù)后就能自己解釋執(zhí)行這個泛型方法。如果你也想臨時驗證某個泛型問題是不是補充元數(shù)據(jù)能解決可以寫一段只包含該泛型操作的測試熱更代碼真機跑一次比在論壇上猜快得多。5. 與項目框架配套AB 打包、啟動更新和版本保護5.1 熱更 dll 放 AssetBundle元數(shù)據(jù)放哪里熱更 dll 本質上是一個二進制文件你可以直接放服務器讓客戶端下載后寫到 persistentDataPath也可以塞進 AssetBundle。實戰(zhàn)上我更推薦塞 AssetBundle原因不是放不下一個 dll而是項目本來就有資源更新鏈路復用同一套下載、校驗、加載邏輯比另起一套文件下載穩(wěn)定得多。有一點經(jīng)驗很重要不要把熱更 dll 用 Unity 的 TextAsset 直接打進 ResourcesResources 里的東西在包發(fā)布后是不能動態(tài)替換的只適合放“永遠不會變的 AOT 兜底版本”或某個基礎元數(shù)據(jù)。真正要更新的是放在 AssetBundle 里的那份 dll首包時可以把這個 AB 同時放到 StreamingAssets