1. 项目概述为什么我们需要自动循环滚动列表在Unity3D的UGUI开发中但凡涉及到列表展示无论是排行榜、背包系统、聊天记录还是商品橱窗ScrollRect组件都是绕不开的核心。但只要你做过稍微复杂一点的列表比如一个拥有几百条数据的聊天记录一个包含上千个道具的背包你肯定遇到过那个让人头疼的问题性能断崖式下跌。游戏帧率FPS直接从60掉到20以下滑动起来卡顿感明显内存占用也蹭蹭往上涨。这就是原生ScrollRect直接实例化所有列表项Item带来的恶果。所以“自动循环滚动列表”这个轮子几乎是每个稍有经验的Unity UI程序员都会自己造一遍的。它的核心思想非常直观只创建和渲染当前可视区域Viewport内以及少量缓冲区的列表项。当列表项滑出可视区域时我们并不销毁它而是立刻将其回收并移动到即将进入可视区域的位置更新其显示的数据。这样一来无论你的数据源有1万条还是10万条屏幕上实际存在的GameObject可能只有10到20个性能开销被恒定在一个极低的水平。网上能找到的循环列表方案很多但要么耦合度太高难以集成到现有项目要么功能简陋不支持不同尺寸的Item、不处理边缘回弹、或者数据刷新逻辑混乱。今天我要分享的这套C#源码是我在多个上线项目中打磨出来的它不仅仅实现了“循环”更在易用性、扩展性和稳定性上做了大量优化。你拿到手后几乎可以像使用原生ScrollRect一样通过简单的数据绑定就获得一个高性能的无限滚动列表。2. 核心设计思路与架构拆解在动手写代码之前我们必须把设计思路理清楚。一个健壮的循环滚动列表不能只是一个简单的“对象池位置计算”它需要一套清晰的架构来管理状态、处理数据和响应交互。2.1 核心组件职责划分我设计的这个循环列表系统主要由三个核心类构成职责分明耦合度低LoopScrollRect(继承自ScrollRect): 这是主控制器。它接管了原生ScrollRect的滚动逻辑但重写了关键方法。它的核心职责是监听滚动事件onValueChanged。根据滚动位置和方向计算当前哪些数据索引应该被显示。指挥LoopScrollItemPool提供或回收Item。调用ILoopScrollDataSource来为Item填充数据。LoopScrollItemPool(对象池管理器): 负责Item的生命周期管理。它不是一个简单的ListGameObject而是一个智能的缓存系统。预热Preheat: 在列表初始化时根据可视区域大小提前实例化出刚好足够覆盖甚至略多于屏幕的Item避免滚动时突然实例化造成的卡顿。提供Get: 当需要显示一个新索引的Item时池子首先检查是否有已回收未激活的、同类型的Item可用。如果有则复用如果没有则根据预设的Prefab实例化一个新的。回收Recycle: 当Item滑出可视区域并加上一个缓冲距离后将其放回池中设置为未激活状态等待下次复用。这里的关键是判断回收时机的算法要既及时又不至于在快速滚动时出现闪烁。ILoopScrollDataSource(数据源接口): 这是连接你的业务数据和UI展示的桥梁。采用接口设计是为了解耦。你的数据可以来自任何地方——一个ListT一个字典甚至网络请求。你只需要实现这个接口循环列表本身不关心你的数据具体如何存储。int GetItemCount(): 返回数据总条数。void ProvideData(Transform itemTransform, int index): 这是最重要的方法。当某个Item需要显示第index条数据时列表会调用这个方法并把这个Item的Transform传给你。你需要在这个方法里找到Item上的Text、Image等组件并用你的第index条数据去填充它们。2.2 滚动方向与Item尺寸处理循环列表必须完美支持垂直滚动Vertical和水平滚动Horizontal。两者的计算逻辑镜像对称但需要分开处理。垂直滚动: Item的锚点Anchor通常设置为Top-Stretch其位置由anchoredPosition.y决定。我们需要计算每个Item的顶部top和底部bottom在世界空间或本地空间中的位置来判断它是否在Viewport内。水平滚动: Item的锚点通常设置为Left-Stretch其位置由anchoredPosition.x决定。判断依据是Item的左侧left和右侧right。更复杂的情况是**动态尺寸Dynamic Size**的Item。比如聊天列表每条消息的文本长度不同气泡高度也就不同。对于这种需求我们的架构需要支持初始化时计算: 在提供数据后强制立即布局LayoutRebuilder.ForceRebuildLayoutImmediate来获取Item渲染后的实际高度或宽度。缓存尺寸: 将计算出的每个索引的Item尺寸缓存起来避免重复计算。这里可以用一个数组或字典来存储。位置推算: 在滚动时根据缓存的所有Item的尺寸累加计算出任意一个数据索引的Item应该所在的位置。这是循环列表算法中最核心的数学部分。2.3 与原生UGUI的兼容性思考我们继承自ScrollRect因此天然拥有原生的所有特性惯性滚动、弹性回弹Elasticity、滚动条Scrollbar支持。这是一个巨大的优势。我们的任务不是推翻它而是增强它。因此在重写像SetContentAnchoredPosition这样的方法时必须小心处理确保在不破坏原生滚动体验的前提下插入我们的循环逻辑。3. 关键实现细节与源码解析接下来我们深入到代码层面看看几个最关键的实现细节。我会贴出核心代码片段并解释每一行背后的意图。3.1 对象池LoopScrollItemPool的智能回收策略对象池的核心难点不在于“存”和“取”而在于何时回收。回收早了快速滚动时边缘的Item可能会闪一下回收晚了池子里闲置的Item过多失去优化意义。我的策略是引入一个“缓冲区BufferZone”的概念。Viewport的可视区域外上下或左右各预留一段缓冲区。只有当Item完全离开“可视区域缓冲区”后才进行回收。// 这是一个简化的判断逻辑以垂直滚动为例 private bool IsItemBeyondViewport(RectTransform itemRect, float buffer) { // 获取Viewport的边界 float viewportTop viewportRectTransform.rect.yMax; float viewportBottom viewportRectTransform.rect.yMin; // 将Item的边界转换到Viewport的本地空间 Vector3[] itemCorners new Vector3[4]; itemRect.GetWorldCorners(itemCorners); // 这里需要将worldCorners转换到viewport的本地空间简化起见我们理解概念 float itemWorldTop itemCorners[1].y; // 左上角 float itemWorldBottom itemCorners[0].y; // 左下角 // 判断如果Item的底部 (Viewport顶部 缓冲区) 或 Item的顶部 (Viewport底部 - 缓冲区)则回收 bool isBeyondTop itemWorldBottom (viewportTop buffer); bool isBeyondBottom itemWorldTop (viewportBottom - buffer); return isBeyondTop || isBeyondBottom; }实操心得buffer的大小设置很有讲究。我通常设置为1.5到2个Item的高度/宽度。太小了在高速滚动下不保险太大了浪费内存。你可以根据项目实际滚动速度调整这个参数。3.2 数据索引与显示Item的映射管理我们需要一个高效的结构来维护“当前屏幕上显示的是哪几个数据索引以及它们分别对应哪个GameObject”。我使用两个Dictionary来实现双向查找private Dictionaryint, RectTransform m_activeItems new Dictionaryint, RectTransform(); // 索引 - Item private DictionaryRectTransform, int m_itemToIndex new DictionaryRectTransform, int(); // Item - 索引当滚动发生时LoopScrollRect会计算新的索引范围startIndex,endIndex。然后执行一个刷新循环遍历当前m_activeItems将不在新范围[startIndex, endIndex]内的Item回收至对象池并从字典中移除。遍历新范围[startIndex, endIndex]对于当前m_activeItems中不存在的索引向对象池申请一个新的Item。为申请到的新Item以及因为数据变化可能需要刷新的已有Item调用数据源的ProvideData方法并更新两个字典。这个过程必须高效因为它在每一帧滚动时都可能被调用。3.3 动态尺寸Item的位置计算与缓存这是循环列表的“终极挑战”。假设我们支持垂直滚动的动态高度Item。首先我们需要一个数组来缓存每个Item的高度private float[] m_itemSizes; // m_itemSizes[index] 存储第index个Item的高度当数据源变化如新增一条聊天记录或者某个Item的尺寸可能发生变化时我们需要更新缓存。但全量重新计算所有Item的尺寸是灾难性的。因此我采用了惰性计算Lazy Calculation和局部更新的策略。初始化/重置时如果数据总量不大比如小于500可以暴力计算所有。如果很大则只计算前N个足以填满屏幕的尺寸后面的用一个预估的平均高度暂时填充。当滚动到未计算过的索引时再进行实时计算并更新缓存。提供数据时在ProvideData调用后立即强制布局重建然后通过LayoutUtility.GetPreferredHeight或直接读取rectTransform.rect.height来获取实际高度。计算位置要找到第index个Item的起始Y坐标公式为posY sum(m_itemSizes[0] m_itemSizes[1] ... m_itemSizes[index-1])。我们可以维护一个前缀和数组来加速这个计算避免每次滚动都进行O(n)的累加。// 计算内容的总高度并设置Content的sizeDelta.y private void UpdateContentSize() { float totalHeight 0; for(int i 0; i totalCount; i) { totalHeight GetItemSize(i); // GetItemSize会从缓存读取或计算 } content.sizeDelta new Vector2(content.sizeDelta.x, totalHeight); } // 根据索引获取Item的位置 private float GetItemPosition(int index) { float pos 0; for(int i 0; i index; i) { pos GetItemSize(i); } return pos; // 这里假设锚点在顶部所以pos是Item顶部的Y值 }注意动态尺寸的计算和缓存是性能敏感区。一定要做好边界判断避免在滚动过程中频繁触发LayoutRebuilder.ForceRebuildLayoutImmediate这个调用本身是比较耗时的。可以考虑在一帧内只处理一个未计算尺寸的Item。4. 完整集成与使用指南理论说了这么多现在来看看怎么在你的项目里用起来。我会假设你已经有了一个UGUI的ScrollRect基础结构。4.1 第一步创建Item预制体Prefab这和普通列表项制作没有任何区别。比如做一个简单的消息Item在UI下创建一个Image作为背景。在它下面添加Text组件显示消息内容。确保这个GameObject上有LayoutElement组件如果你希望高度自适应或者固定好它的RectTransform尺寸。将这个GameObject做成Prefab比如叫MessageItem.prefab。4.2 第二步实现数据源接口ILoopScrollDataSource在你的游戏逻辑脚本里比如ChatManager实现这个接口。using UnityEngine; public class ChatLoopScrollDataSource : MonoBehaviour, ILoopScrollDataSource { // 你的业务数据 public ListChatMessage messageList new ListChatMessage(); public int GetItemCount() { return messageList.Count; } public void ProvideData(Transform itemTransform, int index) { // 1. 安全校验 if (index 0 || index messageList.Count) { Debug.LogError($Index {index} out of range!); itemTransform.gameObject.SetActive(false); return; } // 2. 获取或添加Item上的逻辑组件推荐 var itemUI itemTransform.GetComponentChatMessageItemUI(); if (itemUI null) { itemUI itemTransform.gameObject.AddComponentChatMessageItemUI(); } // 3. 用数据填充UI组件 ChatMessage msg messageList[index]; itemUI.SetMessage(msg.Content, msg.Sender, msg.Time); // 4. 如果是动态尺寸在这里ItemUI的SetMessage方法内部可能会改变文本长度从而改变Item高度。 // LoopScrollRect会在调用ProvideData后自动处理尺寸更新和位置重排。 } }4.3 第三步配置LoopScrollRect组件在场景中找到你的ScrollRect游戏对象。移除或禁用原生的ScrollRect组件。添加我们编写的LoopScrollRect脚本。在Inspector面板上进行配置Item Prefab: 拖入第一步制作的MessageItem.prefab。Data Source: 拖入第二步创建的ChatLoopScrollDataSource脚本所在的游戏对象。Pool Size: 对象池初始大小。设置为0脚本会根据Viewport大小自动计算一个合理值。Buffer Factor: 前面提到的缓冲区系数比如1.5。Direction: 滚动方向选择Vertical。其他如Movement Type,Elasticity,Inertia等继承自ScrollRect的属性按需设置。4.4 第四步运行时操作列表现在你可以通过操作数据源来驱动列表的更新。// 添加新消息 void OnReceiveNewMessage(string content) { messageList.Add(new ChatMessage(content)); // 通知列表数据总量变了 loopScrollRect.RefreshItemCount(); // 如果你希望列表自动滚动到底部像微信一样 loopScrollRect.SrollToBottom(); } // 清空列表 void OnClearChat() { messageList.Clear(); loopScrollRect.RefreshItemCount(); } // 更新某条消息比如消息状态变为“已读” void UpdateMessageAt(int index) { if(index 0 index messageList.Count) { messageList[index].IsRead true; // 如果该消息当前正在屏幕上显示需要刷新它 loopScrollRect.RefreshItem(index); } }RefreshItemCount()和RefreshItem(int index)是LoopScrollRect暴露的关键方法它们内部会触发重新计算索引范围、回收/申请Item、调用ProvideData等一系列操作。5. 实战中遇到的坑与优化技巧这套方案在多个项目中使用后我积累了一些宝贵的“踩坑”经验。5.1 性能陷阱与优化Canvas的“脏区域”重绘即使我们只更新了少数几个Item的文本UGUI的Canvas在默认情况下也可能重绘整个ScrollRect区域。为了优化确保你的Item结构尽量简单并将频繁变化的元素放在独立的子Canvas下但需谨慎子Canvas过多也有开销。更重要的是使用UI合批Batching的最佳实践让相邻的Item使用相同的材质和纹理图集Atlas。GetComponent调用在ProvideData中避免每一帧都通过GetComponent来查找子节点上的组件。应该在Item预制体上挂载一个专用的脚本如ChatMessageItemUI在Awake或Start中缓存所有需要赋值的Text、Image引用。然后在数据源中直接调用这个缓存好的脚本的方法。布局计算Layout对于动态尺寸ItemLayoutRebuilder.ForceRebuildLayoutImmediate是性能杀手。优化方法是限制频率确保一帧内只对最多1-2个新出现的Item进行强制布局计算。使用Content Size Fitter Vertical Layout Group时要格外小心这些组件方便但性能开销大。在超长列表中可以考虑手动计算文本高度并设置rectTransform.sizeDelta而不是依赖自动布局。5.2 交互与体验细节快速滚动时的“白屏”或闪烁这通常是缓冲区BufferZone设置过小或者对象池容量不足导致的。当滚动速度极快时新Item的实例化和数据填充可能跟不上滚动的速度。解决方案适当增大Buffer Factor。在列表初始化时通过PreheatPool方法让对象池提前多实例化一些Item比如多实例化50%。在ProvideData中对于图片等可能异步加载的资源使用占位图等加载完成后再替换避免因等待资源而卡住UI。滚动条Scrollbar的准确性由于我们只渲染了部分Item原生的Scrollbar如果直接绑定到Content的大小上会严重不准。我们需要重写Scrollbar的size和value逻辑使其基于数据总条数和每个Item的预估/实际尺寸来计算而不是基于Content这个实际很短的RectTransform。这需要额外的代码将Scrollbar与我们的LoopScrollRect连接起来。回弹Elasticity与边界处理当滚动到列表顶部或底部时原生的弹性效果依然有效。但我们的循环逻辑需要知道“已经滚到真实边界了”此时不应该再尝试去显示不存在的索引如-1或totalCount。在LoopScrollRect的LateUpdate或滚动值监听中需要加入边界检查防止索引越界。5.3 扩展功能实现Item的多类型支持一个列表里可能有文本消息、图片消息、系统通知等不同样式的Item。这需要扩展对象池使其能管理多种Prefab。我们可以在数据源接口中增加一个GetItemPrefabIndex(int dataIndex)方法根据数据索引返回使用哪种Prefab。对象池则需要对每种Prefab分别维护一个子池。跳转到指定项ScrollTo这是一个非常常见的需求比如点击“回到未读消息”。实现原理就是计算出目标索引Item的起始位置使用前面提到的GetItemPosition方法然后设置Content的anchoredPosition。但要注意平滑滚动可以配合DOTween或UnityEngine.UI.CoroutineTween做一个插值动画。数据选中状态比如一个可选择的邮件列表。选中状态应该保存在数据模型messageList[index].IsSelected中而不是Item的UI上。当Item被回收再复用时在ProvideData方法里要根据当前数据模型的IsSelected值来重新设置UI的选中表现如高亮背景。同时需要在Item的UI脚本上处理点击事件并回调给管理器去更新数据模型和刷新该Item。这套源码的价值不仅在于它解决了性能问题更在于它提供了一套清晰、解耦、可扩展的架构。你可以轻松地将它应用到任何需要展示大量数据的UGUI场景中无论是游戏内的背包、排行榜还是工具软件内的日志查看器、文件列表。它的核心思想——按需渲染、对象复用、数据驱动——也是现代UI开发中的通用高性能解决方案。 
长河君 · 2026/8/9 16:21:52 · 阅读 1.2k Unity UGUI高性能循环滚动列表：原理、实现与优化实践
1. 项目概述为什么我们需要自动循环滚动列表在Unity3D的UGUI开发中但凡涉及到列表展示无论是排行榜、背包系统、聊天记录还是商品橱窗ScrollRect组件都是绕不开的核心。但只要你做过稍微复杂一点的列表比如一个拥有几百条数据的聊天记录一个包含上千个道具的背包你肯定遇到过那个让人头疼的问题性能断崖式下跌。游戏帧率FPS直接从60掉到20以下滑动起来卡顿感明显内存占用也蹭蹭往上涨。这就是原生ScrollRect直接实例化所有列表项Item带来的恶果。所以“自动循环滚动列表”这个轮子几乎是每个稍有经验的Unity UI程序员都会自己造一遍的。它的核心思想非常直观只创建和渲染当前可视区域Viewport内以及少量缓冲区的列表项。当列表项滑出可视区域时我们并不销毁它而是立刻将其回收并移动到即将进入可视区域的位置更新其显示的数据。这样一来无论你的数据源有1万条还是10万条屏幕上实际存在的GameObject可能只有10到20个性能开销被恒定在一个极低的水平。网上能找到的循环列表方案很多但要么耦合度太高难以集成到现有项目要么功能简陋不支持不同尺寸的Item、不处理边缘回弹、或者数据刷新逻辑混乱。今天我要分享的这套C#源码是我在多个上线项目中打磨出来的它不仅仅实现了“循环”更在易用性、扩展性和稳定性上做了大量优化。你拿到手后几乎可以像使用原生ScrollRect一样通过简单的数据绑定就获得一个高性能的无限滚动列表。2. 核心设计思路与架构拆解在动手写代码之前我们必须把设计思路理清楚。一个健壮的循环滚动列表不能只是一个简单的“对象池位置计算”它需要一套清晰的架构来管理状态、处理数据和响应交互。2.1 核心组件职责划分我设计的这个循环列表系统主要由三个核心类构成职责分明耦合度低LoopScrollRect(继承自ScrollRect): 这是主控制器。它接管了原生ScrollRect的滚动逻辑但重写了关键方法。它的核心职责是监听滚动事件onValueChanged。根据滚动位置和方向计算当前哪些数据索引应该被显示。指挥LoopScrollItemPool提供或回收Item。调用ILoopScrollDataSource来为Item填充数据。LoopScrollItemPool(对象池管理器): 负责Item的生命周期管理。它不是一个简单的ListGameObject而是一个智能的缓存系统。预热Preheat: 在列表初始化时根据可视区域大小提前实例化出刚好足够覆盖甚至略多于屏幕的Item避免滚动时突然实例化造成的卡顿。提供Get: 当需要显示一个新索引的Item时池子首先检查是否有已回收未激活的、同类型的Item可用。如果有则复用如果没有则根据预设的Prefab实例化一个新的。回收Recycle: 当Item滑出可视区域并加上一个缓冲距离后将其放回池中设置为未激活状态等待下次复用。这里的关键是判断回收时机的算法要既及时又不至于在快速滚动时出现闪烁。ILoopScrollDataSource(数据源接口): 这是连接你的业务数据和UI展示的桥梁。采用接口设计是为了解耦。你的数据可以来自任何地方——一个ListT一个字典甚至网络请求。你只需要实现这个接口循环列表本身不关心你的数据具体如何存储。int GetItemCount(): 返回数据总条数。void ProvideData(Transform itemTransform, int index): 这是最重要的方法。当某个Item需要显示第index条数据时列表会调用这个方法并把这个Item的Transform传给你。你需要在这个方法里找到Item上的Text、Image等组件并用你的第index条数据去填充它们。2.2 滚动方向与Item尺寸处理循环列表必须完美支持垂直滚动Vertical和水平滚动Horizontal。两者的计算逻辑镜像对称但需要分开处理。垂直滚动: Item的锚点Anchor通常设置为Top-Stretch其位置由anchoredPosition.y决定。我们需要计算每个Item的顶部top和底部bottom在世界空间或本地空间中的位置来判断它是否在Viewport内。水平滚动: Item的锚点通常设置为Left-Stretch其位置由anchoredPosition.x决定。判断依据是Item的左侧left和右侧right。更复杂的情况是**动态尺寸Dynamic Size**的Item。比如聊天列表每条消息的文本长度不同气泡高度也就不同。对于这种需求我们的架构需要支持初始化时计算: 在提供数据后强制立即布局LayoutRebuilder.ForceRebuildLayoutImmediate来获取Item渲染后的实际高度或宽度。缓存尺寸: 将计算出的每个索引的Item尺寸缓存起来避免重复计算。这里可以用一个数组或字典来存储。位置推算: 在滚动时根据缓存的所有Item的尺寸累加计算出任意一个数据索引的Item应该所在的位置。这是循环列表算法中最核心的数学部分。2.3 与原生UGUI的兼容性思考我们继承自ScrollRect因此天然拥有原生的所有特性惯性滚动、弹性回弹Elasticity、滚动条Scrollbar支持。这是一个巨大的优势。我们的任务不是推翻它而是增强它。因此在重写像SetContentAnchoredPosition这样的方法时必须小心处理确保在不破坏原生滚动体验的前提下插入我们的循环逻辑。3. 关键实现细节与源码解析接下来我们深入到代码层面看看几个最关键的实现细节。我会贴出核心代码片段并解释每一行背后的意图。3.1 对象池LoopScrollItemPool的智能回收策略对象池的核心难点不在于“存”和“取”而在于何时回收。回收早了快速滚动时边缘的Item可能会闪一下回收晚了池子里闲置的Item过多失去优化意义。我的策略是引入一个“缓冲区BufferZone”的概念。Viewport的可视区域外上下或左右各预留一段缓冲区。只有当Item完全离开“可视区域缓冲区”后才进行回收。// 这是一个简化的判断逻辑以垂直滚动为例 private bool IsItemBeyondViewport(RectTransform itemRect, float buffer) { // 获取Viewport的边界 float viewportTop viewportRectTransform.rect.yMax; float viewportBottom viewportRectTransform.rect.yMin; // 将Item的边界转换到Viewport的本地空间 Vector3[] itemCorners new Vector3[4]; itemRect.GetWorldCorners(itemCorners); // 这里需要将worldCorners转换到viewport的本地空间简化起见我们理解概念 float itemWorldTop itemCorners[1].y; // 左上角 float itemWorldBottom itemCorners[0].y; // 左下角 // 判断如果Item的底部 (Viewport顶部 缓冲区) 或 Item的顶部 (Viewport底部 - 缓冲区)则回收 bool isBeyondTop itemWorldBottom (viewportTop buffer); bool isBeyondBottom itemWorldTop (viewportBottom - buffer); return isBeyondTop || isBeyondBottom; }实操心得buffer的大小设置很有讲究。我通常设置为1.5到2个Item的高度/宽度。太小了在高速滚动下不保险太大了浪费内存。你可以根据项目实际滚动速度调整这个参数。3.2 数据索引与显示Item的映射管理我们需要一个高效的结构来维护“当前屏幕上显示的是哪几个数据索引以及它们分别对应哪个GameObject”。我使用两个Dictionary来实现双向查找private Dictionaryint, RectTransform m_activeItems new Dictionaryint, RectTransform(); // 索引 - Item private DictionaryRectTransform, int m_itemToIndex new DictionaryRectTransform, int(); // Item - 索引当滚动发生时LoopScrollRect会计算新的索引范围startIndex,endIndex。然后执行一个刷新循环遍历当前m_activeItems将不在新范围[startIndex, endIndex]内的Item回收至对象池并从字典中移除。遍历新范围[startIndex, endIndex]对于当前m_activeItems中不存在的索引向对象池申请一个新的Item。为申请到的新Item以及因为数据变化可能需要刷新的已有Item调用数据源的ProvideData方法并更新两个字典。这个过程必须高效因为它在每一帧滚动时都可能被调用。3.3 动态尺寸Item的位置计算与缓存这是循环列表的“终极挑战”。假设我们支持垂直滚动的动态高度Item。首先我们需要一个数组来缓存每个Item的高度private float[] m_itemSizes; // m_itemSizes[index] 存储第index个Item的高度当数据源变化如新增一条聊天记录或者某个Item的尺寸可能发生变化时我们需要更新缓存。但全量重新计算所有Item的尺寸是灾难性的。因此我采用了惰性计算Lazy Calculation和局部更新的策略。初始化/重置时如果数据总量不大比如小于500可以暴力计算所有。如果很大则只计算前N个足以填满屏幕的尺寸后面的用一个预估的平均高度暂时填充。当滚动到未计算过的索引时再进行实时计算并更新缓存。提供数据时在ProvideData调用后立即强制布局重建然后通过LayoutUtility.GetPreferredHeight或直接读取rectTransform.rect.height来获取实际高度。计算位置要找到第index个Item的起始Y坐标公式为posY sum(m_itemSizes[0] m_itemSizes[1] ... m_itemSizes[index-1])。我们可以维护一个前缀和数组来加速这个计算避免每次滚动都进行O(n)的累加。// 计算内容的总高度并设置Content的sizeDelta.y private void UpdateContentSize() { float totalHeight 0; for(int i 0; i totalCount; i) { totalHeight GetItemSize(i); // GetItemSize会从缓存读取或计算 } content.sizeDelta new Vector2(content.sizeDelta.x, totalHeight); } // 根据索引获取Item的位置 private float GetItemPosition(int index) { float pos 0; for(int i 0; i index; i) { pos GetItemSize(i); } return pos; // 这里假设锚点在顶部所以pos是Item顶部的Y值 }注意动态尺寸的计算和缓存是性能敏感区。一定要做好边界判断避免在滚动过程中频繁触发LayoutRebuilder.ForceRebuildLayoutImmediate这个调用本身是比较耗时的。可以考虑在一帧内只处理一个未计算尺寸的Item。4. 完整集成与使用指南理论说了这么多现在来看看怎么在你的项目里用起来。我会假设你已经有了一个UGUI的ScrollRect基础结构。4.1 第一步创建Item预制体Prefab这和普通列表项制作没有任何区别。比如做一个简单的消息Item在UI下创建一个Image作为背景。在它下面添加Text组件显示消息内容。确保这个GameObject上有LayoutElement组件如果你希望高度自适应或者固定好它的RectTransform尺寸。将这个GameObject做成Prefab比如叫MessageItem.prefab。4.2 第二步实现数据源接口ILoopScrollDataSource在你的游戏逻辑脚本里比如ChatManager实现这个接口。using UnityEngine; public class ChatLoopScrollDataSource : MonoBehaviour, ILoopScrollDataSource { // 你的业务数据 public ListChatMessage messageList new ListChatMessage(); public int GetItemCount() { return messageList.Count; } public void ProvideData(Transform itemTransform, int index) { // 1. 安全校验 if (index 0 || index messageList.Count) { Debug.LogError($Index {index} out of range!); itemTransform.gameObject.SetActive(false); return; } // 2. 获取或添加Item上的逻辑组件推荐 var itemUI itemTransform.GetComponentChatMessageItemUI(); if (itemUI null) { itemUI itemTransform.gameObject.AddComponentChatMessageItemUI(); } // 3. 用数据填充UI组件 ChatMessage msg messageList[index]; itemUI.SetMessage(msg.Content, msg.Sender, msg.Time); // 4. 如果是动态尺寸在这里ItemUI的SetMessage方法内部可能会改变文本长度从而改变Item高度。 // LoopScrollRect会在调用ProvideData后自动处理尺寸更新和位置重排。 } }4.3 第三步配置LoopScrollRect组件在场景中找到你的ScrollRect游戏对象。移除或禁用原生的ScrollRect组件。添加我们编写的LoopScrollRect脚本。在Inspector面板上进行配置Item Prefab: 拖入第一步制作的MessageItem.prefab。Data Source: 拖入第二步创建的ChatLoopScrollDataSource脚本所在的游戏对象。Pool Size: 对象池初始大小。设置为0脚本会根据Viewport大小自动计算一个合理值。Buffer Factor: 前面提到的缓冲区系数比如1.5。Direction: 滚动方向选择Vertical。其他如Movement Type,Elasticity,Inertia等继承自ScrollRect的属性按需设置。4.4 第四步运行时操作列表现在你可以通过操作数据源来驱动列表的更新。// 添加新消息 void OnReceiveNewMessage(string content) { messageList.Add(new ChatMessage(content)); // 通知列表数据总量变了 loopScrollRect.RefreshItemCount(); // 如果你希望列表自动滚动到底部像微信一样 loopScrollRect.SrollToBottom(); } // 清空列表 void OnClearChat() { messageList.Clear(); loopScrollRect.RefreshItemCount(); } // 更新某条消息比如消息状态变为“已读” void UpdateMessageAt(int index) { if(index 0 index messageList.Count) { messageList[index].IsRead true; // 如果该消息当前正在屏幕上显示需要刷新它 loopScrollRect.RefreshItem(index); } }RefreshItemCount()和RefreshItem(int index)是LoopScrollRect暴露的关键方法它们内部会触发重新计算索引范围、回收/申请Item、调用ProvideData等一系列操作。5. 实战中遇到的坑与优化技巧这套方案在多个项目中使用后我积累了一些宝贵的“踩坑”经验。5.1 性能陷阱与优化Canvas的“脏区域”重绘即使我们只更新了少数几个Item的文本UGUI的Canvas在默认情况下也可能重绘整个ScrollRect区域。为了优化确保你的Item结构尽量简单并将频繁变化的元素放在独立的子Canvas下但需谨慎子Canvas过多也有开销。更重要的是使用UI合批Batching的最佳实践让相邻的Item使用相同的材质和纹理图集Atlas。GetComponent调用在ProvideData中避免每一帧都通过GetComponent来查找子节点上的组件。应该在Item预制体上挂载一个专用的脚本如ChatMessageItemUI在Awake或Start中缓存所有需要赋值的Text、Image引用。然后在数据源中直接调用这个缓存好的脚本的方法。布局计算Layout对于动态尺寸ItemLayoutRebuilder.ForceRebuildLayoutImmediate是性能杀手。优化方法是限制频率确保一帧内只对最多1-2个新出现的Item进行强制布局计算。使用Content Size Fitter Vertical Layout Group时要格外小心这些组件方便但性能开销大。在超长列表中可以考虑手动计算文本高度并设置rectTransform.sizeDelta而不是依赖自动布局。5.2 交互与体验细节快速滚动时的“白屏”或闪烁这通常是缓冲区BufferZone设置过小或者对象池容量不足导致的。当滚动速度极快时新Item的实例化和数据填充可能跟不上滚动的速度。解决方案适当增大Buffer Factor。在列表初始化时通过PreheatPool方法让对象池提前多实例化一些Item比如多实例化50%。在ProvideData中对于图片等可能异步加载的资源使用占位图等加载完成后再替换避免因等待资源而卡住UI。滚动条Scrollbar的准确性由于我们只渲染了部分Item原生的Scrollbar如果直接绑定到Content的大小上会严重不准。我们需要重写Scrollbar的size和value逻辑使其基于数据总条数和每个Item的预估/实际尺寸来计算而不是基于Content这个实际很短的RectTransform。这需要额外的代码将Scrollbar与我们的LoopScrollRect连接起来。回弹Elasticity与边界处理当滚动到列表顶部或底部时原生的弹性效果依然有效。但我们的循环逻辑需要知道“已经滚到真实边界了”此时不应该再尝试去显示不存在的索引如-1或totalCount。在LoopScrollRect的LateUpdate或滚动值监听中需要加入边界检查防止索引越界。5.3 扩展功能实现Item的多类型支持一个列表里可能有文本消息、图片消息、系统通知等不同样式的Item。这需要扩展对象池使其能管理多种Prefab。我们可以在数据源接口中增加一个GetItemPrefabIndex(int dataIndex)方法根据数据索引返回使用哪种Prefab。对象池则需要对每种Prefab分别维护一个子池。跳转到指定项ScrollTo这是一个非常常见的需求比如点击“回到未读消息”。实现原理就是计算出目标索引Item的起始位置使用前面提到的GetItemPosition方法然后设置Content的anchoredPosition。但要注意平滑滚动可以配合DOTween或UnityEngine.UI.CoroutineTween做一个插值动画。数据选中状态比如一个可选择的邮件列表。选中状态应该保存在数据模型messageList[index].IsSelected中而不是Item的UI上。当Item被回收再复用时在ProvideData方法里要根据当前数据模型的IsSelected值来重新设置UI的选中表现如高亮背景。同时需要在Item的UI脚本上处理点击事件并回调给管理器去更新数据模型和刷新该Item。这套源码的价值不仅在于它解决了性能问题更在于它提供了一套清晰、解耦、可扩展的架构。你可以轻松地将它应用到任何需要展示大量数据的UGUI场景中无论是游戏内的背包、排行榜还是工具软件内的日志查看器、文件列表。它的核心思想——按需渲染、对象复用、数据驱动——也是现代UI开发中的通用高性能解决方案。