1. 项目概述为什么我们需要无限循环列表在Unity开发中尤其是制作移动端或PC端的UI界面时我们经常会遇到一个经典场景一个列表需要展示成百上千条数据比如排行榜、背包、聊天记录或者一个大型的图库。如果使用Unity原生的ScrollRect配合GridLayoutGroup或VerticalLayoutGroup并直接实例化所有列表项Item会发生什么你的应用会瞬间卡死或者内存飙升因为每一帧都在处理成百上千个GameObject的渲染、布局和更新这无疑是性能的灾难。这就是“无限循环列表”要解决的核心痛点。它本质上是一种按需渲染的优化技术。无论数据源有多少条1万条、10万条列表中实际存在的GameObject数量只等于当前屏幕上能看到的数量再加上少量的缓冲项。当用户滚动列表时旧的、移出视口的项会被回收并立即填充新的数据重新放置到滚动方向的前端从而实现视觉上的“无限”滚动。“高性能”意味着我们需要在CPU避免不必要的布局计算、对象创建销毁和GPU减少Draw Call合批优化上都做到极致。“通用”则意味着这套方案不应该绑定特定的数据类型或UI样式它应该是一个框架能够适配各种不同的列表项预制体和数据模型。最近在社区里我看到不少朋友在搜索“unity程序打开黑屏无响应”、“unity 打包android”等问题很多时候性能问题就是罪魁祸首之一。一个设计不当的列表完全有可能成为导致应用卡顿、内存泄漏乃至崩溃的元凶。因此掌握并实现一个高性能的通用无限循环列表是中级向高级Unity开发者迈进的关键一步它能直接提升你项目的品质和用户体验。2. 核心设计思路与架构拆解实现一个无限循环列表听起来复杂但拆解开来核心思路非常清晰。我们不是去发明一个新轮子而是在Unity现有的ScrollRect和RectTransform体系之上构建一套智能的管理逻辑。2.1 核心组件职责划分一个健壮的无限循环列表系统通常由以下几个核心组件构成它们各司其职循环列表控制器 (LoopScrollRect / InfiniteScrollView)这是大脑。它继承或封装ScrollRect负责监听滚动事件、计算可视区域、管理列表项池、决定何时回收以及何时创建/复用新的列表项。它持有数据源的引用但不关心数据的具体内容。列表项预制体 (Item Prefab)这是士兵。它定义了单个列表项的外观和基本结构。一个控制器可以管理多种预制体用于不同样式的列表项但通常我们讨论的是单一预制体的情况。数据源 (Data Source)这是弹药库。它是一个抽象的数据集合可以是ListT、T[]或者任何IList实现。控制器通过索引向数据源请求数据。项渲染器委托 (Item Renderer Delegate)这是装弹手。这是一个回调函数Actionint, GameObject或接口IItemRenderer当控制器决定某个索引的项需要显示时会调用这个委托将数据源中对应索引的数据填充到回收或新创建的GameObject上。2.2 关键算法如何计算哪些项应该显示这是整个系统的数学核心。我们有一个视口Viewport一个内容区域Content。内容区域理论上应该能装下所有列表项但其高度/宽度是根据数据总量和单项大小动态计算出来的用于驱动ScrollRect的滚动条。计算步骤确定视口范围获取ScrollRect的viewport的RectTransform的边界rect。确定内容锚点Content的锚点通常设为左上角Top-Left或左下角Bottom-Left这决定了坐标原点和增长方向。我们以垂直列表、锚点在左上角为例。计算单项尺寸在初始化时我们需要知道每个列表项的高度包括间距。这可以通过实例化一个预制体获取其RectTransform.rect.height并加上预设的Spacing得到。计算索引范围内容区域的当前Y轴位置content.anchoredPosition.y是正值因为向下滚动内容向上移动。视口顶部相对于内容区域顶部的距离startPos -content.anchoredPosition.y。视口底部相对于内容区域顶部的距离endPos startPos viewport.rect.height。起始索引startIndex Mathf.FloorToInt(startPos / (itemHeight spacing))。确保不小于0。结束索引endIndex Mathf.CeilToInt(endPos / (itemHeight spacing))。确保不大于数据总数-1。这样我们就得到了当前应该显示在视口中的数据索引范围[startIndex, endIndex]。所有在这个范围内的项都必须有对应的活跃GameObject所有不在这个范围内的活跃GameObject都应该被回收到对象池。注意这里有一个非常重要的细节——缓冲Buffer。为了滚动流畅我们通常会让startIndex减去一个缓冲值如2让endIndex加上一个缓冲值。这样在用户开始滚动的瞬间下一批即将进入视口的项已经准备就绪避免了白屏或卡顿。2.3 对象池性能的基石频繁地Instantiate和Destroy是Unity中的性能杀手。对象池是解决这个问题的标准答案。我们的控制器内部需要维护一个或多个对象池。池子结构一个StackGameObject或QueueGameObject用于存放回收的项。使用Stack后进先出可能对缓存更友好。获取项当需要为一个新索引提供GameObject时首先检查池子是否为空。如果不为空Pop出一个并重置其状态如果为空则Instantiate一个新的预制体。回收项当某个项的索引移出缓冲范围时不是Destroy它而是将其SetActive(false)从Content下移除并Push回池子。池子预热在初始化时可以根据初始屏幕能显示的项数量缓冲预先实例化好这些对象放入池中避免在第一次滚动时发生实例化卡顿。3. 实现细节与核心代码解析接下来我们深入到代码层面看看如何将上述思路落地。我会以一个垂直滚动的单预制体循环列表为例进行说明。3.1 定义数据与渲染接口首先为了让系统通用我们需要定义数据填充的契约。// 这是一个简单的渲染委托你也可以定义一个接口 IItemRenderer public delegate void ItemRendererDelegate(int dataIndex, GameObject itemObject); public class LoopVerticalScrollRect : ScrollRect { // 预制体和数据源 public GameObject itemPrefab; public int totalCount; // 数据总数 public ItemRendererDelegate onItemRender; // 布局参数 public float itemHeight; public float spacing; // 对象池 private StackGameObject itemPool new StackGameObject(); // 活跃项字典Key-数据索引 Value-对应的GameObject private Dictionaryint, GameObject activeItems new Dictionaryint, GameObject(); // 当前管理的索引范围 [_startIndex, _endIndex] private int _startIndex -1; private int _endIndex -1; private int _buffer 2; // 缓冲数量 // 内容区域RectTransform的缓存 private RectTransform _contentRT; private RectTransform _viewportRT; }3.2 初始化与布局计算在Start()或一个专门的Init()方法中我们需要进行初始化。protected override void Start() { base.Start(); _contentRT content; _viewportRT viewport; // 如果未设置itemHeight则通过预制体计算 if (itemHeight 0 itemPrefab ! null) { GameObject sample Instantiate(itemPrefab); itemHeight sample.GetComponentRectTransform().rect.height; Destroy(sample); } // 计算内容区域的总高度驱动ScrollRect的滚动 float totalHeight totalCount * itemHeight (totalCount - 1) * spacing; _contentRT.SetSizeWithCurrentAnchors(RectTransform.Axis.Vertical, totalHeight); // 预热对象池创建初始可视项缓冲 int initPoolSize Mathf.CeilToInt(_viewportRT.rect.height / itemHeight) _buffer * 2; for (int i 0; i initPoolSize; i) { GameObject obj Instantiate(itemPrefab, _contentRT); obj.SetActive(false); itemPool.Push(obj); } // 初始刷新显示 RefreshAllItems(); } void RefreshAllItems() { // 清理当前所有活跃项 foreach (var kvp in activeItems) { RecycleItem(kvp.Value); } activeItems.Clear(); // 计算新的索引范围 CalculateCurrentIndexRange(out int newStart, out int newEnd); // 为新的索引范围创建项 for (int i newStart; i newEnd; i) { ProvideItemForIndex(i); } _startIndex newStart; _endIndex newEnd; }3.3 滚动监听与动态更新核心逻辑在ScrollRect的LateUpdate之后执行或者直接监听onValueChanged事件。为了更精确的控制我们重写LateUpdate。private void LateUpdate() { // 如果数据没有变化且没有在拖动/滚动中可以跳过计算 if (!IsDragging !IsVelocityActive()) return; CalculateCurrentIndexRange(out int newStart, out int newEnd); // 如果索引范围没有变化则无需更新 if (newStart _startIndex newEnd _endIndex) return; // 回收已经移出并超出缓冲范围的项 for (int i _startIndex; i _endIndex; i) { if (i newStart - _buffer || i newEnd _buffer) { if (activeItems.TryGetValue(i, out GameObject obj)) { RecycleItem(obj); activeItems.Remove(i); } } } // 为新的、在缓冲范围内且没有活跃项的索引提供GameObject for (int i newStart - _buffer; i newEnd _buffer; i) { if (i 0 || i totalCount) continue; // 索引合法性检查 if (i _startIndex - _buffer i _endIndex _buffer) continue; // 原本就在管理范围内跳过 if (!activeItems.ContainsKey(i)) { ProvideItemForIndex(i); } } // 更新所有活跃项的位置因为Content的anchoredPosition可能变了 foreach (var kvp in activeItems) { SetItemPosition(kvp.Key, kvp.Value); } _startIndex newStart; _endIndex newEnd; } void CalculateCurrentIndexRange(out int startIndex, out int endIndex) { // 获取Content的当前上边距锚点Top-Left时anchoredPosition.y是正值 float contentTop -_contentRT.anchoredPosition.y; float contentBottom contentTop _viewportRT.rect.height; startIndex Mathf.FloorToInt(contentTop / (itemHeight spacing)); endIndex Mathf.CeilToInt(contentBottom / (itemHeight spacing)); startIndex Mathf.Clamp(startIndex, 0, totalCount - 1); endIndex Mathf.Clamp(endIndex, 0, totalCount - 1); }3.4 项的提供、回收与定位这是对象池和渲染的核心操作。void ProvideItemForIndex(int index) { GameObject itemObj; if (itemPool.Count 0) { itemObj itemPool.Pop(); itemObj.SetActive(true); } else { itemObj Instantiate(itemPrefab, _contentRT); } // 设置项的位置 SetItemPosition(index, itemObj); // 调用渲染委托填充数据 onItemRender?.Invoke(index, itemObj); // 记录到活跃字典 activeItems[index] itemObj; } void RecycleItem(GameObject itemObj) { itemObj.SetActive(false); itemPool.Push(itemObj); } void SetItemPosition(int index, GameObject itemObj) { RectTransform rt itemObj.GetComponentRectTransform(); // 锚点预设为Top-Left float y -index * (itemHeight spacing); // Y坐标为负值因为向下排列 rt.anchoredPosition new Vector2(0, y); }3.5 数据更新与局部刷新一个完整的列表必须支持数据更新。比如数据源增加了、删除了或某条数据变化了。数据总量变化直接修改totalCount然后重新计算Content的总高度并调用RefreshAllItems()。注意这里可能会有项的增加或回收。局部数据更新如果只是某一条或某几条数据的内容变了而索引位置没变我们不需要动GameObject。只需要找到该索引对应的活跃GameObject再次调用onItemRender(index, obj)即可。这非常高效。数据插入/删除非末尾这是最复杂的情况因为它会导致后面所有数据的索引发生变化。一个简单粗暴的方法是调用RefreshAllItems()。更优化的方法是只更新受影响索引范围之后的项的位置和渲染数据但这需要更精细的索引偏移计算。4. 性能优化深度实践实现基础功能只是第一步要让列表真正“高性能”还需要在以下几个方面下功夫4.1 减少Canvas重建与合批优化这是影响UI性能的最大因素。无限循环列表本身已经极大减少了Canvas需要处理的元素数量但我们还可以做得更好。避免列表项内的动态布局尽量不要在列表项内部使用LayoutGroup如HorizontalLayoutGroup。LayoutGroup会在每帧或布局变化时触发昂贵的递归计算。如果必须用确保它是静态的或者在数据设置完成后手动调用LayoutRebuilder.ForceRebuildLayoutImmediate一次然后禁用或移除LayoutGroup组件。保持材质与图集一致确保所有列表项使用的图片都在同一个Sprite图集中这样它们可以被动态合批显著减少Draw Call。使用Unity的Sprite Atlas功能。分离动态与静态元素如果列表项中有频繁变化的文本如计时器考虑将其与背景等静态元素分离到不同的子Canvas或Renderer下避免因文本变化导致整个项乃至整个Canvas的重建。4.2 计算与逻辑优化使用对象池我们已经做了这是底线。避免在滚动过程中进行昂贵计算LateUpdate中的CalculateCurrentIndexRange和循环遍历要尽可能高效。如果totalCount极大可以考虑使用更高效的数据结构来查找需要回收的项。分帧处理如果在刷新全部列表RefreshAllItems时需要创建/渲染的项很多比如成百上千一次性完成可能会造成帧率卡顿。可以将这个过程分散到多帧中进行。例如每帧只处理10-20个项的创建和渲染。使用RectTransformUtility进行边界计算在计算项是否在视口内时可以使用RectTransformUtility.RectangleContainsScreenPoint进行更精确的碰撞检测但我们的基于索引的近似计算在大多数情况下已经足够快且准确。4.3 内存与资源管理池子大小管理池子不是越大越好。池大小应略大于“可视项缓冲项”的最大可能数量。可以定期检查并清理长期未使用的多余对象。预制体引用管理确保列表项预制体中没有任何对外部场景对象的引用除非是绝对静态的防止意外的内存泄漏。卸载不可见项的资源对于特别重的列表项比如包含RawImage显示网络图片当项被回收时可以主动卸载其加载的资源如将RawImage.texture设为null 触发Resources.UnloadUnusedAssets或使用Addressables进行释放。5. 常见问题与实战调试技巧在实际项目中你一定会遇到各种各样的问题。下面是我踩过的一些坑和解决方案。5.1 列表项错乱或闪烁现象快速滚动时项的内容显示错误或者出现瞬间的错位。原因与排查回收与提供时序问题确保“回收旧项”和“提供新项”的逻辑是原子的或者在同一个循环周期内完成避免中间状态被渲染。我们的代码中先回收所有需要回收的再提供所有需要提供的这个顺序是安全的。索引计算错误仔细检查CalculateCurrentIndexRange函数。确认viewport的rect、content的anchoredPosition以及锚点预设是否正确。强烈建议在编辑器下绘制调试Gizmos将计算出的视口范围世界坐标和每个活跃项的范围画出来一目了然。对象池状态未重置从池中取出的对象可能残留着上一次使用的数据。在ProvideItemForIndex中除了调用onItemRender有时还需要一个OnItemRecycle的回调用于在回收时清理项的状态例如清空文本、重置图片等。5.2 滚动卡顿或跳帧现象滚动不跟手有延迟感。原因与排查onItemRender委托过于耗时这是最常见的原因。在渲染委托中不要做复杂计算、不要同步加载资源尤其是网络图片。对于耗时操作异步进行并先显示一个占位符。Canvas重建风暴使用Unity的Profiler窗口查看Canvas.SendWillRenderCanvases的耗时。如果某一帧特别高说明有大量的UI元素被标记为脏需要重建。检查列表项内部是否有不必要的SetActive、颜色/材质改变、文本频繁更新等操作。物理或其它系统干扰确保列表项的Layer不会与物理世界发生交互避免不必要的Raycast。可以将ScrollRect的Movement Type设为Clamped或Elastic并适当调整Inertia惯性参数让手感更舒适。5.3 与Input Field等UI组件的交互问题现象当列表项中有InputField时滚动操作可能会和输入框的点击/拖拽冲突。解决方案ScrollRect有一个Scroll Sensitivity滚动灵敏度设置可以调低。更根本的方法是监听InputField的OnSelect事件当输入框被选中时暂时禁用ScrollRect的滚动scrollRect.enabled false在InputField失去焦点OnDeselect时再重新启用。这需要精细的事件管理。5.4 对不规则高度项的支持我们上面的实现基于固定itemHeight。如果要支持类似微信聊天记录那样不同高度的项复杂度会大大增加。实现思路预先计算或动态计算高度需要为每个索引存储一个计算好的高度值。这要求数据源能提供高度或者提供一个能根据数据计算高度的委托。内容总高度计算Content的总高度不再是itemHeight * count而是所有项高度之和。索引范围计算无法再用除法简单计算。需要维护一个“累积高度”的数组或进行二分查找找到当前视口位置所对应的起始和结束索引。这会带来额外的计算开销。项的位置计算SetItemPosition时需要根据该索引之前所有项的高度总和来计算Y坐标。市面上成熟的资产如Unity UI Extensions中的LoopScrollRect通常都支持可变大小但其内部实现也复杂得多。如果你的项目不需要坚决使用固定高度以获得最佳性能。6. 进阶扩展与生态集成一个基础的循环列表满足大部分需求但在复杂的项目中我们可能需要更多功能。多预制体支持数据源中每个索引可以对应一个预制体类型ID。控制器需要管理多个对象池每个预制体一个池并根据ID从对应的池中取用对象。渲染委托也需要接收这个ID。水平与网格布局原理与垂直列表相同只是将Y轴的计算换成X轴水平或同时计算X和Y轴网格。网格布局需要知道每行的列数columns。与数据绑定框架集成如将循环列表与UniRx、Zenject或Unity的MVP/MVVM模式结合。让列表控制器只负责视图的回收与放置而项的数据填充通过观察数据模型的变化自动完成实现更清晰的关注点分离。动画与特效在项出现Provide、消失Recycle时可以加入淡入淡出、缩放等简单动画提升用户体验。注意动画性能避免使用LayoutGroup配合Content Size Fitter做动画。实现一个高性能的通用无限循环列表是对开发者Unity UI系统理解、算法设计和性能优化能力的综合考验。它没有使用任何黑魔法所有的优化都源于对引擎机制的理解和对细节的掌控。从最简单的固定高度列表开始逐步迭代加入缓冲、对象池、局部刷新最后挑战可变高度和多预制体这个学习过程本身就能让你对Unity UI的认知提升一个层次。
Unity高性能无限循环列表：原理、实现与优化实践
发布时间：2026/7/19 7:53:38
1. 项目概述为什么我们需要无限循环列表在Unity开发中尤其是制作移动端或PC端的UI界面时我们经常会遇到一个经典场景一个列表需要展示成百上千条数据比如排行榜、背包、聊天记录或者一个大型的图库。如果使用Unity原生的ScrollRect配合GridLayoutGroup或VerticalLayoutGroup并直接实例化所有列表项Item会发生什么你的应用会瞬间卡死或者内存飙升因为每一帧都在处理成百上千个GameObject的渲染、布局和更新这无疑是性能的灾难。这就是“无限循环列表”要解决的核心痛点。它本质上是一种按需渲染的优化技术。无论数据源有多少条1万条、10万条列表中实际存在的GameObject数量只等于当前屏幕上能看到的数量再加上少量的缓冲项。当用户滚动列表时旧的、移出视口的项会被回收并立即填充新的数据重新放置到滚动方向的前端从而实现视觉上的“无限”滚动。“高性能”意味着我们需要在CPU避免不必要的布局计算、对象创建销毁和GPU减少Draw Call合批优化上都做到极致。“通用”则意味着这套方案不应该绑定特定的数据类型或UI样式它应该是一个框架能够适配各种不同的列表项预制体和数据模型。最近在社区里我看到不少朋友在搜索“unity程序打开黑屏无响应”、“unity 打包android”等问题很多时候性能问题就是罪魁祸首之一。一个设计不当的列表完全有可能成为导致应用卡顿、内存泄漏乃至崩溃的元凶。因此掌握并实现一个高性能的通用无限循环列表是中级向高级Unity开发者迈进的关键一步它能直接提升你项目的品质和用户体验。2. 核心设计思路与架构拆解实现一个无限循环列表听起来复杂但拆解开来核心思路非常清晰。我们不是去发明一个新轮子而是在Unity现有的ScrollRect和RectTransform体系之上构建一套智能的管理逻辑。2.1 核心组件职责划分一个健壮的无限循环列表系统通常由以下几个核心组件构成它们各司其职循环列表控制器 (LoopScrollRect / InfiniteScrollView)这是大脑。它继承或封装ScrollRect负责监听滚动事件、计算可视区域、管理列表项池、决定何时回收以及何时创建/复用新的列表项。它持有数据源的引用但不关心数据的具体内容。列表项预制体 (Item Prefab)这是士兵。它定义了单个列表项的外观和基本结构。一个控制器可以管理多种预制体用于不同样式的列表项但通常我们讨论的是单一预制体的情况。数据源 (Data Source)这是弹药库。它是一个抽象的数据集合可以是ListT、T[]或者任何IList实现。控制器通过索引向数据源请求数据。项渲染器委托 (Item Renderer Delegate)这是装弹手。这是一个回调函数Actionint, GameObject或接口IItemRenderer当控制器决定某个索引的项需要显示时会调用这个委托将数据源中对应索引的数据填充到回收或新创建的GameObject上。2.2 关键算法如何计算哪些项应该显示这是整个系统的数学核心。我们有一个视口Viewport一个内容区域Content。内容区域理论上应该能装下所有列表项但其高度/宽度是根据数据总量和单项大小动态计算出来的用于驱动ScrollRect的滚动条。计算步骤确定视口范围获取ScrollRect的viewport的RectTransform的边界rect。确定内容锚点Content的锚点通常设为左上角Top-Left或左下角Bottom-Left这决定了坐标原点和增长方向。我们以垂直列表、锚点在左上角为例。计算单项尺寸在初始化时我们需要知道每个列表项的高度包括间距。这可以通过实例化一个预制体获取其RectTransform.rect.height并加上预设的Spacing得到。计算索引范围内容区域的当前Y轴位置content.anchoredPosition.y是正值因为向下滚动内容向上移动。视口顶部相对于内容区域顶部的距离startPos -content.anchoredPosition.y。视口底部相对于内容区域顶部的距离endPos startPos viewport.rect.height。起始索引startIndex Mathf.FloorToInt(startPos / (itemHeight spacing))。确保不小于0。结束索引endIndex Mathf.CeilToInt(endPos / (itemHeight spacing))。确保不大于数据总数-1。这样我们就得到了当前应该显示在视口中的数据索引范围[startIndex, endIndex]。所有在这个范围内的项都必须有对应的活跃GameObject所有不在这个范围内的活跃GameObject都应该被回收到对象池。注意这里有一个非常重要的细节——缓冲Buffer。为了滚动流畅我们通常会让startIndex减去一个缓冲值如2让endIndex加上一个缓冲值。这样在用户开始滚动的瞬间下一批即将进入视口的项已经准备就绪避免了白屏或卡顿。2.3 对象池性能的基石频繁地Instantiate和Destroy是Unity中的性能杀手。对象池是解决这个问题的标准答案。我们的控制器内部需要维护一个或多个对象池。池子结构一个StackGameObject或QueueGameObject用于存放回收的项。使用Stack后进先出可能对缓存更友好。获取项当需要为一个新索引提供GameObject时首先检查池子是否为空。如果不为空Pop出一个并重置其状态如果为空则Instantiate一个新的预制体。回收项当某个项的索引移出缓冲范围时不是Destroy它而是将其SetActive(false)从Content下移除并Push回池子。池子预热在初始化时可以根据初始屏幕能显示的项数量缓冲预先实例化好这些对象放入池中避免在第一次滚动时发生实例化卡顿。3. 实现细节与核心代码解析接下来我们深入到代码层面看看如何将上述思路落地。我会以一个垂直滚动的单预制体循环列表为例进行说明。3.1 定义数据与渲染接口首先为了让系统通用我们需要定义数据填充的契约。// 这是一个简单的渲染委托你也可以定义一个接口 IItemRenderer public delegate void ItemRendererDelegate(int dataIndex, GameObject itemObject); public class LoopVerticalScrollRect : ScrollRect { // 预制体和数据源 public GameObject itemPrefab; public int totalCount; // 数据总数 public ItemRendererDelegate onItemRender; // 布局参数 public float itemHeight; public float spacing; // 对象池 private StackGameObject itemPool new StackGameObject(); // 活跃项字典Key-数据索引 Value-对应的GameObject private Dictionaryint, GameObject activeItems new Dictionaryint, GameObject(); // 当前管理的索引范围 [_startIndex, _endIndex] private int _startIndex -1; private int _endIndex -1; private int _buffer 2; // 缓冲数量 // 内容区域RectTransform的缓存 private RectTransform _contentRT; private RectTransform _viewportRT; }3.2 初始化与布局计算在Start()或一个专门的Init()方法中我们需要进行初始化。protected override void Start() { base.Start(); _contentRT content; _viewportRT viewport; // 如果未设置itemHeight则通过预制体计算 if (itemHeight 0 itemPrefab ! null) { GameObject sample Instantiate(itemPrefab); itemHeight sample.GetComponentRectTransform().rect.height; Destroy(sample); } // 计算内容区域的总高度驱动ScrollRect的滚动 float totalHeight totalCount * itemHeight (totalCount - 1) * spacing; _contentRT.SetSizeWithCurrentAnchors(RectTransform.Axis.Vertical, totalHeight); // 预热对象池创建初始可视项缓冲 int initPoolSize Mathf.CeilToInt(_viewportRT.rect.height / itemHeight) _buffer * 2; for (int i 0; i initPoolSize; i) { GameObject obj Instantiate(itemPrefab, _contentRT); obj.SetActive(false); itemPool.Push(obj); } // 初始刷新显示 RefreshAllItems(); } void RefreshAllItems() { // 清理当前所有活跃项 foreach (var kvp in activeItems) { RecycleItem(kvp.Value); } activeItems.Clear(); // 计算新的索引范围 CalculateCurrentIndexRange(out int newStart, out int newEnd); // 为新的索引范围创建项 for (int i newStart; i newEnd; i) { ProvideItemForIndex(i); } _startIndex newStart; _endIndex newEnd; }3.3 滚动监听与动态更新核心逻辑在ScrollRect的LateUpdate之后执行或者直接监听onValueChanged事件。为了更精确的控制我们重写LateUpdate。private void LateUpdate() { // 如果数据没有变化且没有在拖动/滚动中可以跳过计算 if (!IsDragging !IsVelocityActive()) return; CalculateCurrentIndexRange(out int newStart, out int newEnd); // 如果索引范围没有变化则无需更新 if (newStart _startIndex newEnd _endIndex) return; // 回收已经移出并超出缓冲范围的项 for (int i _startIndex; i _endIndex; i) { if (i newStart - _buffer || i newEnd _buffer) { if (activeItems.TryGetValue(i, out GameObject obj)) { RecycleItem(obj); activeItems.Remove(i); } } } // 为新的、在缓冲范围内且没有活跃项的索引提供GameObject for (int i newStart - _buffer; i newEnd _buffer; i) { if (i 0 || i totalCount) continue; // 索引合法性检查 if (i _startIndex - _buffer i _endIndex _buffer) continue; // 原本就在管理范围内跳过 if (!activeItems.ContainsKey(i)) { ProvideItemForIndex(i); } } // 更新所有活跃项的位置因为Content的anchoredPosition可能变了 foreach (var kvp in activeItems) { SetItemPosition(kvp.Key, kvp.Value); } _startIndex newStart; _endIndex newEnd; } void CalculateCurrentIndexRange(out int startIndex, out int endIndex) { // 获取Content的当前上边距锚点Top-Left时anchoredPosition.y是正值 float contentTop -_contentRT.anchoredPosition.y; float contentBottom contentTop _viewportRT.rect.height; startIndex Mathf.FloorToInt(contentTop / (itemHeight spacing)); endIndex Mathf.CeilToInt(contentBottom / (itemHeight spacing)); startIndex Mathf.Clamp(startIndex, 0, totalCount - 1); endIndex Mathf.Clamp(endIndex, 0, totalCount - 1); }3.4 项的提供、回收与定位这是对象池和渲染的核心操作。void ProvideItemForIndex(int index) { GameObject itemObj; if (itemPool.Count 0) { itemObj itemPool.Pop(); itemObj.SetActive(true); } else { itemObj Instantiate(itemPrefab, _contentRT); } // 设置项的位置 SetItemPosition(index, itemObj); // 调用渲染委托填充数据 onItemRender?.Invoke(index, itemObj); // 记录到活跃字典 activeItems[index] itemObj; } void RecycleItem(GameObject itemObj) { itemObj.SetActive(false); itemPool.Push(itemObj); } void SetItemPosition(int index, GameObject itemObj) { RectTransform rt itemObj.GetComponentRectTransform(); // 锚点预设为Top-Left float y -index * (itemHeight spacing); // Y坐标为负值因为向下排列 rt.anchoredPosition new Vector2(0, y); }3.5 数据更新与局部刷新一个完整的列表必须支持数据更新。比如数据源增加了、删除了或某条数据变化了。数据总量变化直接修改totalCount然后重新计算Content的总高度并调用RefreshAllItems()。注意这里可能会有项的增加或回收。局部数据更新如果只是某一条或某几条数据的内容变了而索引位置没变我们不需要动GameObject。只需要找到该索引对应的活跃GameObject再次调用onItemRender(index, obj)即可。这非常高效。数据插入/删除非末尾这是最复杂的情况因为它会导致后面所有数据的索引发生变化。一个简单粗暴的方法是调用RefreshAllItems()。更优化的方法是只更新受影响索引范围之后的项的位置和渲染数据但这需要更精细的索引偏移计算。4. 性能优化深度实践实现基础功能只是第一步要让列表真正“高性能”还需要在以下几个方面下功夫4.1 减少Canvas重建与合批优化这是影响UI性能的最大因素。无限循环列表本身已经极大减少了Canvas需要处理的元素数量但我们还可以做得更好。避免列表项内的动态布局尽量不要在列表项内部使用LayoutGroup如HorizontalLayoutGroup。LayoutGroup会在每帧或布局变化时触发昂贵的递归计算。如果必须用确保它是静态的或者在数据设置完成后手动调用LayoutRebuilder.ForceRebuildLayoutImmediate一次然后禁用或移除LayoutGroup组件。保持材质与图集一致确保所有列表项使用的图片都在同一个Sprite图集中这样它们可以被动态合批显著减少Draw Call。使用Unity的Sprite Atlas功能。分离动态与静态元素如果列表项中有频繁变化的文本如计时器考虑将其与背景等静态元素分离到不同的子Canvas或Renderer下避免因文本变化导致整个项乃至整个Canvas的重建。4.2 计算与逻辑优化使用对象池我们已经做了这是底线。避免在滚动过程中进行昂贵计算LateUpdate中的CalculateCurrentIndexRange和循环遍历要尽可能高效。如果totalCount极大可以考虑使用更高效的数据结构来查找需要回收的项。分帧处理如果在刷新全部列表RefreshAllItems时需要创建/渲染的项很多比如成百上千一次性完成可能会造成帧率卡顿。可以将这个过程分散到多帧中进行。例如每帧只处理10-20个项的创建和渲染。使用RectTransformUtility进行边界计算在计算项是否在视口内时可以使用RectTransformUtility.RectangleContainsScreenPoint进行更精确的碰撞检测但我们的基于索引的近似计算在大多数情况下已经足够快且准确。4.3 内存与资源管理池子大小管理池子不是越大越好。池大小应略大于“可视项缓冲项”的最大可能数量。可以定期检查并清理长期未使用的多余对象。预制体引用管理确保列表项预制体中没有任何对外部场景对象的引用除非是绝对静态的防止意外的内存泄漏。卸载不可见项的资源对于特别重的列表项比如包含RawImage显示网络图片当项被回收时可以主动卸载其加载的资源如将RawImage.texture设为null 触发Resources.UnloadUnusedAssets或使用Addressables进行释放。5. 常见问题与实战调试技巧在实际项目中你一定会遇到各种各样的问题。下面是我踩过的一些坑和解决方案。5.1 列表项错乱或闪烁现象快速滚动时项的内容显示错误或者出现瞬间的错位。原因与排查回收与提供时序问题确保“回收旧项”和“提供新项”的逻辑是原子的或者在同一个循环周期内完成避免中间状态被渲染。我们的代码中先回收所有需要回收的再提供所有需要提供的这个顺序是安全的。索引计算错误仔细检查CalculateCurrentIndexRange函数。确认viewport的rect、content的anchoredPosition以及锚点预设是否正确。强烈建议在编辑器下绘制调试Gizmos将计算出的视口范围世界坐标和每个活跃项的范围画出来一目了然。对象池状态未重置从池中取出的对象可能残留着上一次使用的数据。在ProvideItemForIndex中除了调用onItemRender有时还需要一个OnItemRecycle的回调用于在回收时清理项的状态例如清空文本、重置图片等。5.2 滚动卡顿或跳帧现象滚动不跟手有延迟感。原因与排查onItemRender委托过于耗时这是最常见的原因。在渲染委托中不要做复杂计算、不要同步加载资源尤其是网络图片。对于耗时操作异步进行并先显示一个占位符。Canvas重建风暴使用Unity的Profiler窗口查看Canvas.SendWillRenderCanvases的耗时。如果某一帧特别高说明有大量的UI元素被标记为脏需要重建。检查列表项内部是否有不必要的SetActive、颜色/材质改变、文本频繁更新等操作。物理或其它系统干扰确保列表项的Layer不会与物理世界发生交互避免不必要的Raycast。可以将ScrollRect的Movement Type设为Clamped或Elastic并适当调整Inertia惯性参数让手感更舒适。5.3 与Input Field等UI组件的交互问题现象当列表项中有InputField时滚动操作可能会和输入框的点击/拖拽冲突。解决方案ScrollRect有一个Scroll Sensitivity滚动灵敏度设置可以调低。更根本的方法是监听InputField的OnSelect事件当输入框被选中时暂时禁用ScrollRect的滚动scrollRect.enabled false在InputField失去焦点OnDeselect时再重新启用。这需要精细的事件管理。5.4 对不规则高度项的支持我们上面的实现基于固定itemHeight。如果要支持类似微信聊天记录那样不同高度的项复杂度会大大增加。实现思路预先计算或动态计算高度需要为每个索引存储一个计算好的高度值。这要求数据源能提供高度或者提供一个能根据数据计算高度的委托。内容总高度计算Content的总高度不再是itemHeight * count而是所有项高度之和。索引范围计算无法再用除法简单计算。需要维护一个“累积高度”的数组或进行二分查找找到当前视口位置所对应的起始和结束索引。这会带来额外的计算开销。项的位置计算SetItemPosition时需要根据该索引之前所有项的高度总和来计算Y坐标。市面上成熟的资产如Unity UI Extensions中的LoopScrollRect通常都支持可变大小但其内部实现也复杂得多。如果你的项目不需要坚决使用固定高度以获得最佳性能。6. 进阶扩展与生态集成一个基础的循环列表满足大部分需求但在复杂的项目中我们可能需要更多功能。多预制体支持数据源中每个索引可以对应一个预制体类型ID。控制器需要管理多个对象池每个预制体一个池并根据ID从对应的池中取用对象。渲染委托也需要接收这个ID。水平与网格布局原理与垂直列表相同只是将Y轴的计算换成X轴水平或同时计算X和Y轴网格。网格布局需要知道每行的列数columns。与数据绑定框架集成如将循环列表与UniRx、Zenject或Unity的MVP/MVVM模式结合。让列表控制器只负责视图的回收与放置而项的数据填充通过观察数据模型的变化自动完成实现更清晰的关注点分离。动画与特效在项出现Provide、消失Recycle时可以加入淡入淡出、缩放等简单动画提升用户体验。注意动画性能避免使用LayoutGroup配合Content Size Fitter做动画。实现一个高性能的通用无限循环列表是对开发者Unity UI系统理解、算法设计和性能优化能力的综合考验。它没有使用任何黑魔法所有的优化都源于对引擎机制的理解和对细节的掌控。从最简单的固定高度列表开始逐步迭代加入缓冲、对象池、局部刷新最后挑战可变高度和多预制体这个学习过程本身就能让你对Unity UI的认知提升一个层次。
