1. 项目概述与核心价值在Unity项目开发中尤其是UI密集或2D游戏项目图集Atlas是性能优化和资源管理绕不开的话题。Unity官方提供了功能强大的Sprite Atlas系统它自动化程度高对于大多数标准项目来说已经足够好用。但当你需要更精细的控制、动态的图集管理或者需要处理一些非标准的纹理打包逻辑时官方的黑盒方案就显得有些力不从心了。比如你可能需要运行时动态合成图集、实现特定算法的纹理布局如MaxRects、Guillotine、或者需要将图集数据序列化为自定义格式供其他工具链使用。这就是我们为什么要深入探讨“自定义图集”实现的原因。这个系列文章我们聚焦于从零开始构建一套自定义图集系统。前三篇我们可能已经搭建了基础框架定义了数据结构实现了静态打包。本篇作为系列的第四部分我们将深入到最核心、也最具挑战性的环节动态图集管理与高级纹理布局算法优化。动态图集意味着我们可以在运行时根据游戏逻辑如角色换装、UI图标动态加载实时地向图集中添加或移除精灵而无需重启游戏或重新打包AssetBundle。这不仅能减少包体大小还能实现更灵活的资源流式加载。2. 动态图集管理器的设计与实现动态图集的核心矛盾在于“空间碎片化”。随着不断地添加和移除纹理图集纹理上会出现许多零散的空闲区域虽然总空闲面积可能很大但无法容纳一个稍大的新纹理导致图集利用率下降最终触发昂贵的“图集重建”操作。2.1 核心数据结构空闲区域管理我们不能简单地用一个ListRect来记录所有空闲矩形因为合并相邻的空闲区域是减少碎片化的关键。这里我们通常采用一种称为“空闲矩形列表”并配合合并策略的数据结构。首先我们定义一个FreeRect类它不仅记录位置和大小还需要一些标志位来辅助算法。public class FreeRect { public int x; public int y; public int width; public int height; public bool isActive; // 该空闲区域是否有效未被分割或合并 // 用于合并算法的临时标记避免重复合并 public bool merged; }我们的动态图集管理器DynamicAtlasManager将维护一个当前图集纹理Texture2D和一个所有已占用区域的列表ListRect以及一个关键的空闲矩形列表ListFreeRect。初始化时整个图集就是一个大的空闲矩形。2.2 动态添加纹理的流程当请求添加一个纹理时流程如下请求与规格检查获取纹理的宽高并考虑我们自定义的Padding值防止纹理边缘 bleeding。计算所需宽度reqWidth tex.width padding*2高度同理。寻找放置位置遍历空闲矩形列表使用选定的布局算法如Best Short Side Fit, BSSF找到一个最适合放置该纹理的空闲矩形。所谓“最适合”通常定义为放入后剩余空间最不浪费的。放置与分割找到目标空闲矩形freeRect后将纹理绘制到图集对应的(freeRect.x padding, freeRect.y padding)位置。然后从空闲矩形列表中移除freeRect。最关键的一步来了将这个大的空闲矩形分割成剩余的小矩形。通常采用“最大分割法”Maximal Split如果放入的纹理宽度小于空闲矩形宽度则右侧会产生一个新的竖直条状空闲矩形。如果放入的纹理高度小于空闲矩形高度则下方会产生一个新的水平条状空闲矩形。将这两个新产生的空闲矩形如果有效加入空闲矩形列表。记录与返回将纹理的ID或引用与其在图集中的UV坐标需要从像素坐标转换关联起来存入一个字典。返回这个UV信息给调用者。实操心得在步骤3的分割过程中一定要处理“纹理尺寸恰好等于空闲矩形尺寸”的边缘情况此时不应产生新的空闲矩形。同时新产生的空闲矩形可能会与列表中已有的其他空闲矩形相邻为下一步合并埋下伏笔。2.3 空闲矩形合并策略每次放置操作后或定期进行我们需要执行“合并”操作来整合相邻的空闲矩形形成更大的连续空间。合并算法通常扫描空闲矩形列表寻找满足以下条件的一对矩形A和BA的右边缘与B的左边缘对齐且高度相同水平相邻。或者A的底边缘与B的顶边缘对齐且宽度相同垂直相邻。找到后将A和B合并成一个更大的矩形C将A和B标记为无效isActive false并将C加入列表。一轮扫描后清除所有无效的矩形。private void MergeFreeRects() { for (int i 0; i freeRects.Count; i) { if (!freeRects[i].isActive) continue; for (int j i 1; j freeRects.Count; j) { if (!freeRects[j].isActive) continue; // 检查水平相邻合并 if (freeRects[i].y freeRects[j].y freeRects[i].height freeRects[j].height) { if (freeRects[i].x freeRects[i].width freeRects[j].x) { // 合并i和j生成新的矩形标记i,j为无效 FreeRect merged new FreeRect(); merged.x freeRects[i].x; merged.y freeRects[i].y; merged.width freeRects[i].width freeRects[j].width; merged.height freeRects[i].height; merged.isActive true; freeRects.Add(merged); freeRects[i].isActive false; freeRects[j].isActive false; // 注意这里break后需要重新开始扫描因为列表结构变了 // 简化处理可以设置一个dirty标志在外层循环处理 } } // 检查垂直相邻合并逻辑类似 } } // 清理所有isActive为false的矩形 freeRects.RemoveAll(rect !rect.isActive); }注意事项合并操作虽然能有效减少碎片但其本身是一个O(n²)的操作不宜每帧执行。通常可以在每次添加操作后执行一次或者设置一个阈值如每添加10次纹理后合并一次。对于性能敏感的场景需要仔细评估。2.4 动态移除与空间回收动态移除纹理是另一个难点。我们不能简单地从纹理上“擦除”像素成本高且无意义但我们需要回收它占用的区域将其重新标记为空闲矩形。标记区域为空闲当移除一个纹理时根据其UV坐标反向计算出在图集上的像素矩形区域记得加上Padding创建一个新的FreeRect加入空闲矩形列表。立即合并这个新加入的空闲矩形极有可能与周围现有的空闲矩形相邻因此在移除操作后立即执行一次合并操作是非常有必要的可以快速整合空间。这里有一个关键陷阱直接合并可能不够。假设之前我们分割了一个大矩形现在移除了其中一部分我们希望能与原来的另一部分合并还原。但简单的相邻合并可能无法处理“L”形或更复杂形状的还原。更高级的算法会记录每个已放置矩形的“来源”在移除时尝试与其“兄弟”矩形合并。实现复杂度较高需要根据项目需求权衡。3. 高级纹理布局算法深度优化在第二部分我们提到了使用“Best Short Side Fit (BSSF)”来寻找放置位置。这只是众多算法中的一种。对于追求极致空间利用率的场景我们需要了解并选择合适的算法。3.1 常见矩形装箱算法对比我们实现一个IPackingAlgorithm接口便于切换算法。public interface IPackingAlgorithm { bool TryPack(Rectangle toPack, ListFreeRect freeRects, out PackedPosition position); }算法名称核心思想优点缺点适用场景Best Area Fit (BAF)选择放入后剩余面积最小的空闲矩形。直觉上能最大化空间利用率。可能产生很多细长的“缝隙”不利于后续放置。通用纹理大小差异不大时。Best Short Side Fit (BSSF)选择放入后短边剩余长度最小的空闲矩形。倾向于产生更“方正”的剩余空间有利于后续放置。空间利用率可能略低于BAF。动态图集的推荐首选能较好地平衡利用率和碎片化。Best Long Side Fit (BLSF)选择放入后长边剩余长度最小的空闲矩形。与BSSF类似但策略不同。效果通常不如BSSF稳定。特定纹理分布下可能有效。Bottom-Left (BL)始终选择最靠下、靠左的空闲矩形并选择使矩形顶部最高的放置方式。规则简单速度快。空间利用率通常最低。对性能要求极高对利用率不敏感的场景。MaxRects维护一个由“最大矩形”组成的空闲列表而非简单的矩形列表。每次放置后更新最大矩形集合。目前公认的2D离线打包最优算法之一利用率极高。算法实现复杂动态更新分割与合并开销大。静态图集打包的黄金标准。3.2 实现MaxRects算法MaxRects算法的核心是维护一个“最大空白矩形”的列表。所谓“最大矩形”是指该矩形无法再向上下左右任意方向扩展而不碰到已占用区域或边界。放置步骤遍历所有最大空白矩形用选定的启发式规则如BAF, BSSF评估待放置纹理。放置后更新最大矩形列表这个步骤最复杂。需要从列表中移除被覆盖的最大矩形并将因放置而产生的新的潜在最大矩形计算出来并加入列表。这通常涉及大量的矩形相交、分割计算。由于实现非常复杂这里给出一个高度简化的伪代码逻辑说明更新过程// 假设我们放置了一个新矩形 placedRect ListFreeRect newMaxRects new ListFreeRect(); foreach (var maxRect in currentMaxRects) { if (!RectOverlap(maxRect, placedRect)) { // 如果没有重叠保留 newMaxRects.Add(maxRect); continue; } // 如果重叠将maxRect分割成最多4个可能的新矩形上、下、左、右部分 // 分割出的每个新矩形需要检查它是否是“最大”的即不能完全被其他空闲矩形包含 // 这是一个计算密集型操作 var splitRects SplitMaxRect(maxRect, placedRect); foreach (var split in splitRects) { if (IsMaximal(split, newMaxRects, allOccupiedRects)) { newMaxRects.Add(split); } } } currentMaxRects newMaxRects;踩坑实录在Unity中实现一个完整高效的MaxRects动态版本是一项艰巨任务。我曾在项目中尝试发现其CPU开销在频繁的动态操作下如每秒多次添加/移除可能成为瓶颈。对于绝大多数需要动态图集的游戏BSSF算法配合良好的空闲矩形合并策略已经能提供90%以上场景下可接受的性能与利用率平衡。除非你的项目对图集空间利用率有极端要求例如图集尺寸固定且必须容纳极大量纹理否则不建议在动态环境下使用MaxRects。3.3 多图集管理与扩容策略单个动态图集总有装满的时候。我们的系统需要支持自动创建新图集。创建策略当当前图集无法容纳新纹理时自动创建一个新的DynamicAtlas对象。新图集的尺寸可以采用固定大小如1024x1024也可以是动态计算的例如是当前所有纹理总面积的两倍再向上取整到2的幂次。查询策略管理器需要维护一个ListDynamicAtlas。当请求添加纹理时按顺序遍历所有图集直到找到可以容纳的图集。为了效率可以记录每个图集的剩余空间面积优先尝试剩余空间大的。纹理引用与渲染一个UI元素或SpriteRenderer可能需要使用来自不同图集的纹理。这没有问题但意味着它可能会在渲染时产生多次Draw Call如果这些图集材质不同。为了合批尽量让同一帧内需要同时渲染的物体使用同一个图集。这需要上层逻辑进行一定的资源分组规划。4. 性能优化与内存管理实战自定义动态图集在带来灵活性的同时也引入了性能风险。以下是几个关键的优化点。4.1 纹理读写与Apply在Unity中频繁调用Texture2D.SetPixels和Texture2D.Apply()来更新图集纹理是非常耗时的操作尤其是在移动端。Apply()函数会将CPU内存中的数据上传到GPU显存可能造成卡顿。优化策略批量更新不要每次添加一个纹理就Apply一次。可以积累一批纹理添加请求在一帧的末尾如LateUpdate或固定的时间间隔如每0.1秒进行一次性的SetPixels和Apply。使用Graphics.CopyTexture(如果支持)对于从另一个纹理复制区域到图集的操作如果平台支持OpenGL ES 3.0, Metal, DX11使用Graphics.CopyTexture比CPU端的GetPixels/SetPixels快几个数量级。它直接在GPU内存间复制数据。启用Read/Write Enabled的权衡我们的动态图集纹理在导入时必须勾选Read/Write Enabled否则无法通过脚本修改。但这会使纹理内存翻倍CPU和GPU各一份。这是实现动态功能的必要代价需在项目内存预算中考虑。4.2 图集重建的代价与避免当图集碎片化严重无法放入新纹理且创建新图集也不合适时可能需要进行“图集重建”Repack创建一个新的空白大图集将所有当前有用的纹理重新收集、排序、打包进去然后销毁旧图集。重建是昂贵的因为它涉及从GPU读回所有纹理数据如果之前没保留CPU端副本。重新执行打包算法。将新数据上传到GPU。更新所有引用旧图集UV的材质属性。如何避免频繁重建预分配与预热在加载界面或场景初始化时根据已知的资源列表预先向动态图集中添加一批常用纹理填满一定空间减少运行时碎片化的初始速度。设置合理的图集尺寸不要一开始就用2048x2048。根据目标平台和项目规模从512x512或1024x1024开始。不够再扩容或新建。过大的图集即使有空闲碎片化后也难利用。实现智能的纹理生命周期管理对于确定不再使用的纹理如过场动画的专属贴图主动从动态图集中移除并及时合并空间。可以结合引用计数或WeakReference来管理。4.3 渲染合批与材质属性块即使我们管理好了纹理如果渲染时破坏了合批性能提升也会大打折扣。确保使用同一个材质所有使用同一动态图集的SpriteRenderer或UI Image应该共享同一个材质实例。这个材质的MainTex属性指向我们的动态图集纹理。使用MaterialPropertyBlock如果不同的物体需要微调颜色等属性不要创建新的材质实例会导致合批中断。应该使用MaterialPropertyBlock来覆盖每渲染器的特定属性这不会破坏动态合批。UV更新当动态图集纹理改变重建或扩容后所有使用它的物体的UV都需要更新。我们需要维护一个注册列表在图集更新后遍历列表通过MaterialPropertyBlock或直接修改共享材质的纹理偏移/缩放属性来批量更新UV。更高效的做法是使用一个大的Texture2DArray或UnityEngine.Rendering.Universal.2D中的Sprite-Lit-DefaultShader配合PerRendererData但这属于更高级的优化范畴。5. 常见问题排查与调试技巧在实际集成自定义动态图集系统时你肯定会遇到各种问题。下面是一些典型问题的排查思路。5.1 纹理显示错乱或拉伸症状精灵显示为其他精灵的图像或者被不正常拉伸。排查步骤检查UV计算确认从图集像素坐标到UV坐标0-1范围的转换公式正确。公式通常是u (x 0.5f) / atlasWidth,v (y 0.5f) / atlasHeight。注意0.5f是为了采样纹理中心避免边缘过滤问题。同时要计算正确的宽高uvWidth (texWidth) / atlasWidth。检查Padding在计算UV时是否错误地将Padding区域包含了进去绘制时我们在(xpadding, ypadding)但UV应该是基于包含Padding的整个区块还是仅内部区域通常UV应对应纹理的有效区域不含Padding。所以UV起点应为(xpadding)/atlasWidth。使用调试视图创建一个调试脚本将动态图集纹理在屏幕上渲染出来用GUI.DrawTexture或创建一个RawImage并绘制出每个已分配区域的边框。肉眼观察纹理是否正确放置区域有无重叠。5.2 性能突然下降症状游戏运行一段时间后出现卡顿。排查步骤Profile查看Texture2D.Apply在Unity Profiler的CPU模块中查看Texture2D.Apply的调用耗时和频率。如果频繁出现且耗时高说明你的批量更新策略没做好。检查图集重建在代码中添加日志记录图集重建事件。如果重建过于频繁需要优化你的空间分配算法或调整纹理生命周期管理。检查合并算法如果合并操作MergeFreeRects的CPU开销很大考虑降低其执行频率或者优化其实现如使用空间划分数据结构如四叉树来加速相邻矩形查找但这本身也增加复杂度。5.3 内存泄漏症状游戏内存持续增长特别是纹理内存。排查步骤检查旧图集纹理是否被销毁当你创建新图集或重建图集后旧的Texture2D对象是否调用了Destroy别忘了启用了Read/Write Enabled的纹理在CPU和GPU都有占用。检查纹理引用确保从动态图集中移除纹理时也清除了所有对该纹理区域数据的缓存引用例如你可能会缓存一份Color[]数据用于快速复制。使用Unity的Memory Profiler抓取内存快照查看Texture2D对象的数量和历史创建堆栈定位泄漏源。5.4 打包到AssetBundle后失效症状在编辑器运行正常打包后动态添加的纹理不显示。排查步骤纹理格式与平台设置动态创建的Texture2D其格式如TextureFormat.RGBA32必须与目标平台的纹理压缩格式兼容。在创建纹理时使用SystemInfo.SupportsTextureFormat进行检查。Shader与材质确保你使用的材质和Shader在目标平台是有效的并且MainTex属性能够正确绑定到运行时创建的纹理上。有时需要将Shader打入Always Included Shaders列表。代码剥离检查是否因为Unity的代码剥离Code Stripping导致你的动态图集管理类中的某些方法被意外移除。可以在Project Settings - Player - Managed Stripping Level中尝试降低级别或使用[Preserve]属性标记关键类和方法。实现一个健壮、高效的自定义动态图集系统是对开发者耐心和细心的极大考验。它没有银弹每一个优化点都需要根据具体项目需求进行权衡和调整。但从头构建它的过程会让你对Unity的资源管理、渲染管线、内存和性能优化有更深层次的理解这种收获远超仅仅会使用官方工具。当你看到自己管理的UI系统流畅运行Draw Call数量显著下降时那种成就感是无可替代的。