、重復(fù)資源與包體膨脹)
搞Unity客戶端這么些年AssetBundle打包這件事可以說是我在項目上線前最不敢掉以輕心的一環(huán)。你平時開發(fā)時在編輯器里跑得再流暢真到打AB包、出正式包那天依賴環(huán)、重復(fù)資源、包體膨脹這幾個老冤家總會挑一個蹦出來惡心你。尤其是現(xiàn)在手游動輒幾百兆甚至上G紅米、低端機一大堆包體大一點、加載卡一點玩家口碑和次留直接崩。這篇東西就是把我自己反復(fù)踩坑之后沉淀下來的一套打包前“體檢”和“急救”流程專門治依賴環(huán)、重復(fù)資源和包體膨脹這三座大山適合正在做Unity項目的人拿回去直接抄作業(yè)。先說清楚一點這套東西不是高深的底層黑科技更多是“把該做的事做到位”。很多團隊不是不會而是沒把打包當工程問題來治理導(dǎo)致上線前全靠人肉看報告、瞎試最后草草提交。如果你正面臨打包依賴報錯、AB重疊資源一大堆、包體從500M漲到800M還找不到元兇那這篇值得你花十分鐘看完。1. 為什么AssetBundle打包會失控三個核心病根先說結(jié)論依賴環(huán)、重復(fù)資源、包體膨脹從來不是三個獨立的問題它們是一根藤上結(jié)出的三個瓜。很多團隊只盯著包體數(shù)字卻不知道包體變大有一大半是被前兩個問題逼出來的。1.1 依賴環(huán)是怎么悄悄長出來的AssetBundle的依賴機制本身不復(fù)雜A包里的資源引用了B包的資源運行時通過引用計數(shù)和依賴關(guān)系加載。問題在于Unity的打包器不是人的思維它只是機械地把所有被引用到的資源歸到“某個包”里然后生成依賴圖。一旦你的資源之間存在交叉引用比如Prefab A掛在Character B上Character B又掛回Prefab A的某個組件打包器就可能陷入“你到底該去哪個包找”的尷尬。我見過最典型的依賴環(huán)長這樣UI模塊的Prefab引用了角色模型上的一套骨骼動畫而角色模型那邊的Prefab又引用了UI模塊里的某個圖標或通用文本組件。從業(yè)務(wù)邏輯上看這倆“不該扯上關(guān)系”但美術(shù)或程序為了圖方便直接拖拽引用依賴環(huán)就那么被造出來了。依賴環(huán)的直接后果是打包器在計算依賴關(guān)系時要么遞歸爆掉要么干脆把環(huán)里的資源全部塞進同一個包導(dǎo)致AB體積飆升、加載時的依賴遍歷多繞一圈內(nèi)存上還會出現(xiàn)AB包無法卸載的“假泄漏”——Unity官方文檔里專門警告過這種循環(huán)引用是資源管理黑洞。1.2 重復(fù)資源是從哪里進來的重復(fù)資源和依賴環(huán)往往是伴生關(guān)系。當同一個材質(zhì)、紋理、Mesh被多個AB包共同引用而你的打包策略又是“每個邏輯模塊單獨打成AB包”時Unity的默認行為并不是幫你把這顆共享資源抽出去而是在每個依賴它的AB包里各自生成一份拷貝。舉個例子你有一個通用按鈕皮膚貼圖UI包引用它新手引導(dǎo)包也引用它角色創(chuàng)建包還引用它。如果你按UI、引導(dǎo)、創(chuàng)建分成三個AB只因為打包粒度太細或沒顯式把通用資源劃走最終打出來的包就是三份一模一樣的貼圖在各自AB里躺尸。這種冗余在報告里不會報錯但一算總包體白白胖了10%-30%都屬于正常操作。很多人以為用了Addressable就沒這問題了其實Addressable底層也是AssetBundle如果你不關(guān)注資源分組和依賴回收它照樣給你復(fù)制成三份。對我試過血淚教訓(xùn)。1.3 包體膨脹是上面的“果”不是“因”包體膨脹這個表象大多數(shù)人首先懷疑貼圖壓縮格式、模型面數(shù)、音頻碼率很少有人第一時間去查依賴環(huán)和重復(fù)資源。但實際項目里一個600M的包你可能優(yōu)化完貼圖壓縮省下80M回頭一看依賴環(huán)把兩個大模型場景綁在了一起又給旁邊塞了30M的冗余等于白干。所以這套治理思路的第一步不是沖上去壓貼圖而是先把依賴關(guān)系和資源歸屬理干凈讓每個資源“只住一個屋”。在這個基礎(chǔ)上再談壓縮格式、Shader變體這些“錦上添花”的手段。順序搞反了你只會越優(yōu)化越痛苦改一個配置牽出一串新問題。2. 依賴環(huán)診斷與治理從“事后爆”到“事前提”依賴環(huán)這個東西最麻煩的不是它多難解決而是它總在打包的中后期才冒出來。你項目跑得好好的一打AB報錯也好、不報錯但加載出問題也好人肉定位能卡掉你一下午。2.1 不靠肉眼寫個Editor腳本自動掃依賴環(huán)我強烈建議你在項目里留一個Editor腳本專門做依賴圖的環(huán)檢測。原理不復(fù)雜用AssetDatabase.GetDependencies或者直接遍歷BuildPipeline.GetDependenciesForAsset把每個資源的引用關(guān)系看成有向圖然后跑一趟DFS看有沒有回邊。下面這段是我項目里一直在用的簡化版本你們可以直接貼到Editor目錄里用using System.Collections.Generic; using System.Linq; using UnityEditor; using UnityEngine; public static class DependencyCycleDetector { [MenuItem(Tools/依賴檢查/檢測Asset依賴環(huán))] public static void DetectCycles() { string[] allAssetPaths AssetDatabase.GetAllAssetPaths() .Where(p p.StartsWith(Assets/)) .Where(p !p.EndsWith(.cs) !p.EndsWith(.js)) .ToArray(); var graph new Dictionarystring, Liststring(); foreach (var path in allAssetPaths) { string[] deps AssetDatabase.GetDependencies(path, false); graph[path] deps.Where(d d.StartsWith(Assets/)).ToList(); } var visited new HashSetstring(); var stack new HashSetstring(); var cycleFound false; foreach (var node in graph.Keys) { if (!visited.Contains(node)) { if (DFS(node, graph, visited, stack)) { cycleFound true; Debug.LogWarning($[依賴環(huán)] 檢測到包含 {node} 的依賴環(huán)請檢查后重新打包); } } } if (!cycleFound) Debug.Log([依賴檢查] 未發(fā)現(xiàn)依賴環(huán)可以放心打包); } static bool DFS(string current, Dictionarystring, Liststring graph, HashSetstring visited, HashSetstring stack) { if (stack.Contains(current)) return true; if (visited.Contains(current)) return false; visited.Add(current); stack.Add(current); if (graph.TryGetValue(current, out var deps)) { foreach (var dep in deps) { if (!visited.Contains(dep) || stack.Contains(dep)) { if (DFS(dep, graph, visited, stack)) return true; } } } stack.Remove(current); return false; } }這段腳本的核心思路是“染色法”visited標記所有訪問過的節(jié)點stack標記當前DFS路徑上的節(jié)點。如果訪問過程中走到了stack里的節(jié)點說明這條鏈路形成了閉環(huán)。跑完一遍菜單點一下能在打包前把環(huán)揪出來比等打包失敗再去猜快太多了。2.2 什么情況最容易觸發(fā)依賴環(huán)怎么預(yù)防依賴環(huán)通常集中在幾個場景UI與角色互相引用、動畫狀態(tài)機改在Prefab上卻反引UI、模塊之間的“臨時引用”忘了拆。我的建議是美術(shù)資源一律不允許直接引用UI的圖集或文本配置UI層也不允許直接把角色Prefab拖進組件引用而要通過事件或資源地址去拿。預(yù)防的抓手在規(guī)范上但規(guī)范的落地要靠工具。比如做一個Editor腳本Prefab保存時自動檢查它的依賴里有沒有“不該出現(xiàn)的目錄”違反規(guī)則直接彈警告。類似這種“保存即檢查”的機制效果比月末審代碼好十倍。需要多嘴一句AssetBundle的依賴環(huán)檢測工具市面上也有一些第三方插件和UI能可視化依賴圖。但說實話對于大多數(shù)中小團隊自己寫腳本加簡單的環(huán)檢測就夠用了不用一上來就上重工具。工具越復(fù)雜團隊越不想維護最后又變成擺設(shè)。2.3 打破依賴環(huán)的三種有效姿勢如果已經(jīng)查出來有環(huán)破解方式無非三種提取公共資源、拆分層級、反轉(zhuǎn)依賴方向。提取公共資源把環(huán)里的公共部分比如共享的材質(zhì)、通用UI元素、公共配置單獨抽成一個“公共包”兩邊都只引用這個包環(huán)自然斷開。拆分層級從“UI層”和“邏輯層”的角度重新劃分AB分組例如把UI資源歸為一個頂層A類把角色資源歸為B類禁止A反向引用B的具體Prefab只允許B引用A的通用資源。反轉(zhuǎn)依賴方向?qū)嵲跓o法避免跨層引用就把引用方向從“UI引用角色”改成“角色發(fā)送事件UI監(jiān)聽事件”代碼層解耦之后資源引用關(guān)系自然就干凈了。我個人最推薦第一種“提取公共資源”因為它不僅破環(huán)同時也在給后面的“去重復(fù)資源”打基礎(chǔ)。實際上很多重復(fù)資源問題也恰恰是因為你沒有一個明確的“公共資源包”而造成的。3. 重復(fù)資源排查與優(yōu)化讓每份資源只住一個屋依賴環(huán)解決了下一步就是清點“資源住址”。做Unity打包裝機的同學(xué)都有體會真正的包體殺手往往是重復(fù)資源同一個貼圖、同一個模型散落在不同AB包里最后全都塞進安裝包。3.1 用打包報告追查冗余資源Unity從打包時生成的BuildReport里其實有非常豐富的信息但默認界面上只給你看總大小和幾個維度不展開看不到細節(jié)。你可以直接寫一個腳本在打包后自動讀取BuildReport把所有AB包里引用的Asset路徑拍平找出“同一個路徑被多個AB包引用”的清單。下面是我項目里實際在用的統(tǒng)計邏輯打包后自動輸出一份重復(fù)資源報告public static void GenerateDuplicateReport() { var reportFile Temp/LastBuildReport.json; var loadedReport UnityEditor.Build.Reporting.BuildReportUtility.GetLastReport(); if (loadedReport null) { Debug.LogError(沒有找到上一次的BuildReport請先執(zhí)行一次打包); return; } var assetToBundles new Dictionarystring, Liststring(); foreach (var packedAsset in loadedReport.packedAssets) { var bundleName packedAsset.shortPath; foreach (var content in packedAsset.contents) { var assetPath content.sourceAssetPath; if (!assetToBundles.ContainsKey(assetPath)) assetToBundles[assetPath] new Liststring(); assetToBundles[assetPath].Add(bundleName); } } var duplicates assetToBundles .Where(kv kv.Value.Count 1) .OrderByDescending(kv kv.Value.Count) .ToList(); Debug.Log($[重復(fù)資源] 共發(fā)現(xiàn) {duplicates.Count} 個資源被多個AB包引用); foreach (var item in duplicates) { Debug.LogWarning(${item.Key} —— 被 {string.Join(, , item.Value)} 引用); } }跑完這份報告你就可以清楚地看到哪顆貼圖被UI包、引導(dǎo)包、商城包同時引用了。注意這里統(tǒng)計的是“打包結(jié)果”層面的重復(fù)不是Assets目錄下的重復(fù)文件。很多團隊目錄里沒有重復(fù)文件但打包結(jié)果卻有重復(fù)拷貝就是因為AB分組和依賴關(guān)系沒理清。3.2 去重不是“看見重復(fù)就刪”先算賬我踩過最深的坑就是拿到報告后一股腦去“去重”結(jié)果把幾張被高頻公用的小貼圖硬塞進公共包反而導(dǎo)致首包加載變慢、公共包鎖定的資源太多、沒法按需下載。所以去重前一定要復(fù)盤這組資源的使用場景。我的建議是三層判斷如果這個資源被5個以上模塊引用且文件體積大比如超過1MB那一定要抽到公共包或大資源包重復(fù)就是純浪費。如果只有2-3個模塊引用且文件體積很小比如幾十KB的小貼圖合并成一個“通用素材包”也行但別拆太碎。如果它只在一個模塊內(nèi)被復(fù)用那基本問題不大你只需要確認它所在的AB分組是否合理。另外別忘了UI圖集。Unity的SpriteAtlas如果設(shè)置不當不同圖集之間也可能穿插引用同一張源圖造成圖集A里面有它圖集B也打包進去了。檢查Atlas的Include in Build開關(guān)和關(guān)聯(lián)的Sprite引用是必要步驟。3.3 用“一個資源只屬于一個AB包”作為分組準繩治理重復(fù)資源最根本的辦法是讓分包規(guī)則清晰到“傻瓜都能執(zhí)行”。我一般把項目里的資源劃分成這幾類對應(yīng)不同類型的AB包公共基礎(chǔ)包UI骨架、通用Shader、通用圖集、字體、公共特效角色相關(guān)包模型、動作、專屬貼圖材質(zhì)場景相關(guān)包地圖、光照、大模型、場景特效玩法模塊包各玩法獨立的一組資源按需加載這種分法的關(guān)鍵是讓每個資源在目錄結(jié)構(gòu)里就能看出來該歸哪個包。比如所有公用圖標統(tǒng)一放在Assets/Art/Shared/UI/Icons下打成SharedUI包角色資源只在Assets/Art/Characters/CharacterA下打成CharacterA包。目錄即分包不用額外維護一份巨大的映射表否則你上線前根本不敢動資源。你還可以寫一個“目錄到Bundle名”的自動映射腳本來輔助打包讓Unity按照目錄約定自動決定每個資源屬于哪個AB包。這比手動一個個指定BundleName維護成本低得多也避免了“手動指定時漏了某個資源結(jié)果它被默認打進別的包”的尷尬。4. 包體膨脹分析與瘦身實操不只是改一個壓縮格式當依賴關(guān)系和重復(fù)資源都梳理干凈后你手里的包體才是“真實體量”這時候再去做壓縮和精簡才有意義。這部分的干貨我可以寫好幾篇文章這里只挑最影響結(jié)果的幾個環(huán)節(jié)說。4.1 先做“包體畫像”搞清楚每一兆花在哪拿到BuildReport后先別急著優(yōu)化按資源類型做一次聚合統(tǒng)計貼圖占多少、模型占多少、音頻占多少、Shader占多少、AB包頭和Manifest占多少。這一步非常關(guān)鍵很多人一急就沖進貼圖目錄去改壓縮格式結(jié)果發(fā)現(xiàn)真正的大頭是某個忘了壓縮的巨大模型白忙一場。我自己習(xí)慣打包后立刻跑一段統(tǒng)計腳本代碼也不復(fù)雜var groups loadedReport.packedAssets .SelectMany(p p.contents) .GroupBy(c c.type.ToString()) .Select(g new { Type g.Key, TotalSize g.Sum(x x.packedSize) }) .OrderByDescending(x x.TotalSize); foreach (var group in groups) Debug.Log(${group.Type}: {group.TotalSize / (1024f * 1024f):F2} MB);跑完之后你會對包體分布一目了然。比如發(fā)現(xiàn)Mesh占了大頭就別死磕貼圖了發(fā)現(xiàn)Shader編譯產(chǎn)物異常大就該去查變體收集策略。4.2 貼圖、模型、音頻、Shader的實戰(zhàn)壓縮清單貼圖這是最常規(guī)的包體大頭。優(yōu)先把平臺格式設(shè)為ASTC移動端根據(jù)用途選擇壓縮質(zhì)量。UI貼圖通常不需要Mipmap關(guān)閉后能省大概33%內(nèi)存和磁盤占用模型貼圖可以開Mipmap但要設(shè)好大小限制。圖集合并這個事適合做但別貪圖集越大加載進內(nèi)存的顆粒度越粗反而容易在只顯示一塊UI時被迫加載整張圖集。模型Mesh的壓縮率常常被忽略。模型導(dǎo)入設(shè)置里的Mesh Compression默認Off你可以設(shè)為Low或Medium配合優(yōu)化頂點數(shù)據(jù)能壓掉不少體積。另外動畫文件里的骨骼數(shù)量、曲線精度也可以壓縮對包體貢獻很大。音頻長音樂和語音用Vorbis高壓縮比短音效用ADPCM或盡量減少時長。很多人都知道碼率參數(shù)但忘了檢查“音效時長”本身——很多策劃喜歡在音效文件里留好幾秒空白尾音這種冗余對包體和內(nèi)存都是純浪費。Shader這是最隱蔽的膨脹源。Shader變體如果沒做收集Unity會把所有開啟的關(guān)鍵字組合都打進變體集合你一個Shader可能有幾百上千個變體包體瞬間脹出幾十M。所以一定要做ShaderVariantCollection并且在打包時做變體裁剪。如果項目用了大量第三方Shader更得先查變體否則你怎么壓貼圖都補不回這個洞。4.3 LZ4還是LZMA壓縮策略沒那么好選AB包的壓縮方式一般用LZ4或LZMA。LZMA壓縮率高但解壓的時候CPU開銷大還得整體解壓到內(nèi)存才能用LZ4壓縮率低一點但加載快還能隨機訪問。我的習(xí)慣是首包必須用的核心AB用LZ4后續(xù)熱更或按需下載的包用LZMA能省一點下載量。但游戲?qū)虞d速度很敏感的話也可以全部LZ4犧牲一點包體換流暢度。這個取舍一定要和項目性能組對齊別自己拍腦袋。另外提醒一句別迷信“必須把所有AB壓縮率拉到最高”。壓縮率上來之后解壓時的峰值內(nèi)存也會上去低端機本來就緊張可能因此卡頓或閃退。包體數(shù)字漂亮不等于體驗好。5. 上線前自動“揪問題”把體檢變成流水線講到這里大家應(yīng)該發(fā)現(xiàn)了依賴環(huán)、重復(fù)資源、包體膨脹這些問題單靠上線前人工查一次遠遠不夠。因為項目在持續(xù)迭代今天清干凈了明天新合入一個分支又造出來一個環(huán)。最穩(wěn)的做法是把它塞進CI流程打包后自動體檢不符合指標就失敗別讓壞包流到提測環(huán)節(jié)。5.1 一個打包后自動化檢查腳本的骨架我建議在每個打包流水線后面接一個“AB體檢”步驟檢查項至少覆蓋依賴環(huán)檢測、重復(fù)資源超閾值檢測、包體總量超閾值檢測、單包大小異常檢測。滿足條件的報告自動發(fā)到構(gòu)建平臺不合格就直接標紅。這段是檢查單包大小的核心邏輯可以掛在打包命令之后public static void CheckBundleSizeLimits() { var bundlesDirectory Assets/StreamingAssets/AB; var allBundles Directory.GetFiles(bundlesDirectory, *, SearchOption.AllDirectories) .Where(f !f.EndsWith(.manifest)) .ToList(); foreach (var bundlePath in allBundles) { var size new FileInfo(bundlePath).Length; var bundleName Path.GetFileName(bundlePath); if (size 30 * 1024 * 1024) // 單包超過30M就報警 Debug.LogWarning($[AB體檢] 包 {bundleName} 體積異常: {size / (1024f * 1024f):F2}MB); } }流程整體上就是三步一、觸發(fā)打包二、跑構(gòu)建后檢查三、把報告回傳到CI平臺由CI根據(jù)結(jié)果決定這包能不能進提測環(huán)境。如果你用的是Jenkins或GitLab CI直接在命令里加上這些Editor腳本的調(diào)用入口幾行代碼的事。5.2 檢查清單我在每次出包前必過的8項整理了一份我現(xiàn)在每天都在用的清單分享給你們參考檢查項標準檢查方式依賴環(huán)0個自動腳本DFS跨AB引用數(shù)不超過30個且都在白名單內(nèi)BuildReport統(tǒng)計重復(fù)資源體積占比低于總包體5%自定義報告單AB包最大體積不超過30MB文件掃描AB包總數(shù)量每個平臺不超過300個文件掃描貼圖壓縮格式全部為ASTC移動端自定義檢查Shader變體數(shù)每Shader不超過200個ShaderVariantCollection總包體增量和上一版對比增幅不超過5%CI對比腳本你可以根據(jù)自己的項目調(diào)整閾值但重點是把“標準”寫下來讓它變成團隊共同遵守的規(guī)矩而不是你一個人在編輯器里手動看。5.3 用差異對比抓“增量膨脹”我還特別推薦在CI里保留上次構(gòu)建的Report快照每次新打一包自動對比新舊兩個包在“每個AB的大小差”。這一招能讓你快速定位“這次到底是哪個資源吃掉了包體增量”。我見過不少團隊只知道包從600M漲到700M但說不清漲在哪最后只能靠運營、策劃一個個去猜。有了自動對比新人也能幾秒內(nèi)定位到具體資源。做法不復(fù)雜打包腳本里把這個包的報告序列化保存到一個固定目錄CI腳本對比時反序列化后按“AB包名”做diff輸出成表格。如果某個AB增量超過10%那說明這次迭代里的某個資源導(dǎo)入方式出問題了大概率是忘了壓縮、模型沒合批或者多人協(xié)作時把大文件直接塞進AB的目錄里了。6. 常見問題與排查技巧實錄最后這部分我把自己這些年遇到的高頻問題按“現(xiàn)象—原因—解法”整理成一個速查表算是給前面所有內(nèi)容的落地補個底。實際項目里遇到老問題翻這張表比翻文檔快?，F(xiàn)象常見原因排查思路打包報循環(huán)依賴錯誤Asset引用形成閉環(huán)先跑2.1的環(huán)檢測腳本定位資源鏈路運行時加載AB提示找不到依賴依賴資源沒進StreamingAssets或下載路徑不對檢查Manifest文件、檢查依賴AB是否被打成獨立包同一貼圖在不同包各出現(xiàn)一次公共資源未單獨分組查BuildReport重復(fù)資源清單抽出公共包包體比上一版突然大20M新合入資源導(dǎo)入設(shè)置不對用CI diff腳本對比增量定位具體ABUI界面加載卡頓AB包粒度過大整包加載拆分每個界面為獨立AB用LZ4壓縮Shader變體導(dǎo)致打包巨慢且包體畸形變體數(shù)量爆炸手動構(gòu)建ShaderVariantCollection并裁剪關(guān)鍵字AB無法Unload依賴環(huán)或跨AB引用未清理排查依賴圖、檢查對象的卸載策略我再補充一個容易忽略的技巧StreamingAssets里的AB包如果你用C#自帶的File操作去讀取別忘加上路徑拼接時對平臺差異的處理。Android要拿到j(luò)ar包內(nèi)路徑很多時候要用UnityWebRequest來讀直接File.ReadAllBytes在Android上會出現(xiàn)讀取不到文件的問題。這種事不報錯但運行失敗排查起來特別費勁。另外一個小心得不要等到“上線前”才做整套治理。先把檢查腳本放進日常開發(fā)每個版本提測前都跑一遍哪怕只跑依賴環(huán)和重復(fù)資源檢查也能在早期攔下一批問題。等到了真正提審、出包的前一晚你才能睡個安穩(wěn)覺。說到底AssetBundle打包治理不是一次性項目而是一套需要持續(xù)維護的過程。我見過太多團隊在“崩一下修一下”的循環(huán)里反復(fù)掙扎核心原因就是沒有把“規(guī)則”和“工具”沉淀下來。希望這套流程和腳本能幫你在下次出包時少踩幾個坑。如果你手上項目已經(jīng)在Android、iOS、微信小游戲這些平臺上遇到了打包差異問題或者下一步準備接入Addressable那在動手換工具之前先把這套體檢腳本跑起來。你會發(fā)現(xiàn)很多遷移過程中的坑本質(zhì)上還是依賴環(huán)和重復(fù)資源的老問題換了個新皮膚而已。 Unity AssetBundle打包治理：根治依賴環(huán)、重復(fù)資源與包體膨脹
搞Unity客戶端這么些年AssetBundle打包這件事可以說是我在項目上線前最不敢掉以輕心的一環(huán)。你平時開發(fā)時在編輯器里跑得再流暢真到打AB包、出正式包那天依賴環(huán)、重復(fù)資源、包體膨脹這幾個老冤家總會挑一個蹦出來惡心你。尤其是現(xiàn)在手游動輒幾百兆甚至上G紅米、低端機一大堆包體大一點、加載卡一點玩家口碑和次留直接崩。這篇東西就是把我自己反復(fù)踩坑之后沉淀下來的一套打包前“體檢”和“急救”流程專門治依賴環(huán)、重復(fù)資源和包體膨脹這三座大山適合正在做Unity項目的人拿回去直接抄作業(yè)。先說清楚一點這套東西不是高深的底層黑科技更多是“把該做的事做到位”。很多團隊不是不會而是沒把打包當工程問題來治理導(dǎo)致上線前全靠人肉看報告、瞎試最后草草提交。如果你正面臨打包依賴報錯、AB重疊資源一大堆、包體從500M漲到800M還找不到元兇那這篇值得你花十分鐘看完。1. 為什么AssetBundle打包會失控三個核心病根先說結(jié)論依賴環(huán)、重復(fù)資源、包體膨脹從來不是三個獨立的問題它們是一根藤上結(jié)出的三個瓜。很多團隊只盯著包體數(shù)字卻不知道包體變大有一大半是被前兩個問題逼出來的。1.1 依賴環(huán)是怎么悄悄長出來的AssetBundle的依賴機制本身不復(fù)雜A包里的資源引用了B包的資源運行時通過引用計數(shù)和依賴關(guān)系加載。問題在于Unity的打包器不是人的思維它只是機械地把所有被引用到的資源歸到“某個包”里然后生成依賴圖。一旦你的資源之間存在交叉引用比如Prefab A掛在Character B上Character B又掛回Prefab A的某個組件打包器就可能陷入“你到底該去哪個包找”的尷尬。我見過最典型的依賴環(huán)長這樣UI模塊的Prefab引用了角色模型上的一套骨骼動畫而角色模型那邊的Prefab又引用了UI模塊里的某個圖標或通用文本組件。從業(yè)務(wù)邏輯上看這倆“不該扯上關(guān)系”但美術(shù)或程序為了圖方便直接拖拽引用依賴環(huán)就那么被造出來了。依賴環(huán)的直接后果是打包器在計算依賴關(guān)系時要么遞歸爆掉要么干脆把環(huán)里的資源全部塞進同一個包導(dǎo)致AB體積飆升、加載時的依賴遍歷多繞一圈內(nèi)存上還會出現(xiàn)AB包無法卸載的“假泄漏”——Unity官方文檔里專門警告過這種循環(huán)引用是資源管理黑洞。1.2 重復(fù)資源是從哪里進來的重復(fù)資源和依賴環(huán)往往是伴生關(guān)系。當同一個材質(zhì)、紋理、Mesh被多個AB包共同引用而你的打包策略又是“每個邏輯模塊單獨打成AB包”時Unity的默認行為并不是幫你把這顆共享資源抽出去而是在每個依賴它的AB包里各自生成一份拷貝。舉個例子你有一個通用按鈕皮膚貼圖UI包引用它新手引導(dǎo)包也引用它角色創(chuàng)建包還引用它。如果你按UI、引導(dǎo)、創(chuàng)建分成三個AB只因為打包粒度太細或沒顯式把通用資源劃走最終打出來的包就是三份一模一樣的貼圖在各自AB里躺尸。這種冗余在報告里不會報錯但一算總包體白白胖了10%-30%都屬于正常操作。很多人以為用了Addressable就沒這問題了其實Addressable底層也是AssetBundle如果你不關(guān)注資源分組和依賴回收它照樣給你復(fù)制成三份。對我試過血淚教訓(xùn)。1.3 包體膨脹是上面的“果”不是“因”包體膨脹這個表象大多數(shù)人首先懷疑貼圖壓縮格式、模型面數(shù)、音頻碼率很少有人第一時間去查依賴環(huán)和重復(fù)資源。但實際項目里一個600M的包你可能優(yōu)化完貼圖壓縮省下80M回頭一看依賴環(huán)把兩個大模型場景綁在了一起又給旁邊塞了30M的冗余等于白干。所以這套治理思路的第一步不是沖上去壓貼圖而是先把依賴關(guān)系和資源歸屬理干凈讓每個資源“只住一個屋”。在這個基礎(chǔ)上再談壓縮格式、Shader變體這些“錦上添花”的手段。順序搞反了你只會越優(yōu)化越痛苦改一個配置牽出一串新問題。2. 依賴環(huán)診斷與治理從“事后爆”到“事前提”依賴環(huán)這個東西最麻煩的不是它多難解決而是它總在打包的中后期才冒出來。你項目跑得好好的一打AB報錯也好、不報錯但加載出問題也好人肉定位能卡掉你一下午。2.1 不靠肉眼寫個Editor腳本自動掃依賴環(huán)我強烈建議你在項目里留一個Editor腳本專門做依賴圖的環(huán)檢測。原理不復(fù)雜用AssetDatabase.GetDependencies或者直接遍歷BuildPipeline.GetDependenciesForAsset把每個資源的引用關(guān)系看成有向圖然后跑一趟DFS看有沒有回邊。下面這段是我項目里一直在用的簡化版本你們可以直接貼到Editor目錄里用using System.Collections.Generic; using System.Linq; using UnityEditor; using UnityEngine; public static class DependencyCycleDetector { [MenuItem(Tools/依賴檢查/檢測Asset依賴環(huán))] public static void DetectCycles() { string[] allAssetPaths AssetDatabase.GetAllAssetPaths() .Where(p p.StartsWith(Assets/)) .Where(p !p.EndsWith(.cs) !p.EndsWith(.js)) .ToArray(); var graph new Dictionarystring, Liststring(); foreach (var path in allAssetPaths) { string[] deps AssetDatabase.GetDependencies(path, false); graph[path] deps.Where(d d.StartsWith(Assets/)).ToList(); } var visited new HashSetstring(); var stack new HashSetstring(); var cycleFound false; foreach (var node in graph.Keys) { if (!visited.Contains(node)) { if (DFS(node, graph, visited, stack)) { cycleFound true; Debug.LogWarning($[依賴環(huán)] 檢測到包含 {node} 的依賴環(huán)請檢查后重新打包); } } } if (!cycleFound) Debug.Log([依賴檢查] 未發(fā)現(xiàn)依賴環(huán)可以放心打包); } static bool DFS(string current, Dictionarystring, Liststring graph, HashSetstring visited, HashSetstring stack) { if (stack.Contains(current)) return true; if (visited.Contains(current)) return false; visited.Add(current); stack.Add(current); if (graph.TryGetValue(current, out var deps)) { foreach (var dep in deps) { if (!visited.Contains(dep) || stack.Contains(dep)) { if (DFS(dep, graph, visited, stack)) return true; } } } stack.Remove(current); return false; } }這段腳本的核心思路是“染色法”visited標記所有訪問過的節(jié)點stack標記當前DFS路徑上的節(jié)點。如果訪問過程中走到了stack里的節(jié)點說明這條鏈路形成了閉環(huán)。跑完一遍菜單點一下能在打包前把環(huán)揪出來比等打包失敗再去猜快太多了。2.2 什么情況最容易觸發(fā)依賴環(huán)怎么預(yù)防依賴環(huán)通常集中在幾個場景UI與角色互相引用、動畫狀態(tài)機改在Prefab上卻反引UI、模塊之間的“臨時引用”忘了拆。我的建議是美術(shù)資源一律不允許直接引用UI的圖集或文本配置UI層也不允許直接把角色Prefab拖進組件引用而要通過事件或資源地址去拿。預(yù)防的抓手在規(guī)范上但規(guī)范的落地要靠工具。比如做一個Editor腳本Prefab保存時自動檢查它的依賴里有沒有“不該出現(xiàn)的目錄”違反規(guī)則直接彈警告。類似這種“保存即檢查”的機制效果比月末審代碼好十倍。需要多嘴一句AssetBundle的依賴環(huán)檢測工具市面上也有一些第三方插件和UI能可視化依賴圖。但說實話對于大多數(shù)中小團隊自己寫腳本加簡單的環(huán)檢測就夠用了不用一上來就上重工具。工具越復(fù)雜團隊越不想維護最后又變成擺設(shè)。2.3 打破依賴環(huán)的三種有效姿勢如果已經(jīng)查出來有環(huán)破解方式無非三種提取公共資源、拆分層級、反轉(zhuǎn)依賴方向。提取公共資源把環(huán)里的公共部分比如共享的材質(zhì)、通用UI元素、公共配置單獨抽成一個“公共包”兩邊都只引用這個包環(huán)自然斷開。拆分層級從“UI層”和“邏輯層”的角度重新劃分AB分組例如把UI資源歸為一個頂層A類把角色資源歸為B類禁止A反向引用B的具體Prefab只允許B引用A的通用資源。反轉(zhuǎn)依賴方向?qū)嵲跓o法避免跨層引用就把引用方向從“UI引用角色”改成“角色發(fā)送事件UI監(jiān)聽事件”代碼層解耦之后資源引用關(guān)系自然就干凈了。我個人最推薦第一種“提取公共資源”因為它不僅破環(huán)同時也在給后面的“去重復(fù)資源”打基礎(chǔ)。實際上很多重復(fù)資源問題也恰恰是因為你沒有一個明確的“公共資源包”而造成的。3. 重復(fù)資源排查與優(yōu)化讓每份資源只住一個屋依賴環(huán)解決了下一步就是清點“資源住址”。做Unity打包裝機的同學(xué)都有體會真正的包體殺手往往是重復(fù)資源同一個貼圖、同一個模型散落在不同AB包里最后全都塞進安裝包。3.1 用打包報告追查冗余資源Unity從打包時生成的BuildReport里其實有非常豐富的信息但默認界面上只給你看總大小和幾個維度不展開看不到細節(jié)。你可以直接寫一個腳本在打包后自動讀取BuildReport把所有AB包里引用的Asset路徑拍平找出“同一個路徑被多個AB包引用”的清單。下面是我項目里實際在用的統(tǒng)計邏輯打包后自動輸出一份重復(fù)資源報告public static void GenerateDuplicateReport() { var reportFile Temp/LastBuildReport.json; var loadedReport UnityEditor.Build.Reporting.BuildReportUtility.GetLastReport(); if (loadedReport null) { Debug.LogError(沒有找到上一次的BuildReport請先執(zhí)行一次打包); return; } var assetToBundles new Dictionarystring, Liststring(); foreach (var packedAsset in loadedReport.packedAssets) { var bundleName packedAsset.shortPath; foreach (var content in packedAsset.contents) { var assetPath content.sourceAssetPath; if (!assetToBundles.ContainsKey(assetPath)) assetToBundles[assetPath] new Liststring(); assetToBundles[assetPath].Add(bundleName); } } var duplicates assetToBundles .Where(kv kv.Value.Count 1) .OrderByDescending(kv kv.Value.Count) .ToList(); Debug.Log($[重復(fù)資源] 共發(fā)現(xiàn) {duplicates.Count} 個資源被多個AB包引用); foreach (var item in duplicates) { Debug.LogWarning(${item.Key} —— 被 {string.Join(, , item.Value)} 引用); } }跑完這份報告你就可以清楚地看到哪顆貼圖被UI包、引導(dǎo)包、商城包同時引用了。注意這里統(tǒng)計的是“打包結(jié)果”層面的重復(fù)不是Assets目錄下的重復(fù)文件。很多團隊目錄里沒有重復(fù)文件但打包結(jié)果卻有重復(fù)拷貝就是因為AB分組和依賴關(guān)系沒理清。3.2 去重不是“看見重復(fù)就刪”先算賬我踩過最深的坑就是拿到報告后一股腦去“去重”結(jié)果把幾張被高頻公用的小貼圖硬塞進公共包反而導(dǎo)致首包加載變慢、公共包鎖定的資源太多、沒法按需下載。所以去重前一定要復(fù)盤這組資源的使用場景。我的建議是三層判斷如果這個資源被5個以上模塊引用且文件體積大比如超過1MB那一定要抽到公共包或大資源包重復(fù)就是純浪費。如果只有2-3個模塊引用且文件體積很小比如幾十KB的小貼圖合并成一個“通用素材包”也行但別拆太碎。如果它只在一個模塊內(nèi)被復(fù)用那基本問題不大你只需要確認它所在的AB分組是否合理。另外別忘了UI圖集。Unity的SpriteAtlas如果設(shè)置不當不同圖集之間也可能穿插引用同一張源圖造成圖集A里面有它圖集B也打包進去了。檢查Atlas的Include in Build開關(guān)和關(guān)聯(lián)的Sprite引用是必要步驟。3.3 用“一個資源只屬于一個AB包”作為分組準繩治理重復(fù)資源最根本的辦法是讓分包規(guī)則清晰到“傻瓜都能執(zhí)行”。我一般把項目里的資源劃分成這幾類對應(yīng)不同類型的AB包公共基礎(chǔ)包UI骨架、通用Shader、通用圖集、字體、公共特效角色相關(guān)包模型、動作、專屬貼圖材質(zhì)場景相關(guān)包地圖、光照、大模型、場景特效玩法模塊包各玩法獨立的一組資源按需加載這種分法的關(guān)鍵是讓每個資源在目錄結(jié)構(gòu)里就能看出來該歸哪個包。比如所有公用圖標統(tǒng)一放在Assets/Art/Shared/UI/Icons下打成SharedUI包角色資源只在Assets/Art/Characters/CharacterA下打成CharacterA包。目錄即分包不用額外維護一份巨大的映射表否則你上線前根本不敢動資源。你還可以寫一個“目錄到Bundle名”的自動映射腳本來輔助打包讓Unity按照目錄約定自動決定每個資源屬于哪個AB包。這比手動一個個指定BundleName維護成本低得多也避免了“手動指定時漏了某個資源結(jié)果它被默認打進別的包”的尷尬。4. 包體膨脹分析與瘦身實操不只是改一個壓縮格式當依賴關(guān)系和重復(fù)資源都梳理干凈后你手里的包體才是“真實體量”這時候再去做壓縮和精簡才有意義。這部分的干貨我可以寫好幾篇文章這里只挑最影響結(jié)果的幾個環(huán)節(jié)說。4.1 先做“包體畫像”搞清楚每一兆花在哪拿到BuildReport后先別急著優(yōu)化按資源類型做一次聚合統(tǒng)計貼圖占多少、模型占多少、音頻占多少、Shader占多少、AB包頭和Manifest占多少。這一步非常關(guān)鍵很多人一急就沖進貼圖目錄去改壓縮格式結(jié)果發(fā)現(xiàn)真正的大頭是某個忘了壓縮的巨大模型白忙一場。我自己習(xí)慣打包后立刻跑一段統(tǒng)計腳本代碼也不復(fù)雜var groups loadedReport.packedAssets .SelectMany(p p.contents) .GroupBy(c c.type.ToString()) .Select(g new { Type g.Key, TotalSize g.Sum(x x.packedSize) }) .OrderByDescending(x x.TotalSize); foreach (var group in groups) Debug.Log(${group.Type}: {group.TotalSize / (1024f * 1024f):F2} MB);跑完之后你會對包體分布一目了然。比如發(fā)現(xiàn)Mesh占了大頭就別死磕貼圖了發(fā)現(xiàn)Shader編譯產(chǎn)物異常大就該去查變體收集策略。4.2 貼圖、模型、音頻、Shader的實戰(zhàn)壓縮清單貼圖這是最常規(guī)的包體大頭。優(yōu)先把平臺格式設(shè)為ASTC移動端根據(jù)用途選擇壓縮質(zhì)量。UI貼圖通常不需要Mipmap關(guān)閉后能省大概33%內(nèi)存和磁盤占用模型貼圖可以開Mipmap但要設(shè)好大小限制。圖集合并這個事適合做但別貪圖集越大加載進內(nèi)存的顆粒度越粗反而容易在只顯示一塊UI時被迫加載整張圖集。模型Mesh的壓縮率常常被忽略。模型導(dǎo)入設(shè)置里的Mesh Compression默認Off你可以設(shè)為Low或Medium配合優(yōu)化頂點數(shù)據(jù)能壓掉不少體積。另外動畫文件里的骨骼數(shù)量、曲線精度也可以壓縮對包體貢獻很大。音頻長音樂和語音用Vorbis高壓縮比短音效用ADPCM或盡量減少時長。很多人都知道碼率參數(shù)但忘了檢查“音效時長”本身——很多策劃喜歡在音效文件里留好幾秒空白尾音這種冗余對包體和內(nèi)存都是純浪費。Shader這是最隱蔽的膨脹源。Shader變體如果沒做收集Unity會把所有開啟的關(guān)鍵字組合都打進變體集合你一個Shader可能有幾百上千個變體包體瞬間脹出幾十M。所以一定要做ShaderVariantCollection并且在打包時做變體裁剪。如果項目用了大量第三方Shader更得先查變體否則你怎么壓貼圖都補不回這個洞。4.3 LZ4還是LZMA壓縮策略沒那么好選AB包的壓縮方式一般用LZ4或LZMA。LZMA壓縮率高但解壓的時候CPU開銷大還得整體解壓到內(nèi)存才能用LZ4壓縮率低一點但加載快還能隨機訪問。我的習(xí)慣是首包必須用的核心AB用LZ4后續(xù)熱更或按需下載的包用LZMA能省一點下載量。但游戲?qū)虞d速度很敏感的話也可以全部LZ4犧牲一點包體換流暢度。這個取舍一定要和項目性能組對齊別自己拍腦袋。另外提醒一句別迷信“必須把所有AB壓縮率拉到最高”。壓縮率上來之后解壓時的峰值內(nèi)存也會上去低端機本來就緊張可能因此卡頓或閃退。包體數(shù)字漂亮不等于體驗好。5. 上線前自動“揪問題”把體檢變成流水線講到這里大家應(yīng)該發(fā)現(xiàn)了依賴環(huán)、重復(fù)資源、包體膨脹這些問題單靠上線前人工查一次遠遠不夠。因為項目在持續(xù)迭代今天清干凈了明天新合入一個分支又造出來一個環(huán)。最穩(wěn)的做法是把它塞進CI流程打包后自動體檢不符合指標就失敗別讓壞包流到提測環(huán)節(jié)。5.1 一個打包后自動化檢查腳本的骨架我建議在每個打包流水線后面接一個“AB體檢”步驟檢查項至少覆蓋依賴環(huán)檢測、重復(fù)資源超閾值檢測、包體總量超閾值檢測、單包大小異常檢測。滿足條件的報告自動發(fā)到構(gòu)建平臺不合格就直接標紅。這段是檢查單包大小的核心邏輯可以掛在打包命令之后public static void CheckBundleSizeLimits() { var bundlesDirectory Assets/StreamingAssets/AB; var allBundles Directory.GetFiles(bundlesDirectory, *, SearchOption.AllDirectories) .Where(f !f.EndsWith(.manifest)) .ToList(); foreach (var bundlePath in allBundles) { var size new FileInfo(bundlePath).Length; var bundleName Path.GetFileName(bundlePath); if (size 30 * 1024 * 1024) // 單包超過30M就報警 Debug.LogWarning($[AB體檢] 包 {bundleName} 體積異常: {size / (1024f * 1024f):F2}MB); } }流程整體上就是三步一、觸發(fā)打包二、跑構(gòu)建后檢查三、把報告回傳到CI平臺由CI根據(jù)結(jié)果決定這包能不能進提測環(huán)境。如果你用的是Jenkins或GitLab CI直接在命令里加上這些Editor腳本的調(diào)用入口幾行代碼的事。5.2 檢查清單我在每次出包前必過的8項整理了一份我現(xiàn)在每天都在用的清單分享給你們參考檢查項標準檢查方式依賴環(huán)0個自動腳本DFS跨AB引用數(shù)不超過30個且都在白名單內(nèi)BuildReport統(tǒng)計重復(fù)資源體積占比低于總包體5%自定義報告單AB包最大體積不超過30MB文件掃描AB包總數(shù)量每個平臺不超過300個文件掃描貼圖壓縮格式全部為ASTC移動端自定義檢查Shader變體數(shù)每Shader不超過200個ShaderVariantCollection總包體增量和上一版對比增幅不超過5%CI對比腳本你可以根據(jù)自己的項目調(diào)整閾值但重點是把“標準”寫下來讓它變成團隊共同遵守的規(guī)矩而不是你一個人在編輯器里手動看。5.3 用差異對比抓“增量膨脹”我還特別推薦在CI里保留上次構(gòu)建的Report快照每次新打一包自動對比新舊兩個包在“每個AB的大小差”。這一招能讓你快速定位“這次到底是哪個資源吃掉了包體增量”。我見過不少團隊只知道包從600M漲到700M但說不清漲在哪最后只能靠運營、策劃一個個去猜。有了自動對比新人也能幾秒內(nèi)定位到具體資源。做法不復(fù)雜打包腳本里把這個包的報告序列化保存到一個固定目錄CI腳本對比時反序列化后按“AB包名”做diff輸出成表格。如果某個AB增量超過10%那說明這次迭代里的某個資源導(dǎo)入方式出問題了大概率是忘了壓縮、模型沒合批或者多人協(xié)作時把大文件直接塞進AB的目錄里了。6. 常見問題與排查技巧實錄最后這部分我把自己這些年遇到的高頻問題按“現(xiàn)象—原因—解法”整理成一個速查表算是給前面所有內(nèi)容的落地補個底。實際項目里遇到老問題翻這張表比翻文檔快?，F(xiàn)象常見原因排查思路打包報循環(huán)依賴錯誤Asset引用形成閉環(huán)先跑2.1的環(huán)檢測腳本定位資源鏈路運行時加載AB提示找不到依賴依賴資源沒進StreamingAssets或下載路徑不對檢查Manifest文件、檢查依賴AB是否被打成獨立包同一貼圖在不同包各出現(xiàn)一次公共資源未單獨分組查BuildReport重復(fù)資源清單抽出公共包包體比上一版突然大20M新合入資源導(dǎo)入設(shè)置不對用CI diff腳本對比增量定位具體ABUI界面加載卡頓AB包粒度過大整包加載拆分每個界面為獨立AB用LZ4壓縮Shader變體導(dǎo)致打包巨慢且包體畸形變體數(shù)量爆炸手動構(gòu)建ShaderVariantCollection并裁剪關(guān)鍵字AB無法Unload依賴環(huán)或跨AB引用未清理排查依賴圖、檢查對象的卸載策略我再補充一個容易忽略的技巧StreamingAssets里的AB包如果你用C#自帶的File操作去讀取別忘加上路徑拼接時對平臺差異的處理。Android要拿到j(luò)ar包內(nèi)路徑很多時候要用UnityWebRequest來讀直接File.ReadAllBytes在Android上會出現(xiàn)讀取不到文件的問題。這種事不報錯但運行失敗排查起來特別費勁。另外一個小心得不要等到“上線前”才做整套治理。先把檢查腳本放進日常開發(fā)每個版本提測前都跑一遍哪怕只跑依賴環(huán)和重復(fù)資源檢查也能在早期攔下一批問題。等到了真正提審、出包的前一晚你才能睡個安穩(wěn)覺。說到底AssetBundle打包治理不是一次性項目而是一套需要持續(xù)維護的過程。我見過太多團隊在“崩一下修一下”的循環(huán)里反復(fù)掙扎核心原因就是沒有把“規(guī)則”和“工具”沉淀下來。希望這套流程和腳本能幫你在下次出包時少踩幾個坑。如果你手上項目已經(jīng)在Android、iOS、微信小游戲這些平臺上遇到了打包差異問題或者下一步準備接入Addressable那在動手換工具之前先把這套體檢腳本跑起來。你會發(fā)現(xiàn)很多遷移過程中的坑本質(zhì)上還是依賴環(huán)和重復(fù)資源的老問題換了個新皮膚而已。