做手游這幾年有一件事比換引擎、調(diào)渲染還讓我上心就是熱更。早期項(xiàng)目上線遇到嚴(yán)重Bug看著玩家在應(yīng)用商店評(píng)論區(qū)罵了整整一周新版本才過審那種無力感到現(xiàn)在都記得。后來團(tuán)隊(duì)下定決心從C#直出改成“C#殼 Lua業(yè)務(wù)”的架構(gòu)這才把線上問題的響應(yīng)時(shí)間從一周壓縮到幾小時(shí)。這篇文章只講一件事Unity手游里用Lua做熱更配合XLua落地框架怎么搭、代碼怎么分、坑怎么躲。我盡量按實(shí)際項(xiàng)目推進(jìn)的順序來講從“為什么選XLua”到“打包補(bǔ)丁”再到“線上排障”把你在面試?yán)镎f不清、文檔里找不到的那些細(xì)節(jié)一次說透。內(nèi)容會(huì)有一點(diǎn)點(diǎn)長(zhǎng)但每段都能直接用得上。如果你正好在改熱更方案或者準(zhǔn)備從零接XLua這篇應(yīng)該是你需要的。1. 選型邏輯為什么是Lua為什么是XLua1.1 先搞清楚熱更到底解決了什么問題很多新手把熱更理解成“換個(gè)方式加載代碼”這是本末倒置。熱更的本質(zhì)是響應(yīng)速度它解決的是“用戶手里已經(jīng)安裝的版本我怎么在最短時(shí)間內(nèi)讓它表現(xiàn)正確”。移動(dòng)端發(fā)版有個(gè)繞不開的現(xiàn)實(shí)新版本從提交到全量覆蓋需要不短的時(shí)間而且一旦提審中途就算發(fā)現(xiàn)問題也只能撤回重提時(shí)間損耗非常大。所以線上事故按嚴(yán)重程度可以分為兩類能忍的某個(gè)UI按鈕文案寫錯(cuò)、活動(dòng)時(shí)間配錯(cuò)、美術(shù)資源少了一幀。這類問題可以通過運(yùn)營(yíng)配置臨時(shí)規(guī)避。不能忍的客戶端某個(gè)判斷邏輯反了、算法寫錯(cuò)導(dǎo)致異常、啟動(dòng)就崩潰。這類Bug不能靠配置救必須改代碼。沒有熱更的話第二種Bug的修復(fù)成本是“全部用戶停留在壞版本上等發(fā)版”有熱更的話是“推送一個(gè)幾十KB的補(bǔ)丁用戶下次冷啟動(dòng)自動(dòng)修復(fù)”。這就是為什么商業(yè)手游基本都會(huì)上熱更它已經(jīng)不是加分項(xiàng)而是必修課。另外熱更也保證了版本的迭代節(jié)奏?？蛻舳瞬挥冒衙總€(gè)活動(dòng)功能都堆到一個(gè)大版本里可以拆成小步快跑后端配合發(fā)配置客戶端發(fā)Lua補(bǔ)丁就能更新活動(dòng)邏輯這對(duì)運(yùn)營(yíng)節(jié)奏的幫助非常明顯。1.2 Lua為什么能成為手游腳本層的事實(shí)標(biāo)準(zhǔn)Lua能火不是因?yàn)樗阅鼙菴#好而是因?yàn)樗?、快、嵌入成本低。Lua解釋器本身只有二十萬行左右C代碼編成庫之后體積很小移動(dòng)端毫無壓力。而且Lua是一門真正的嵌入式語言它的設(shè)計(jì)目標(biāo)就是“當(dāng)一個(gè)項(xiàng)目的主語言和宿主程序配合”宿主程序Unity負(fù)責(zé)創(chuàng)建窗口、渲染、音頻等重活Lua負(fù)責(zé)邏輯組織。兩邊通過一套簡(jiǎn)潔的C API通信天然適合游戲這種“引擎重、業(yè)務(wù)快變”的場(chǎng)景。在游戲行業(yè)里L(fēng)ua的傳播還有個(gè)歷史因素當(dāng)年很多成功的MMO和端游都用Lua承載業(yè)務(wù)邏輯插件系統(tǒng)也大量采用Lua一批批程序員就是在Lua的環(huán)境里訓(xùn)練出“把系統(tǒng)拆成小腳本”的習(xí)慣。等這些經(jīng)驗(yàn)沉淀到移動(dòng)端Lua社區(qū)已經(jīng)有成熟的模式可以參考比如模塊化寫法、協(xié)程調(diào)度、面向?qū)ο蟮膖able模擬。這些模式在手游開發(fā)里依舊適用很多團(tuán)隊(duì)甚至發(fā)現(xiàn)用Lua寫復(fù)雜活動(dòng)邏輯比用C#寫更容易做快速調(diào)整因?yàn)楦骆溌范塘艘粚印＿€有一個(gè)容易被忽略的點(diǎn)Lua天然不關(guān)心平臺(tái)差異。同一份Lua腳本在Android、iOS、Windows上行為幾乎一致只要宿主庫編譯對(duì)腳本層不用做平臺(tái)宏區(qū)分。而C#代碼在移動(dòng)端反而會(huì)因?yàn)镸ono和IL2CPP的表現(xiàn)差異踩坑。放業(yè)務(wù)邏輯在Lua里等于少處理了一類平臺(tái)適配問題。1.3 tolua、SLua和XLua怎么權(quán)衡市面上常見的Unity Lua方案主要有三個(gè)tolua、SLua、XLua。很多人問我說是不是兼容性問題其實(shí)這三者的底層都一樣都是把Lua虛擬機(jī)嵌入U(xiǎn)nity進(jìn)程然后打通C#和Lua互調(diào)區(qū)別主要體現(xiàn)在生成適配代碼的方式、維護(hù)活躍度、以及一些工程化特性。對(duì)比項(xiàng)toluaSLuaXLuaLua版本Lua 5.x定制Lua 5.x定制Lua 5.3綁定方式通過反射生成Wrap反射生成Wrap生成Wrap為主部分反射兜底代碼維護(hù)活躍度社區(qū)斷續(xù)明顯放緩目前相對(duì)活躍熱補(bǔ)丁能力支持但需要額外處理有支持但資料少原生Hotfix支持特性完整上手門檻中等中等中等但文檔更清晰如果你只是查資料會(huì)發(fā)現(xiàn)SLua網(wǎng)上也有不少項(xiàng)目在用但從搜索趨勢(shì)看很多人遇到“unable to load dll slua”這類問題根本原因是SLua的維護(hù)節(jié)奏慢移動(dòng)端的新系統(tǒng)適配跟不上。一旦宿主環(huán)境升級(jí)原生庫沒跟上你只能自己編譯費(fèi)時(shí)費(fèi)力。XLua在這方面的壓力小很多社區(qū)也更活躍出問題容易搜到解決方案。選XLua還有個(gè)重要的現(xiàn)實(shí)理由它的互操作機(jī)制比較靈活。編輯器里可以用反射方式跑發(fā)布前用生成代碼方式收緊開發(fā)期和發(fā)布期分離這對(duì)團(tuán)隊(duì)早期的速度很重要。而且XLua對(duì)Lua 5.3的支持意味著你能用更現(xiàn)代的語法和更完整的位運(yùn)算、整數(shù)類型寫邏輯時(shí)不需要為語言版本做妥協(xié)。2. 熱更框架的整體架構(gòu)代碼怎么分、加載鏈路怎么走2.1 分層設(shè)計(jì)C#只做殼Lua做業(yè)務(wù)框架搭建的第一步是先把“什么代碼留在C#、什么代碼必須放Lua”這條邊界劃清楚。這個(gè)邊界是熱更架構(gòu)的地基邊界不清晰后面必然出亂子。我的經(jīng)驗(yàn)是遵循一條簡(jiǎn)單原則凡是玩家能感知到行為變化的邏輯都要能熱更。具體來說留在C#的啟動(dòng)流程、SDK初始化、原生橋接、LuaEnv管理、通用性能敏感的算法、渲染管線相關(guān)邏輯。這些內(nèi)容更新頻率低跑在原生層也更快。下沉到Lua的UI界面行為、戰(zhàn)斗流程、系統(tǒng)邏輯、活動(dòng)規(guī)則、任務(wù)引導(dǎo)、紅點(diǎn)規(guī)則、商店配置組合邏輯。這些內(nèi)容幾乎每次版本都在改必須熱更。有個(gè)很容易犯的錯(cuò)誤把UI流程做成C#的Prefab上掛了一堆組件點(diǎn)擊按鈕后直接調(diào)用C#方法一次點(diǎn)擊跨語言調(diào)用幾十次。這樣的界面一旦邏輯要改哪怕只是按鈕跳轉(zhuǎn)目標(biāo)錯(cuò)了都要改C#代碼。所以UI邏輯必須從C#的MonoBehaviour里解耦出來界面上的組件只負(fù)責(zé)接收Unity事件并把參數(shù)拋給Lua層真正的判斷邏輯在Lua側(cè)實(shí)現(xiàn)。否則你的熱更能力會(huì)大打折扣。2.2 從冷啟動(dòng)到Lua入口的執(zhí)行鏈路理解了分層原則再看整體執(zhí)行鏈路就很清晰了。這里描述的是用XLua承載業(yè)務(wù)的常見冷啟動(dòng)流程Unity引擎初始化第一個(gè)場(chǎng)景加載。C#啟動(dòng)腳本A調(diào)用相關(guān)SDK初始化。C#啟動(dòng)腳本檢查并加載本地補(bǔ)丁列表確認(rèn)是否有可用的熱更內(nèi)容。根據(jù)當(dāng)前版本號(hào)決定是否向服務(wù)器請(qǐng)求最新補(bǔ)丁信息下載增量文件。補(bǔ)丁加載完成后創(chuàng)建XLua的LuaEnv對(duì)象。給LuaEnv注冊(cè)自定義Loader讓它能從“下載目錄”或“內(nèi)置目錄”讀取Lua文件。執(zhí)行入口Lua腳本由Lua側(cè)接管主界面邏輯和模塊加載。從第5步開始游戲就進(jìn)入Lua世界了。之后就算代碼寫得再爛只要C#殼沒崩線上都是可救的。這里補(bǔ)充一個(gè)容易被忽視的點(diǎn)LuaEnv必須在切換場(chǎng)景后手動(dòng)調(diào)用Tick。XLua的LuaEnv在Unity主循環(huán)里不是自動(dòng)驅(qū)動(dòng)的C#側(cè)需要自己在Update里調(diào)用_luaEnv.Tick()它的作用是驅(qū)動(dòng)Lua側(cè)定時(shí)器、協(xié)程調(diào)度、以及部分GC相關(guān)工作。如果忘了Tick你會(huì)發(fā)現(xiàn)Lua里的協(xié)程不跑、延時(shí)函數(shù)不觸發(fā)排查半天說不定是這個(gè)問題。2.3 Lua腳本與資源的目錄策略運(yùn)行器的Loader設(shè)計(jì)是熱更能否生效的核心。我推薦所有Lua文件按以下優(yōu)先策略加載優(yōu)先從熱更緩存目錄讀取路徑類似Application.persistentDataPath /lua/ 當(dāng)前熱更版本號(hào)。只要這個(gè)目錄里有對(duì)應(yīng)文件就用它。其次從只讀目錄讀取也就是打包進(jìn)安裝包的StreamingAssets或Resources中的Lua。這個(gè)作為首次安裝的基礎(chǔ)版本兜底。這樣設(shè)計(jì)的好處是新包安裝后首次啟動(dòng)沒有下載任何補(bǔ)丁依賴內(nèi)置Lua也能完整跑起來服務(wù)器下發(fā)補(bǔ)丁后Loader會(huì)優(yōu)先命中熱更目錄里的新文件于是代碼更新生效。整個(gè)過程不需要把補(bǔ)丁和安裝包邏輯糾纏在一起。資源部分同理。UI界面、圖集、Prefab這些如果走Unity的AssetBundle或Addressables一定要在Lua層封裝一個(gè)統(tǒng)一的資源加載接口Lua業(yè)務(wù)代碼不直接關(guān)心資源在本地還是遠(yuǎn)端。資源加載接口的封裝優(yōu)先級(jí)甚至比Lua代碼熱更高因?yàn)橘Y源體積通常遠(yuǎn)大于Lua腳本對(duì)增量更新策略的影響也更大。2.4 Lua模塊化別把Lua寫成一個(gè)大文件Lua本身沒有強(qiáng)制模塊規(guī)范但XLua環(huán)境下建議采用類似“一個(gè)文件一個(gè)模塊”的寫法每個(gè)模塊返回一個(gè)table或函數(shù)通過require加載。XLua為require提供了自定義Loader的能力所以模塊路徑可以自己定規(guī)則。有兩種常見組織方式按系統(tǒng)劃分module/home.lua、module/battle.lua、module/mall.lua。這樣做的好處是加載邊界清楚出問題能快速定位。按層劃分view/xxx、model/xxx、ctrl/xxx適合偏MVC的項(xiàng)目。不管用哪種都需要注意一個(gè)細(xì)節(jié)避免require循環(huán)依賴。Lua的require機(jī)制會(huì)標(biāo)記模塊是否已加載循環(huán)require時(shí)會(huì)拿到一個(gè)不完整的table常常出現(xiàn)“attempt to index a nil value”這種不明不白的報(bào)錯(cuò)。我的建議是模塊間依賴盡量自上而下單向流動(dòng)UI模塊可以依賴管理器管理器不要反向引用一堆UI模塊實(shí)在需要反向用的時(shí)候用事件系統(tǒng)解耦不要直接require。事件系統(tǒng)可以放在Lua側(cè)自己實(shí)現(xiàn)也可以由C#側(cè)提供一個(gè)全局的C#事件橋Lua往C#事件橋注冊(cè)回調(diào)。這里有個(gè)坑如果Lua函數(shù)注冊(cè)到C#的event后在Lua層銷毀對(duì)象時(shí)沒有反注冊(cè)會(huì)導(dǎo)致事件源一直持有這個(gè)Lua函數(shù)對(duì)應(yīng)的委托內(nèi)存泄漏就埋下了。后面第4章會(huì)展開講這個(gè)問題。3. XLua接入實(shí)戰(zhàn)從環(huán)境準(zhǔn)備到代碼跑通3.1 環(huán)境準(zhǔn)備與版本選擇接入XLua的第一步是拿代碼。注意XLua有版本分支差異如果你用的是Unity 2020以上版本建議選擇較新版分支老版本在IL2CPP下的表現(xiàn)和宏定義可能有差異。下載后把核心目錄放進(jìn)項(xiàng)目的Assets下整個(gè)插件結(jié)構(gòu)大致包含“運(yùn)行時(shí)庫、編輯器擴(kuò)展代碼、示例、生成代碼目錄”幾部分。Unity版本方面我建議直接用你團(tuán)隊(duì)熟悉的長(zhǎng)期支持LTS版本。每次Unity升大版本都會(huì)引入渲染管線、腳本后端的變化熱更方案通常要跟著回歸一遍沒必要為了追新給自己找事。如果項(xiàng)目是2021或2022 LTS繼續(xù)用就好。安裝后有個(gè)宏定義要注意HOTFIX_ENABLE。這個(gè)宏控制的是XLua的打補(bǔ)丁能力。如果你只打算用Lua寫業(yè)務(wù)不啟用Hotfix也可以但如果你想做到“C#線上出小Bug也能打補(bǔ)丁”就必須在Player Settings - Scripting Define Symbols里加上它。加上之后還需要給允許被Hotfix的C#類標(biāo)記[Hotfix]特性并在打包前生成一次代碼。這個(gè)能力是把雙刃劍它能救急但同樣要求你對(duì)改動(dòng)范圍非常謹(jǐn)慎最好只用來修小問題不能用它做大規(guī)模C#重構(gòu)。3.2 生成代碼為什么總是繞不開這一步XLua文檔里反復(fù)強(qiáng)調(diào)“Generate Code”很多新手覺得麻煩但不理解它的意義。這里有它的原理背景C#和Lua之間互相調(diào)用本質(zhì)上要走一層橋梁。最簡(jiǎn)單的方式是每個(gè)類型都用反射查找方法然后調(diào)用。但反射在移動(dòng)端有兩個(gè)壞處一是慢二是在IL2CPP發(fā)布包中部分類型可能被裁剪掉反射根本找不到。所以XLua采用的做法是在編輯器里掃描你已經(jīng)寫好的C#類型為它們生成專用的適配代碼運(yùn)行時(shí)直接調(diào)用生成好的適配函數(shù)不依賴反射。生成步驟不復(fù)雜在編輯器菜單中找到XLua相關(guān)入口先執(zhí)行“Clear Generated Code”清理舊產(chǎn)物再執(zhí)行“Generate Code”。生成完成后會(huì)產(chǎn)出大量文件到指定目錄這些文件是構(gòu)建期需要參與的不能把它們排除在打包之外。要特別提醒的是Lua代碼訪問哪些C#類型最好讓類型被生成代碼覆蓋。如果你加的C#類型不在任何C#靜態(tài)代碼里被引用XLua可能不知道要為它生成適配但你運(yùn)行Lua訪問它時(shí)其實(shí)也能用反射兜底。發(fā)布版如果連反射都被裁剪了就會(huì)報(bào)找不到類型或方法。所以保險(xiǎn)做法是凡是會(huì)被Lua頻繁訪問的類型都在某個(gè)靜態(tài)類里顯式引用一下或者加入XLua的導(dǎo)出配置列表。這個(gè)規(guī)則是很多項(xiàng)目上線后偶發(fā)報(bào)錯(cuò)的根源。3.3 最小可運(yùn)行案例C#加載Lua入口接入XLua的第一步不是寫業(yè)務(wù)而是先讓一個(gè)Lua文件跑起來。下面是一段極簡(jiǎn)但完整的C#啟動(dòng)代碼using XLua; using UnityEngine; using System.IO; public class LuaBootstrap : MonoBehaviour { private LuaEnv _luaEnv; void Start() { _luaEnv new LuaEnv(); _luaEnv.AddLoader(LoadLuaFile); _luaEnv.DoString(require(GameStart)); } void Update() { _luaEnv?.Tick(); } private byte[] LoadLuaFile(ref string filename) { // 優(yōu)先從熱更目錄讀取 string persistentPath Path.Combine(Application.persistentDataPath, lua, filename .lua); if (File.Exists(persistentPath)) { return File.ReadAllBytes(persistentPath); } // 其次從內(nèi)置Resources目錄讀取 TextAsset textAsset Resources.LoadTextAsset(Lua/ filename); return textAsset ! null ? textAsset.bytes : null; } void OnApplicationQuit() { _luaEnv?.Dispose(); _luaEnv null; } }對(duì)應(yīng)的GameStart.lua可以很簡(jiǎn)單local GameStart {} function GameStart.Run() print(GameStart run) end GameStart.Run() return GameStart這個(gè)案例里最關(guān)鍵的是AddLoader回調(diào)。XLua執(zhí)行require的時(shí)候會(huì)把模塊名作為參數(shù)傳進(jìn)來Loader根據(jù)名字去文件系統(tǒng)或Resources里找對(duì)應(yīng)文件找到就返回字節(jié)數(shù)組找不到就返回null。這個(gè)Loader是整個(gè)熱更架構(gòu)的咽喉Lua文件能不能被正確加載、加載的是新文件還是舊文件全看它的實(shí)現(xiàn)。3.4 Lua側(cè)訪問C#常用映射和寫法約定XLua把C#類型暴露給Lua的方式很直接通過一個(gè)全局表CS訪問方式類似CS.UnityEngine.GameObject。示例-- 創(chuàng)建物體 local go CS.UnityEngine.GameObject(Player) -- 訪問靜態(tài)方法 CS.UnityEngine.Debug.Log(hello) -- 訪問C#對(duì)象成員 go.transform.position CS.UnityEngine.Vector3(0, 1, 0)對(duì)于C#的List、DictionaryXLua默認(rèn)支持映射但團(tuán)隊(duì)里最好約定一個(gè)規(guī)范Lua側(cè)優(yōu)先使用table組織數(shù)據(jù)只在需要與C#系統(tǒng)交互時(shí)才傳List/Dictionary。比如C#接口需要一個(gè)Listint你的Lua代碼不應(yīng)該寫一個(gè)for循環(huán)再去逐元素賦值而是盡量在C#側(cè)改成接收int[]或直接接收自定義參數(shù)對(duì)象減少跨語言的數(shù)據(jù)結(jié)構(gòu)構(gòu)造成本。訪問枚舉、委托、事件也比較常用。例如給一個(gè)按鈕加上Lua回調(diào)btn.onClick:AddListener(function() -- 點(diǎn)擊處理 end)這個(gè)用法看著方便但它隱藏了一個(gè)生命周期問題AddListener的對(duì)象如果后續(xù)沒有RemoveListenerLua側(cè)的匿名函數(shù)引用就不會(huì)被釋放。如果你在每次打開界面時(shí)都加一個(gè)永久監(jiān)聽界面關(guān)了又開監(jiān)聽數(shù)量就會(huì)不斷累積內(nèi)存上漲直到卡頓。后文會(huì)再給一段排查方法。4. 性能與內(nèi)存Lua層寫代碼要守住的幾條紅線4.1 跨語言高頻調(diào)用沒有想象中便宜很多人誤以為XLua生成代碼之后Lua調(diào)C#的開銷就接近原生了。實(shí)際測(cè)過就知道生成代碼確實(shí)比反射快很多但每次調(diào)用仍然有參數(shù)檢查、類型轉(zhuǎn)換、可能存在的對(duì)象映射和GC壓力。一次兩次無所謂一旦進(jìn)入每幀執(zhí)行、循環(huán)上萬次的高頻路徑開銷就會(huì)被放大。舉個(gè)實(shí)際例子一個(gè)戰(zhàn)斗飄字系統(tǒng)每個(gè)單位每秒都調(diào)C#的傷害接口如果每次飄字都從Lua層new一個(gè)C#對(duì)象再傳進(jìn)C#方法累積分配會(huì)很可觀。這需要做批量處理單位先把數(shù)據(jù)收集到本地tableC#接口每次接收一個(gè)數(shù)組渲染層統(tǒng)一消費(fèi)。這樣跨語言調(diào)用次數(shù)從“每單位每秒多次”降到了“整批一次”性能差別肉眼可見。所以有一個(gè)判斷準(zhǔn)則如果一段循環(huán)邏輯需要頻繁訪問C# API就要考慮在C#側(cè)提供批量接口或把它完全挪到C#層。業(yè)務(wù)邏輯在Lua沒問題但不要讓Lua替C#做大量對(duì)引擎的碎調(diào)用。4.2 Lua的GC和臨時(shí)對(duì)象Lua自己帶GC而且Lua 5.3的增量GC比老版本平滑但仍有一個(gè)原則需要守住不要在幀循環(huán)里創(chuàng)建大量臨時(shí)table。如果你每幀都要拼一個(gè)字符串來做UI顯示或者每幀都為了求一個(gè)臨時(shí)坐標(biāo)而new一個(gè)Vector3那么Lua側(cè)GC壓力和C#側(cè)臨時(shí)對(duì)象分配會(huì)同時(shí)飆高。這種代碼看得多了典型表現(xiàn)是Profiler里的GC Alloc穩(wěn)定上漲幀率隨時(shí)間緩慢下降。一個(gè)實(shí)用技巧是在Lua側(cè)維護(hù)小型對(duì)象池。全局坐標(biāo)、臨時(shí)顏色、字符串緩沖區(qū)這些結(jié)構(gòu)都可以復(fù)用。不需要寫很復(fù)雜的池子一個(gè)簡(jiǎn)單的循環(huán)復(fù)用table就能有明顯改善。比如需要在屏幕上一幀內(nèi)繪制大量線段時(shí)完全可以在Lua里緩存一個(gè)坐標(biāo)數(shù)組而不是每一段都單獨(dú)創(chuàng)建一個(gè)新table立刻傳給C#。4.3 Lua對(duì)象引用C#對(duì)象誰是釋放的根這是最常見也最難查的內(nèi)存泄漏來源。Lua側(cè)拿到了一個(gè)C#對(duì)象引用后這個(gè)C#對(duì)象是否會(huì)被Unity回收取決于XLua的訪問映射機(jī)制。當(dāng)Lua不再引用它時(shí)XLua的對(duì)象映射表會(huì)允許C#側(cè)對(duì)象被GC但如果你不小心把Lua函數(shù)注冊(cè)進(jìn)了C#事件那么事件源持有委托委托持有Lua函數(shù)Lua函數(shù)又捕獲了它引用的一堆對(duì)象整條鏈都“活”著內(nèi)存就釋放不了。實(shí)際排查中我總結(jié)了三類高發(fā)場(chǎng)景點(diǎn)擊事件未反注冊(cè)UI界面關(guān)閉前沒有調(diào)用RemoveListener。全局緩存未清理比如把某個(gè)界面的Lua模塊table存到了全局表里界面關(guān)閉后old表仍然被全局引用。C#單例持有Lua委托SDK回調(diào)或網(wǎng)絡(luò)回調(diào)注冊(cè)進(jìn)Lua函數(shù)后成單且不會(huì)再觸發(fā)卻沒有主動(dòng)移除。排查方法也比較直接上線前做功能反復(fù)開關(guān)測(cè)試觀察內(nèi)存增量是否回落。如果某界面開一次漲一些內(nèi)存且永遠(yuǎn)不降十有八九就是這種泄漏。再配合C#側(cè)打點(diǎn)在Lua函數(shù)注冊(cè)事件時(shí)記錄調(diào)用棧就很容易定位到具體模塊。4.4 用數(shù)據(jù)說話性能Profile的基本姿勢(shì)很多團(tuán)隊(duì)優(yōu)化Lua代碼都是靠感覺這是不對(duì)的。推薦做法是在Lua側(cè)內(nèi)置一個(gè)簡(jiǎn)單的性能統(tǒng)計(jì)工具針對(duì)需要關(guān)注的函數(shù)用os.clock()記錄單次調(diào)用耗時(shí)按幀聚合后輸出到日志。local start os.clock() -- TODO 要統(tǒng)計(jì)的邏輯 local cost os.clock() - start if cost 0.01 then print(string.format([LuaProfile] %s cost %.3f ms, module_name, cost * 1000)) end線上環(huán)境把統(tǒng)計(jì)日志關(guān)掉開發(fā)環(huán)境開著優(yōu)化時(shí)用數(shù)據(jù)定位熱點(diǎn)。不要盲目相信“Lua肯定比C#慢”的結(jié)論具體慢在哪、調(diào)用次數(shù)是多少、有沒有GC壓力都得靠數(shù)據(jù)判斷。很多情況下真正的問題不是Lua解釋器慢而是跨語言調(diào)用次數(shù)和臨時(shí)對(duì)象分配導(dǎo)致的。5. 版本補(bǔ)丁與更新流程怎么打出可用的熱更包5.1 版本模型客戶端版本和資源版本要分清楚做熱更框架的第一步是理清版本概念。我建議區(qū)分三個(gè)量安裝包版本客戶端在商店發(fā)布的版本通常由C#殼的代碼決定需要發(fā)商店更新才會(huì)變。Lua資源版本Lua腳本和資源的版本號(hào)這個(gè)可以獨(dú)立于安裝包版本不斷增長(zhǎng)。補(bǔ)丁包版本服務(wù)器側(cè)的某個(gè)完整資源快照用于給客戶端提供增量包。啟動(dòng)時(shí)客戶端把自己的安裝包版本和當(dāng)前Lua資源版本上報(bào)給服務(wù)器服務(wù)器返回可用的最新全量版本信息和增量更新清單。這種設(shè)計(jì)能處理很多實(shí)際場(chǎng)景比如用戶安裝了一個(gè)很老的包中間隔了好幾個(gè)資源版本這時(shí)候做增量更新會(huì)算出很大的增量列表不如直接下發(fā)全量包。而如果用戶插件版本比較新只需要修補(bǔ)幾個(gè)最新的Lua文件就可以做增量。5.2 增量包生成策略不要只按時(shí)間戳篩文件一個(gè)常見誤區(qū)是以為增量包等于“在這個(gè)時(shí)間點(diǎn)以后修改過的文件”。實(shí)際項(xiàng)目中會(huì)因?yàn)闃?gòu)建機(jī)器和源碼目錄的修改時(shí)間不穩(wěn)定偶發(fā)漏掉文件或者加入無關(guān)文件這是一個(gè)比較常見的問題。我推薦的做法是用文件MD5做對(duì)比。打包工具遍歷全量Lua與資源目錄生成一份Manifest清單包含文件名、大小、MD5。服務(wù)器構(gòu)建增量包時(shí)拿著最新全量清單和客戶端當(dāng)前版本清單對(duì)比MD5不同的文件進(jìn)增量包新增文件進(jìn)增量包MD5完全一致的天然跳過。這樣不受時(shí)間戳干擾而且能保證“只要文件內(nèi)容沒變用戶就不用重復(fù)下載”。Manifest文件本身要放在最前面被客戶端讀取而且Manifest的MD5最好再由服務(wù)器接口返回一次防中間環(huán)節(jié)被篡改?？蛻舳四玫組anifest后逐文件校驗(yàn)MD5任何一步不過都判定本次更新失敗回到可用舊版本。5.3 下載完成后別急著加載熱更補(bǔ)丁下載后是直接寫入設(shè)備存儲(chǔ)的不需要立刻覆蓋正在使用的資源。標(biāo)準(zhǔn)做法是啟動(dòng)時(shí)請(qǐng)求版本信息。下載新版本文件到臨時(shí)目錄校驗(yàn)MD5。全部校驗(yàn)通過后原子性地替換當(dāng)前Lua目錄。替換時(shí)若無法直接覆蓋目錄可以先把當(dāng)前目錄改名備份再放入新目錄。確認(rèn)新版運(yùn)行正常后刪除或保留備份版本用于回滾。“別急著加載”的意思是說不要在補(bǔ)丁還沒完全落盤時(shí)就讓業(yè)務(wù)代碼嘗試讀取。冷啟動(dòng)階段可以阻塞等待更新完成這個(gè)過程一般控制在幾秒內(nèi)。如果補(bǔ)丁較大需要加進(jìn)度條如果網(wǎng)絡(luò)請(qǐng)求超時(shí)要給默認(rèn)舊版本繼續(xù)啟動(dòng)的機(jī)會(huì)不能讓用戶卡在更新界面。5.4 平臺(tái)差異和構(gòu)建配置的注意點(diǎn)這里專門提一下Android和iOS的差異。Android上腳本和資源可以放在外部存儲(chǔ)目錄熱更新實(shí)現(xiàn)相對(duì)自由。iOS的沙盒機(jī)制限制了你只能寫自己的應(yīng)用目錄但Application.persistentDataPath是一個(gè)合法的寫目錄熱更文件放到這里沒有問題。所以從工程上看不用管平臺(tái)有什么“隱藏限制”只要統(tǒng)一走persistentDataPath邏輯即可。還有一個(gè)容易踩的構(gòu)建坑隨著Android對(duì)API Level的要求逐年提升很多人會(huì)去調(diào)minimum API level和target API level。這時(shí)候如果項(xiàng)目里有XLua依賴的原生庫要確保原生庫的ABI和導(dǎo)出配置一致。只保留arm64-v8a可以顯著減小包體前提是你所有依賴的第三方庫都提供了arm64版本。如果某個(gè)so庫只放了armeabi-v7a又強(qiáng)制在arm64設(shè)備上走64位進(jìn)程那么Unity在加載時(shí)會(huì)報(bào)類似“unable to load dll”的錯(cuò)誤。XLua自身保持更新比較容易適配但項(xiàng)目里其它私有庫就需要自行核對(duì)。另外Addressables或者AssetBundle資源記得做版本分組。Lua代碼和美術(shù)資源可以分成兩條補(bǔ)丁線或合并成一個(gè)大包。通常建議Lua代碼補(bǔ)丁盡量小因?yàn)榇a更新最頻繁客戶端希望快速同步美術(shù)資源包則按需更新UI圖集之類的大文件可以走延遲加載。這里的取舍是代碼包越小更新成功率越高更新失敗影響范圍越小。所以盡量把大資源拆走到資源包里不要讓Lua腳本目錄混進(jìn)幾百M(fèi)B的Prefab和貼圖。6. 實(shí)際項(xiàng)目里的常見報(bào)錯(cuò)與排查技巧6.1 一張速查表應(yīng)付大多數(shù)運(yùn)行時(shí)報(bào)錯(cuò)很多同學(xué)在群里發(fā)報(bào)錯(cuò)截圖問題其實(shí)都集中在幾個(gè)典型場(chǎng)景。這里整理了一張速查表基本覆蓋熱更相關(guān)的頭號(hào)問題報(bào)錯(cuò)特征可能原因處理方式LuaException: ... attempt to index a nil valuerequire的模塊不存在或循環(huán)依賴導(dǎo)致模塊table為nil優(yōu)先檢查L(zhǎng)oader路徑與模塊文件名是否對(duì)應(yīng)再看是否有循環(huán)requireDllNotFoundException: Unable to load DLL xlua or one of its dependencies原生庫缺失或ABI不匹配確認(rèn)libxlua已打入包內(nèi)檢查Android的ABI過濾是否把對(duì)應(yīng)so排除了InvalidOperationException: ... has been destroyedLua仍持有已被Unity銷毀的C#對(duì)象對(duì)象銷毀后確保Lua側(cè)引用置空事件監(jiān)聽反注冊(cè)找不到C#方法或類型目標(biāo)類型沒參與XLua生成代碼IL2CPP裁剪掉反射路徑在C#側(cè)顯式引用目標(biāo)類型重新Generate Code并打包Lua協(xié)程不執(zhí)行或延時(shí)不準(zhǔn)LuaEnv沒有每幀Tick在C#的Update中調(diào)用_luaEnv.Tick()內(nèi)存只增不降Lua函數(shù)被C#事件持有模塊table被全局引用用對(duì)象緩存和接口開關(guān)復(fù)測(cè)定位反向持有點(diǎn)這張表不是背答案而是給排障提供一個(gè)起點(diǎn)。實(shí)際排查時(shí)還要結(jié)合函數(shù)堆棧和代碼上下文但八成問題都落在這些根因上。6.2 報(bào)錯(cuò)和原生庫直接相關(guān)時(shí)的排查步驟熱更方案遇到原生庫報(bào)錯(cuò)的第一反應(yīng)不要慌按下面順序排查確認(rèn)自己的移動(dòng)端包是否真的包含了對(duì)應(yīng)插件。用解包工具看包內(nèi)lib/arm64-v8a或lib/x86_64下是否有l(wèi)ibxlua相關(guān)文件。確認(rèn)Unity構(gòu)建時(shí)的IL2CPP Architecture設(shè)置。如果你同時(shí)勾選了arm64和x86_64而某個(gè)第三方庫只有arm64構(gòu)建時(shí)可能不會(huì)報(bào)錯(cuò)但運(yùn)行時(shí)在模擬器或某些設(shè)備上會(huì)崩潰。檢查是否用的開發(fā)版配置調(diào)試模式下某些庫路徑和發(fā)布版不同。很多“為什么我只改了API Level就崩了”的問題根因都是原生庫ABI不匹配而不是API Level本身。先把架構(gòu)列表統(tǒng)一再試高版本API。6.3 Lua側(cè)的調(diào)試工具選擇關(guān)于Lua IDE我一直建議不要在純文本編輯器里硬寫大項(xiàng)目。JetBrains全家桶里雖然有部分Lua插件支持但完整度更好的是EmmyLua插件它同時(shí)提供VSCode版和IDEA版。裝好之后可以實(shí)現(xiàn)代碼補(bǔ)全、函數(shù)簽名、跳轉(zhuǎn)定義還能和運(yùn)行中的Unity進(jìn)程連上斷點(diǎn)調(diào)試。有了斷點(diǎn)調(diào)試不等于不用打日志。XLua的Lua運(yùn)行錯(cuò)誤堆棧默認(rèn)是進(jìn)Unity Console的但如果你用Application.logMessageReceived做了日志轉(zhuǎn)發(fā)可以把它發(fā)送到自己的遠(yuǎn)端日志系統(tǒng)。這個(gè)建議越早上越好特別是線上發(fā)生熱更后客戶端日志是唯一線索。我見過很多項(xiàng)目上線后熱更出了問題開發(fā)者只能靠玩家截圖反推非常痛苦有日志通道后一天能解決的問題當(dāng)時(shí)拖了一周。6.4 發(fā)布前的熱更回歸清單最后整理一份我們上線前例行檢查的清單短小但真實(shí)有用打一個(gè)新安裝包不觸發(fā)任何更新舊版本Lua能否完整跑通主流程打一個(gè)增量補(bǔ)丁從上一個(gè)版本升級(jí)到新版啟動(dòng)日志確認(rèn)更新成功強(qiáng)制斷網(wǎng)模擬弱網(wǎng)確認(rèn)能走舊版本兜底不白屏不卡死用一個(gè)玩家數(shù)據(jù)較多的賬號(hào)跑一遍涉及資源熱更的核心玩法反復(fù)進(jìn)出一個(gè)復(fù)雜UI 20次觀察內(nèi)存是否恢復(fù)到初始水平這些檢查我在項(xiàng)目里每次發(fā)布都會(huì)執(zhí)行。熱更鏈路在開發(fā)環(huán)境通暢不代表發(fā)布環(huán)境通暢因?yàn)榇虬渲?、目錄?quán)限、網(wǎng)絡(luò)環(huán)境都可能臨時(shí)出問題。與其上線后再被動(dòng)修復(fù)不如把冒煙測(cè)試固化到CI流程里每次構(gòu)建后自動(dòng)跑一遍核心用例。我個(gè)人在實(shí)際維護(hù)熱更框架時(shí)最大的體會(huì)是熱更不是某一個(gè)單獨(dú)的插件而是一條從構(gòu)建到下載再到業(yè)務(wù)運(yùn)行的完整鏈路。鏈條上任何一環(huán)出現(xiàn)偏差玩家體驗(yàn)都是落地到“下載更新失敗”或“卡在啟動(dòng)界面”。所以與其糾結(jié)某個(gè)局部API的用法不如先把框架的整體邊界、版本模型、Load順序、回滾策略想清楚再一頭扎進(jìn)代碼。這些成熟的框架思路也是我在幾個(gè)項(xiàng)目里反復(fù)試錯(cuò)后沉淀下來的希望能幫你少踩一些我已經(jīng)踩平的坑。