1. 项目概述长列表性能优化的核心痛点在CocosCreator项目中但凡涉及到长列表比如聊天记录、排行榜、背包、商品列表性能问题就像个定时炸弹随时可能引爆。最典型的两个症状就是图片闪烁和drawcall激增。图片闪烁指的是列表滚动时新出现的图片会短暂地显示为空白或错图然后才加载出来体验非常割裂。而drawcall激增则是性能的隐形杀手它会让你的游戏帧率骤降在低端机上直接卡成幻灯片。这两个问题看似独立实则同根同源。传统做法是给列表的每个Item都挂上一个Sprite组件并直接设置spriteFrame。当列表快速滚动时大量新的spriteFrame需要被加载、创建纹理、上传至GPU。这个加载过程是异步的如果纹理还没准备好就被绘制就会导致闪烁。同时每一个不同的spriteFrame如果没有经过合理的合批处理就会产生一个独立的drawcall。一个拥有100个不同头像的长列表理论上在最坏情况下可以产生100个drawcall这对渲染管线是毁灭性的打击。动态缓存池技术就是针对这个“根”的解决方案。它不是一个具体的API而是一种资源管理和渲染优化的设计模式。核心思想是将渲染所需的核心资源如纹理、渲染数据进行预加载和缓存并在渲染时实现实例的复用与数据的动态更新从而避免运行时频繁的资源加载与创建并创造合批条件。简单说就是“用空间换时间用设计换性能”。接下来我将拆解如何从零构建一个针对长列表优化的动态缓存池系统。2. 核心思路与架构设计2.1 问题根源深度剖析要设计解决方案必须彻底理解问题。图片闪烁和drawcall高的本质原因如下图片闪烁的根源异步加载延迟loader.loadRes或sprite.spriteFrame直接赋值新资源时如果资源不在缓存中引擎会触发异步加载。在加载完成的回调执行前精灵会处于无纹理或旧纹理状态。纹理上传耗时即使资源已存在于内存将其上传到GPU纹理显存也需要时间。如果在上传完成前提交渲染命令GPU读取到的就是无效数据。列表复用组件未重置在滚动复用Item时如果新的图片资源未就绪而旧的图片资源已被清除或重置就会显示空白。Drawcall激增的根源纹理切换这是最主要的原因。CocosCreator的渲染合批Auto-batching主要依赖于RenderTexture纹理图集。在同一批次内所有顶点数据必须使用相同的纹理更准确地说是相同的RenderTexture及其关联的材质参数。长列表中图片各异意味着频繁切换纹理合批中断drawcall必然增加。渲染状态切换除了纹理不同的混合模式、材质实例也会打断合批。2.2 动态缓存池的核心设计思想基于以上分析我们的动态缓存池系统需要达成以下几个核心目标资源预加载与缓存在列表初始化或空闲时提前将可能用到的图片资源加载到内存中并确保其对应的纹理已上传至GPU即完成texture.uploadData。这是解决闪烁问题的根本。渲染实例复用不仅仅是节点Node的复用这是ScrollView自带或需要自己实现的基础更重要的是Sprite组件所使用的底层RenderData和Model的复用或者通过动态合批手段减少渲染组件的创建。纹理合批优化这是降低drawcall的关键。我们需要将多个分散的小图片在运行时或预处理时合并到一张或几张大的纹理Texture2D上。这样即使渲染100个不同的头像只要它们来自同一张大纹理就能被合并到一个drawcall内。因此一个完整的动态缓存池架构通常包含以下模块资源管理模块负责预加载、缓存、释放图片资源。可以监听loader的生命周期。纹理合批模块核心负责将零散的小图片SpriteFrame动态打包到一张或多张“动态图集”DynamicAtlas中。CocosCreator引擎内部其实有一个DynamicAtlas系统但默认可能不满足所有需求我们需要更精细的控制。渲染代理模块列表中的Item不再直接持有Sprite组件并赋值spriteFrame而是通过一个代理。这个代理接收一个资源ID或索引内部从纹理合批模块中获取该资源对应的在大纹理上的UV坐标并动态更新某个共享Sprite组件或自定义渲染组件的顶点数据。2.3 方案选型静态合批 vs 动态合批这里有两个主要的技术路径静态合批预生成图集在编辑期或项目构建时使用TexturePacker等工具将常用小图打包成一张大图集。在运行时所有Sprite都使用这个大图集中的spriteFrame。这是性能最好的方式drawcall最低。缺点是图集尺寸有限如2048x2048无法容纳过多或过大的图片且后期增删图片需要重新打包图集不够灵活。动态合批运行时图集在运行时根据列表实际需要显示的图片动态地将它们的纹理数据复制到一张或几张GPU纹理上。CocosCreator内置的DynamicAtlas就是此类方案。优点是极其灵活可以应对未知或海量的图片资源。缺点是存在CPU上传开销将像素数据复制到纹理以及图集碎片化管理复杂度。对于长列表优化尤其是图片数量多、不确定的场景如用户头像动态合批是更可行的选择。我们的缓存池将围绕增强版的动态合批来构建。3. 关键技术实现细节3.1 构建增强型动态纹理管理器CocosCreator的director.root.pipeline.dynamicAtlasManager提供了基础的动态图集功能。但为了更精细的控制如分页、LRU释放我们需要封装自己的管理器。// DynamicTextureManager.ts import { _decorator, Texture2D, ImageAsset, dynamicAtlasManager, SpriteFrame } from cc; export class DynamicTextureManager { private static _instance: DynamicTextureManager null; public static get instance(): DynamicTextureManager { if (!this._instance) { this._instance new DynamicTextureManager(); } return this._instance; } // 存储资源路径与动态合批后spriteFrame的映射 private _frameCache: Mapstring, SpriteFrame new Map(); // 也可以存储自己创建的动态纹理页 private _texturePages: Texture2D[] []; private constructor() { // 可以在这里初始化动态图集管理器参数 // 例如dynamicAtlasManager.enabled true; // dynamicAtlasManager.maxAtlasCount 5; // 最大纹理页数 // dynamicAtlasManager.textureSize 2048; // 每页纹理大小 } /** * 预加载资源并插入动态图集 * param urls 资源路径数组 */ public async preloadAndPackFrames(urls: string[]): Promisevoid { const loadPromises urls.map(url this._loadAndPackSingle(url)); await Promise.all(loadPromises); } private async _loadAndPackSingle(url: string): PromiseSpriteFrame { if (this._frameCache.has(url)) { return this._frameCache.get(url); } return new Promise((resolve, reject) { // 1. 加载原始图片资源 loader.loadRes(url, ImageAsset, (err, imageAsset) { if (err) { reject(err); return; } // 2. 创建临时的SpriteFrame此时纹理未合批 const tempFrame new SpriteFrame(); tempFrame.texture imageAsset._texture; // 3. 关键步骤插入动态图集。 // 调用此方法后dynamicAtlasManager会将tempFrame的纹理数据复制到动态图集纹理中 // 并返回一个新的SpriteFrame其texture指向动态图集纹理并设置了正确的rect和uv。 const packedFrame dynamicAtlasManager.insertSpriteFrame(tempFrame); // 4. 缓存结果 this._frameCache.set(url, packedFrame); // 5. 销毁临时资源释放原始纹理内存可选根据需求 tempFrame.destroy(); // 注意不要销毁imageAsset因为packedFrame可能以某种方式引用它实际上需要看引擎实现。 // 更安全的做法是如果原始纹理不再需要可以释放。 // imageAsset._texture.destroy(); // 谨慎操作 resolve(packedFrame); }); }); } /** * 获取已合批的SpriteFrame */ public getPackedFrame(url: string): SpriteFrame | null { return this._frameCache.get(url) || null; } /** * 清理缓存如切换场景时 */ public clearCache(): void { this._frameCache.clear(); // 动态图集管理器有自己的清理逻辑通常我们不需要手动清理_texturePages // dynamicAtlasManager.reset(); } }关键点与注意事项insertSpriteFrame是核心魔法。它完成了将小纹理数据拷贝到大纹理上并计算正确UV坐标的工作。内存管理动态图集占用的显存是持续的。如果列表图片无限增长需要实现LRU最近最少使用策略将不常用的图片从动态图集中移除。这需要自己维护引用计数或时间戳并可能涉及到dynamicAtlasManager.deleteAtlasSpriteFrame如果引擎暴露了类似接口或自己管理多张纹理页进行替换。纹理尺寸与数量务必在项目初始化时根据目标设备性能设置合理的maxAtlasCount和textureSize。设置过大会浪费内存过小会导致图集频繁切换或插入失败。3.2 实现列表项渲染代理列表的Item预制体结构需要调整。传统的直接挂Sprite组件并改spriteFrame的方式不再适用。// ListItemRenderer.ts import { _decorator, Component, Sprite, Node, UITransform, Color } from cc; import { DynamicTextureManager } from ./DynamicTextureManager; const { ccclass, property } _decorator; ccclass(ListItemRenderer) export class ListItemRenderer extends Component { property(Sprite) public contentSprite: Sprite null; // 这个Sprite将始终使用动态图集纹理 // 当前显示的资源ID private _currentResId: string ; start() { // 确保Sprite的spriteFrame初始为空或一个默认的占位图也需加入动态图集 // this.contentSprite.spriteFrame null; } /** * 更新Item显示的数据 * param data 包含需要显示图片资源路径等信息的数据对象 */ public updateData(data: any): void { if (!data || !data.icon) { this._clearDisplay(); return; } const resId data.icon; if (this._currentResId resId) { return; // 避免重复设置 } this._currentResId resId; // 1. 先从缓存管理器获取已合批的SpriteFrame const packedFrame DynamicTextureManager.instance.getPackedFrame(resId); if (packedFrame) { // 缓存命中直接应用此时纹理已就绪无闪烁 this._applySpriteFrame(packedFrame); } else { // 2. 缓存未命中显示占位图并异步加载 this._showPlaceholder(); DynamicTextureManager.instance.preloadAndPackFrames([resId]).then(() { // 加载并合批完成后再次获取 const frame DynamicTextureManager.instance.getPackedFrame(resId); // 需要检查当前Item是否还在显示这个资源防止快速滚动时数据错位 if (frame this._currentResId resId) { this._applySpriteFrame(frame); } }).catch(err { console.error(Failed to load and pack image: ${resId}, err); this._showError(); }); } } private _applySpriteFrame(frame: SpriteFrame): void { if (this.contentSprite) { this.contentSprite.spriteFrame frame; // 因为所有frame共享同一张大纹理所以这里不会引起纹理切换drawcall得以合批。 } } private _showPlaceholder(): void { // 应用一个预加载好的、已加入动态图集的占位图SpriteFrame const placeholderFrame DynamicTextureManager.instance.getPackedFrame(placeholder); if (placeholderFrame) { this.contentSprite.spriteFrame placeholderFrame; } } private _clearDisplay(): void { this.contentSprite.spriteFrame null; this._currentResId ; } private _showError(): void { // 显示错误图标同样应预加载到动态图集中 const errorFrame DynamicTextureManager.instance.getPackedFrame(error); if (errorFrame) { this.contentSprite.spriteFrame errorFrame; } } onDestroy() { this._currentResId ; } }设计要点数据绑定updateData是核心接口列表控制器在复用Item时会调用它。异步处理即使有缓存池首次加载仍可能异步。通过_showPlaceholder确保UI不闪烁加载完成后再平滑替换。数据一致性检查在异步回调中检查this._currentResId resId至关重要。在高速滚动的长列表中Item被快速复用于不同的数据项。如果不检查会导致A项显示B项的图片造成显示错乱。3.3 与滚动列表逻辑集成你的列表逻辑无论是使用ScrollView组件还是自己实现的虚拟列表需要做相应调整。// OptimizedScrollList.ts import { _decorator, Component, ScrollView, Node, instantiate, Prefab } from cc; import { ListItemRenderer } from ./ListItemRenderer; const { ccclass, property } _decorator; ccclass(OptimizedScrollList) export class OptimizedScrollList extends Component { property(Prefab) public itemPrefab: Prefab null; property(ScrollView) public scrollView: ScrollView null; private _dataList: any[] []; private _pool: Node[] []; private _activeItems: Mapnumber, Node new Map(); // key: index, value: node // 在列表初始化或数据更新前预加载一批可能用到的图片资源 public async initData(dataList: any[]) { this._dataList dataList; // 1. 提取所有需要显示的图片资源路径 const iconUrls dataList.map(item item.icon).filter(url !!url); // 可以去重 const uniqueUrls [...new Set(iconUrls)]; // 2. 关键批量预加载并插入动态图集 // 可以在loading界面或空闲时进行避免卡顿 await DynamicTextureManager.instance.preloadAndPackFrames(uniqueUrls).catch(e { console.warn(预加载部分资源失败将采用懒加载模式, e); }); // 3. 初始化/刷新列表UI this._refreshContentView(); this._updateVisibleItems(); } private _refreshContentView() { // 设置ScrollView content的总高度等逻辑... } private _updateVisibleItems() { // 计算当前视口内应该显示的Item索引范围 const [startIdx, endIdx] this._calculateVisibleRange(); // 回收移出视口的Item for (const [idx, node] of this._activeItems) { if (idx startIdx || idx endIdx) { this._recycleItem(node, idx); } } // 为视口内的每个索引创建或复用Item for (let i startIdx; i endIdx; i) { if (this._activeItems.has(i)) continue; const itemNode this._getItemFromPool(); if (!itemNode) continue; const itemComp itemNode.getComponent(ListItemRenderer); if (itemComp) { itemComp.updateData(this._dataList[i]); // 这里触发渲染代理逻辑 } this._setItemPosition(itemNode, i); this._activeItems.set(i, itemNode); } } private _getItemFromPool(): Node { if (this._pool.length 0) { return this._pool.pop(); } return instantiate(this.itemPrefab); } private _recycleItem(node: Node, index: number): void { const itemComp node.getComponent(ListItemRenderer); // 可以通知渲染器清理当前显示避免异步回调错乱 // itemComp.clearData(); // 需要在ListItemRenderer中实现一个clearData方法用于重置状态。 node.removeFromParent(); this._pool.push(node); this._activeItems.delete(index); } // ... 其他滚动事件监听和位置计算逻辑 }4. 性能优化与疑难排查4.1 性能监控与Drawcall验证优化后如何验证效果需要使用CocosCreator的调试渲染器。在游戏运行时打开开发者工具 - 调试渲染器。勾选“显示 DrawCall”和“显示合批”等选项。观察你的长列表区域。优化前列表区域应该布满代表不同drawcall的色块。优化后如果所有头像都成功合批到同一动态图集那么整个列表至少是头像部分应该只被少数几个色块覆盖甚至是一个色块。注意动态图集不是万能的。如果图片超出了图集大小限制或者设置了不同的混合模式如BLEND_ONE、自定义材质合批仍然会被打断。确保列表Item的渲染组件属性尽量一致。4.2 常见问题与解决方案实录问题1图片加载后仍然有瞬间的闪烁或拉伸。原因虽然纹理已预加载但Sprite组件在更换spriteFrame时其UITransform的尺寸可能根据新的spriteFrame的原始尺寸发生了变化而这一变化发生在新帧渲染之前导致节点尺寸突变。解决方案在ListItemRenderer._applySpriteFrame中先锁定节点尺寸再更换spriteFrame。private _applySpriteFrame(frame: SpriteFrame): void { if (!this.contentSprite) return; const uiTrans this.contentSprite.node.getComponent(UITransform); const originalWidth uiTrans.width; const originalHeight uiTrans.height; this.contentSprite.spriteFrame frame; // 保持原有尺寸或根据设计需求进行适配避免因spriteFrame尺寸不同导致的跳动 uiTrans.setContentSize(originalWidth, originalHeight); }问题2滚动极其迅速时仍有错图出现。原因异步加载回调中的一致性检查this._currentResId resId可能不足以应对极端情况。Item被回收和复用的速度可能快于异步回调的执行。解决方案引入“请求令牌”机制。// ListItemRenderer.ts private _loadToken: number 0; public updateData(data: any): void { const resId data?.icon; this._currentResId resId; this._loadToken; // 每次新请求令牌递增 const currentToken this._loadToken; if (packedFrame) { this._applySpriteFrame(packedFrame); } else { this._showPlaceholder(); DynamicTextureManager.instance.preloadAndPackFrames([resId]).then(() { // 双重检查令牌和ID都必须匹配 if (currentToken this._loadToken this._currentResId resId) { const frame DynamicTextureManager.instance.getPackedFrame(resId); this._applySpriteFrame(frame); } }); } } public clearData(): void { this._loadToken; // 使所有进行中的异步请求失效 this._currentResId ; this._showPlaceholder(); }在_recycleItem时务必调用itemComp.clearData()。问题3动态图集很快被填满导致新图片无法插入合批失效。原因动态图集容量有限。如果列表图片数量远超图集容量且没有淘汰机制性能会退化。解决方案实现简单的分页或LRU策略。这比较复杂需要修改DynamicTextureManager。思路A分页根据图片类型或功能划分多个动态图集管理器。例如头像用一个图集图标用另一个。思路BLRU为每个缓存的SpriteFrame记录最后使用时间戳。当尝试插入新图片但图集已满时遍历图集中所有SpriteFrame找到最久未使用的将其从图集中“删除”需要引擎支持或自己管理多个Texture2D进行拷贝清理然后插入新图。这是一个高级特性需要对引擎动态图集管理有深入了解或者自己实现一个基于Canvas的运行时纹理合并器。问题4在Web平台首次加载大量图片时依然卡顿。原因预加载preloadAndPackFrames是并发进行的可能瞬间发起大量网络请求和GPU上传操作。解决方案实现分帧预加载。将预加载任务队列化每帧只处理固定数量如3-5个的资源加载与合批操作避免同一帧内过大的CPU/GPU负载。// DynamicTextureManager.ts 中改进 preloadAndPackFrames public async preloadAndPackFrames(urls: string[], maxPerFrame: number 3): Promisevoid { const uniqueNewUrls urls.filter(url !this._frameCache.has(url)); for (let i 0; i uniqueNewUrls.length; i maxPerFrame) { const batch uniqueNewUrls.slice(i, i maxPerFrame); await Promise.all(batch.map(url this._loadAndPackSingle(url))); // 每处理完一批等待下一帧避免卡死主线程 await this._waitForNextFrame(); } } private _waitForNextFrame(): Promisevoid { return new Promise(resolve { scheduleOnce(resolve, 0); }); }4.3 高级技巧与引擎AssetsManager的结合如果你的项目使用了cc.assetManager进行热更新和资源管理你需要确保动态缓存池与其协同工作。资源释放当通过assetManager释放一个资源包时如果这个包里的图片正在被动态图集引用直接释放会导致黑图。你需要在释放前遍历该包的所有图片资源路径。从你的_frameCache中移除对应记录。通知动态图集管理器如果可能将该图片从图集中移除这是一个难点因为引擎的dynamicAtlasManager可能不提供精确删除单个frame的API。更实用的做法是对于需要热更的资源不使用动态合批或者设计为整张动态图集页可被整体替换。引用计数实现一个简单的引用计数机制跟踪每个合批后的SpriteFrame被多少个ListItemRenderer使用。当计数为0且资源需要被释放时再将其标记为“可被从图集中剔除”。这需要更复杂的状态管理。5. 效果对比与总结在实施上述动态缓存池优化方案后你可以从两个维度进行对比视觉体验快速滚动长列表图片闪烁问题基本消失。取而代之的是占位图到清晰图片的平滑过渡如果你使用了占位图。性能数据通过调试渲染器观察列表区域的drawcall数量从与Item数量线性相关降低到一个相对稳定的低值取决于动态图集的分页数量。在低端手机上滚动帧率会有显著提升。我个人在实际项目中的体会是这套方案对于以用户生成内容UGC为主的长列表如聊天表情、自定义头像性能提升尤为明显。它本质上是一种权衡用额外的内存缓存纹理和初期加载时间换取运行时极致的渲染性能与流畅度。在实现时最大的坑往往不在核心的合批逻辑而在异步加载与UI生命周期的同步上务必做好请求的取消与状态校验。对于超大规模列表可能需要引入更激进的虚拟化方案即只渲染视口内极少量Item如通过Shader进行位移但这又是另一个层面的优化了。 
长河君 · 2026/8/5 16:47:44 · 阅读 1.2k CocosCreator长列表性能优化：动态缓存池与纹理合批实战
1. 项目概述长列表性能优化的核心痛点在CocosCreator项目中但凡涉及到长列表比如聊天记录、排行榜、背包、商品列表性能问题就像个定时炸弹随时可能引爆。最典型的两个症状就是图片闪烁和drawcall激增。图片闪烁指的是列表滚动时新出现的图片会短暂地显示为空白或错图然后才加载出来体验非常割裂。而drawcall激增则是性能的隐形杀手它会让你的游戏帧率骤降在低端机上直接卡成幻灯片。这两个问题看似独立实则同根同源。传统做法是给列表的每个Item都挂上一个Sprite组件并直接设置spriteFrame。当列表快速滚动时大量新的spriteFrame需要被加载、创建纹理、上传至GPU。这个加载过程是异步的如果纹理还没准备好就被绘制就会导致闪烁。同时每一个不同的spriteFrame如果没有经过合理的合批处理就会产生一个独立的drawcall。一个拥有100个不同头像的长列表理论上在最坏情况下可以产生100个drawcall这对渲染管线是毁灭性的打击。动态缓存池技术就是针对这个“根”的解决方案。它不是一个具体的API而是一种资源管理和渲染优化的设计模式。核心思想是将渲染所需的核心资源如纹理、渲染数据进行预加载和缓存并在渲染时实现实例的复用与数据的动态更新从而避免运行时频繁的资源加载与创建并创造合批条件。简单说就是“用空间换时间用设计换性能”。接下来我将拆解如何从零构建一个针对长列表优化的动态缓存池系统。2. 核心思路与架构设计2.1 问题根源深度剖析要设计解决方案必须彻底理解问题。图片闪烁和drawcall高的本质原因如下图片闪烁的根源异步加载延迟loader.loadRes或sprite.spriteFrame直接赋值新资源时如果资源不在缓存中引擎会触发异步加载。在加载完成的回调执行前精灵会处于无纹理或旧纹理状态。纹理上传耗时即使资源已存在于内存将其上传到GPU纹理显存也需要时间。如果在上传完成前提交渲染命令GPU读取到的就是无效数据。列表复用组件未重置在滚动复用Item时如果新的图片资源未就绪而旧的图片资源已被清除或重置就会显示空白。Drawcall激增的根源纹理切换这是最主要的原因。CocosCreator的渲染合批Auto-batching主要依赖于RenderTexture纹理图集。在同一批次内所有顶点数据必须使用相同的纹理更准确地说是相同的RenderTexture及其关联的材质参数。长列表中图片各异意味着频繁切换纹理合批中断drawcall必然增加。渲染状态切换除了纹理不同的混合模式、材质实例也会打断合批。2.2 动态缓存池的核心设计思想基于以上分析我们的动态缓存池系统需要达成以下几个核心目标资源预加载与缓存在列表初始化或空闲时提前将可能用到的图片资源加载到内存中并确保其对应的纹理已上传至GPU即完成texture.uploadData。这是解决闪烁问题的根本。渲染实例复用不仅仅是节点Node的复用这是ScrollView自带或需要自己实现的基础更重要的是Sprite组件所使用的底层RenderData和Model的复用或者通过动态合批手段减少渲染组件的创建。纹理合批优化这是降低drawcall的关键。我们需要将多个分散的小图片在运行时或预处理时合并到一张或几张大的纹理Texture2D上。这样即使渲染100个不同的头像只要它们来自同一张大纹理就能被合并到一个drawcall内。因此一个完整的动态缓存池架构通常包含以下模块资源管理模块负责预加载、缓存、释放图片资源。可以监听loader的生命周期。纹理合批模块核心负责将零散的小图片SpriteFrame动态打包到一张或多张“动态图集”DynamicAtlas中。CocosCreator引擎内部其实有一个DynamicAtlas系统但默认可能不满足所有需求我们需要更精细的控制。渲染代理模块列表中的Item不再直接持有Sprite组件并赋值spriteFrame而是通过一个代理。这个代理接收一个资源ID或索引内部从纹理合批模块中获取该资源对应的在大纹理上的UV坐标并动态更新某个共享Sprite组件或自定义渲染组件的顶点数据。2.3 方案选型静态合批 vs 动态合批这里有两个主要的技术路径静态合批预生成图集在编辑期或项目构建时使用TexturePacker等工具将常用小图打包成一张大图集。在运行时所有Sprite都使用这个大图集中的spriteFrame。这是性能最好的方式drawcall最低。缺点是图集尺寸有限如2048x2048无法容纳过多或过大的图片且后期增删图片需要重新打包图集不够灵活。动态合批运行时图集在运行时根据列表实际需要显示的图片动态地将它们的纹理数据复制到一张或几张GPU纹理上。CocosCreator内置的DynamicAtlas就是此类方案。优点是极其灵活可以应对未知或海量的图片资源。缺点是存在CPU上传开销将像素数据复制到纹理以及图集碎片化管理复杂度。对于长列表优化尤其是图片数量多、不确定的场景如用户头像动态合批是更可行的选择。我们的缓存池将围绕增强版的动态合批来构建。3. 关键技术实现细节3.1 构建增强型动态纹理管理器CocosCreator的director.root.pipeline.dynamicAtlasManager提供了基础的动态图集功能。但为了更精细的控制如分页、LRU释放我们需要封装自己的管理器。// DynamicTextureManager.ts import { _decorator, Texture2D, ImageAsset, dynamicAtlasManager, SpriteFrame } from cc; export class DynamicTextureManager { private static _instance: DynamicTextureManager null; public static get instance(): DynamicTextureManager { if (!this._instance) { this._instance new DynamicTextureManager(); } return this._instance; } // 存储资源路径与动态合批后spriteFrame的映射 private _frameCache: Mapstring, SpriteFrame new Map(); // 也可以存储自己创建的动态纹理页 private _texturePages: Texture2D[] []; private constructor() { // 可以在这里初始化动态图集管理器参数 // 例如dynamicAtlasManager.enabled true; // dynamicAtlasManager.maxAtlasCount 5; // 最大纹理页数 // dynamicAtlasManager.textureSize 2048; // 每页纹理大小 } /** * 预加载资源并插入动态图集 * param urls 资源路径数组 */ public async preloadAndPackFrames(urls: string[]): Promisevoid { const loadPromises urls.map(url this._loadAndPackSingle(url)); await Promise.all(loadPromises); } private async _loadAndPackSingle(url: string): PromiseSpriteFrame { if (this._frameCache.has(url)) { return this._frameCache.get(url); } return new Promise((resolve, reject) { // 1. 加载原始图片资源 loader.loadRes(url, ImageAsset, (err, imageAsset) { if (err) { reject(err); return; } // 2. 创建临时的SpriteFrame此时纹理未合批 const tempFrame new SpriteFrame(); tempFrame.texture imageAsset._texture; // 3. 关键步骤插入动态图集。 // 调用此方法后dynamicAtlasManager会将tempFrame的纹理数据复制到动态图集纹理中 // 并返回一个新的SpriteFrame其texture指向动态图集纹理并设置了正确的rect和uv。 const packedFrame dynamicAtlasManager.insertSpriteFrame(tempFrame); // 4. 缓存结果 this._frameCache.set(url, packedFrame); // 5. 销毁临时资源释放原始纹理内存可选根据需求 tempFrame.destroy(); // 注意不要销毁imageAsset因为packedFrame可能以某种方式引用它实际上需要看引擎实现。 // 更安全的做法是如果原始纹理不再需要可以释放。 // imageAsset._texture.destroy(); // 谨慎操作 resolve(packedFrame); }); }); } /** * 获取已合批的SpriteFrame */ public getPackedFrame(url: string): SpriteFrame | null { return this._frameCache.get(url) || null; } /** * 清理缓存如切换场景时 */ public clearCache(): void { this._frameCache.clear(); // 动态图集管理器有自己的清理逻辑通常我们不需要手动清理_texturePages // dynamicAtlasManager.reset(); } }关键点与注意事项insertSpriteFrame是核心魔法。它完成了将小纹理数据拷贝到大纹理上并计算正确UV坐标的工作。内存管理动态图集占用的显存是持续的。如果列表图片无限增长需要实现LRU最近最少使用策略将不常用的图片从动态图集中移除。这需要自己维护引用计数或时间戳并可能涉及到dynamicAtlasManager.deleteAtlasSpriteFrame如果引擎暴露了类似接口或自己管理多张纹理页进行替换。纹理尺寸与数量务必在项目初始化时根据目标设备性能设置合理的maxAtlasCount和textureSize。设置过大会浪费内存过小会导致图集频繁切换或插入失败。3.2 实现列表项渲染代理列表的Item预制体结构需要调整。传统的直接挂Sprite组件并改spriteFrame的方式不再适用。// ListItemRenderer.ts import { _decorator, Component, Sprite, Node, UITransform, Color } from cc; import { DynamicTextureManager } from ./DynamicTextureManager; const { ccclass, property } _decorator; ccclass(ListItemRenderer) export class ListItemRenderer extends Component { property(Sprite) public contentSprite: Sprite null; // 这个Sprite将始终使用动态图集纹理 // 当前显示的资源ID private _currentResId: string ; start() { // 确保Sprite的spriteFrame初始为空或一个默认的占位图也需加入动态图集 // this.contentSprite.spriteFrame null; } /** * 更新Item显示的数据 * param data 包含需要显示图片资源路径等信息的数据对象 */ public updateData(data: any): void { if (!data || !data.icon) { this._clearDisplay(); return; } const resId data.icon; if (this._currentResId resId) { return; // 避免重复设置 } this._currentResId resId; // 1. 先从缓存管理器获取已合批的SpriteFrame const packedFrame DynamicTextureManager.instance.getPackedFrame(resId); if (packedFrame) { // 缓存命中直接应用此时纹理已就绪无闪烁 this._applySpriteFrame(packedFrame); } else { // 2. 缓存未命中显示占位图并异步加载 this._showPlaceholder(); DynamicTextureManager.instance.preloadAndPackFrames([resId]).then(() { // 加载并合批完成后再次获取 const frame DynamicTextureManager.instance.getPackedFrame(resId); // 需要检查当前Item是否还在显示这个资源防止快速滚动时数据错位 if (frame this._currentResId resId) { this._applySpriteFrame(frame); } }).catch(err { console.error(Failed to load and pack image: ${resId}, err); this._showError(); }); } } private _applySpriteFrame(frame: SpriteFrame): void { if (this.contentSprite) { this.contentSprite.spriteFrame frame; // 因为所有frame共享同一张大纹理所以这里不会引起纹理切换drawcall得以合批。 } } private _showPlaceholder(): void { // 应用一个预加载好的、已加入动态图集的占位图SpriteFrame const placeholderFrame DynamicTextureManager.instance.getPackedFrame(placeholder); if (placeholderFrame) { this.contentSprite.spriteFrame placeholderFrame; } } private _clearDisplay(): void { this.contentSprite.spriteFrame null; this._currentResId ; } private _showError(): void { // 显示错误图标同样应预加载到动态图集中 const errorFrame DynamicTextureManager.instance.getPackedFrame(error); if (errorFrame) { this.contentSprite.spriteFrame errorFrame; } } onDestroy() { this._currentResId ; } }设计要点数据绑定updateData是核心接口列表控制器在复用Item时会调用它。异步处理即使有缓存池首次加载仍可能异步。通过_showPlaceholder确保UI不闪烁加载完成后再平滑替换。数据一致性检查在异步回调中检查this._currentResId resId至关重要。在高速滚动的长列表中Item被快速复用于不同的数据项。如果不检查会导致A项显示B项的图片造成显示错乱。3.3 与滚动列表逻辑集成你的列表逻辑无论是使用ScrollView组件还是自己实现的虚拟列表需要做相应调整。// OptimizedScrollList.ts import { _decorator, Component, ScrollView, Node, instantiate, Prefab } from cc; import { ListItemRenderer } from ./ListItemRenderer; const { ccclass, property } _decorator; ccclass(OptimizedScrollList) export class OptimizedScrollList extends Component { property(Prefab) public itemPrefab: Prefab null; property(ScrollView) public scrollView: ScrollView null; private _dataList: any[] []; private _pool: Node[] []; private _activeItems: Mapnumber, Node new Map(); // key: index, value: node // 在列表初始化或数据更新前预加载一批可能用到的图片资源 public async initData(dataList: any[]) { this._dataList dataList; // 1. 提取所有需要显示的图片资源路径 const iconUrls dataList.map(item item.icon).filter(url !!url); // 可以去重 const uniqueUrls [...new Set(iconUrls)]; // 2. 关键批量预加载并插入动态图集 // 可以在loading界面或空闲时进行避免卡顿 await DynamicTextureManager.instance.preloadAndPackFrames(uniqueUrls).catch(e { console.warn(预加载部分资源失败将采用懒加载模式, e); }); // 3. 初始化/刷新列表UI this._refreshContentView(); this._updateVisibleItems(); } private _refreshContentView() { // 设置ScrollView content的总高度等逻辑... } private _updateVisibleItems() { // 计算当前视口内应该显示的Item索引范围 const [startIdx, endIdx] this._calculateVisibleRange(); // 回收移出视口的Item for (const [idx, node] of this._activeItems) { if (idx startIdx || idx endIdx) { this._recycleItem(node, idx); } } // 为视口内的每个索引创建或复用Item for (let i startIdx; i endIdx; i) { if (this._activeItems.has(i)) continue; const itemNode this._getItemFromPool(); if (!itemNode) continue; const itemComp itemNode.getComponent(ListItemRenderer); if (itemComp) { itemComp.updateData(this._dataList[i]); // 这里触发渲染代理逻辑 } this._setItemPosition(itemNode, i); this._activeItems.set(i, itemNode); } } private _getItemFromPool(): Node { if (this._pool.length 0) { return this._pool.pop(); } return instantiate(this.itemPrefab); } private _recycleItem(node: Node, index: number): void { const itemComp node.getComponent(ListItemRenderer); // 可以通知渲染器清理当前显示避免异步回调错乱 // itemComp.clearData(); // 需要在ListItemRenderer中实现一个clearData方法用于重置状态。 node.removeFromParent(); this._pool.push(node); this._activeItems.delete(index); } // ... 其他滚动事件监听和位置计算逻辑 }4. 性能优化与疑难排查4.1 性能监控与Drawcall验证优化后如何验证效果需要使用CocosCreator的调试渲染器。在游戏运行时打开开发者工具 - 调试渲染器。勾选“显示 DrawCall”和“显示合批”等选项。观察你的长列表区域。优化前列表区域应该布满代表不同drawcall的色块。优化后如果所有头像都成功合批到同一动态图集那么整个列表至少是头像部分应该只被少数几个色块覆盖甚至是一个色块。注意动态图集不是万能的。如果图片超出了图集大小限制或者设置了不同的混合模式如BLEND_ONE、自定义材质合批仍然会被打断。确保列表Item的渲染组件属性尽量一致。4.2 常见问题与解决方案实录问题1图片加载后仍然有瞬间的闪烁或拉伸。原因虽然纹理已预加载但Sprite组件在更换spriteFrame时其UITransform的尺寸可能根据新的spriteFrame的原始尺寸发生了变化而这一变化发生在新帧渲染之前导致节点尺寸突变。解决方案在ListItemRenderer._applySpriteFrame中先锁定节点尺寸再更换spriteFrame。private _applySpriteFrame(frame: SpriteFrame): void { if (!this.contentSprite) return; const uiTrans this.contentSprite.node.getComponent(UITransform); const originalWidth uiTrans.width; const originalHeight uiTrans.height; this.contentSprite.spriteFrame frame; // 保持原有尺寸或根据设计需求进行适配避免因spriteFrame尺寸不同导致的跳动 uiTrans.setContentSize(originalWidth, originalHeight); }问题2滚动极其迅速时仍有错图出现。原因异步加载回调中的一致性检查this._currentResId resId可能不足以应对极端情况。Item被回收和复用的速度可能快于异步回调的执行。解决方案引入“请求令牌”机制。// ListItemRenderer.ts private _loadToken: number 0; public updateData(data: any): void { const resId data?.icon; this._currentResId resId; this._loadToken; // 每次新请求令牌递增 const currentToken this._loadToken; if (packedFrame) { this._applySpriteFrame(packedFrame); } else { this._showPlaceholder(); DynamicTextureManager.instance.preloadAndPackFrames([resId]).then(() { // 双重检查令牌和ID都必须匹配 if (currentToken this._loadToken this._currentResId resId) { const frame DynamicTextureManager.instance.getPackedFrame(resId); this._applySpriteFrame(frame); } }); } } public clearData(): void { this._loadToken; // 使所有进行中的异步请求失效 this._currentResId ; this._showPlaceholder(); }在_recycleItem时务必调用itemComp.clearData()。问题3动态图集很快被填满导致新图片无法插入合批失效。原因动态图集容量有限。如果列表图片数量远超图集容量且没有淘汰机制性能会退化。解决方案实现简单的分页或LRU策略。这比较复杂需要修改DynamicTextureManager。思路A分页根据图片类型或功能划分多个动态图集管理器。例如头像用一个图集图标用另一个。思路BLRU为每个缓存的SpriteFrame记录最后使用时间戳。当尝试插入新图片但图集已满时遍历图集中所有SpriteFrame找到最久未使用的将其从图集中“删除”需要引擎支持或自己管理多个Texture2D进行拷贝清理然后插入新图。这是一个高级特性需要对引擎动态图集管理有深入了解或者自己实现一个基于Canvas的运行时纹理合并器。问题4在Web平台首次加载大量图片时依然卡顿。原因预加载preloadAndPackFrames是并发进行的可能瞬间发起大量网络请求和GPU上传操作。解决方案实现分帧预加载。将预加载任务队列化每帧只处理固定数量如3-5个的资源加载与合批操作避免同一帧内过大的CPU/GPU负载。// DynamicTextureManager.ts 中改进 preloadAndPackFrames public async preloadAndPackFrames(urls: string[], maxPerFrame: number 3): Promisevoid { const uniqueNewUrls urls.filter(url !this._frameCache.has(url)); for (let i 0; i uniqueNewUrls.length; i maxPerFrame) { const batch uniqueNewUrls.slice(i, i maxPerFrame); await Promise.all(batch.map(url this._loadAndPackSingle(url))); // 每处理完一批等待下一帧避免卡死主线程 await this._waitForNextFrame(); } } private _waitForNextFrame(): Promisevoid { return new Promise(resolve { scheduleOnce(resolve, 0); }); }4.3 高级技巧与引擎AssetsManager的结合如果你的项目使用了cc.assetManager进行热更新和资源管理你需要确保动态缓存池与其协同工作。资源释放当通过assetManager释放一个资源包时如果这个包里的图片正在被动态图集引用直接释放会导致黑图。你需要在释放前遍历该包的所有图片资源路径。从你的_frameCache中移除对应记录。通知动态图集管理器如果可能将该图片从图集中移除这是一个难点因为引擎的dynamicAtlasManager可能不提供精确删除单个frame的API。更实用的做法是对于需要热更的资源不使用动态合批或者设计为整张动态图集页可被整体替换。引用计数实现一个简单的引用计数机制跟踪每个合批后的SpriteFrame被多少个ListItemRenderer使用。当计数为0且资源需要被释放时再将其标记为“可被从图集中剔除”。这需要更复杂的状态管理。5. 效果对比与总结在实施上述动态缓存池优化方案后你可以从两个维度进行对比视觉体验快速滚动长列表图片闪烁问题基本消失。取而代之的是占位图到清晰图片的平滑过渡如果你使用了占位图。性能数据通过调试渲染器观察列表区域的drawcall数量从与Item数量线性相关降低到一个相对稳定的低值取决于动态图集的分页数量。在低端手机上滚动帧率会有显著提升。我个人在实际项目中的体会是这套方案对于以用户生成内容UGC为主的长列表如聊天表情、自定义头像性能提升尤为明显。它本质上是一种权衡用额外的内存缓存纹理和初期加载时间换取运行时极致的渲染性能与流畅度。在实现时最大的坑往往不在核心的合批逻辑而在异步加载与UI生命周期的同步上务必做好请求的取消与状态校验。对于超大规模列表可能需要引入更激进的虚拟化方案即只渲染视口内极少量Item如通过Shader进行位移但这又是另一个层面的优化了。