做FGUI列表最烦的不是排版、不是数据而是“顺序”。尤其是做背包、任务列表、消息通知这类需要动态调整展示优先级的界面列表项的层级顺序经常让你在运行时想骂人。明明编辑器里摆得好好的运行起来一刷新就乱套明明只是把某个条目置顶结果整个列表顺序全变了。这篇文章我就把FGUI列表层级顺序这摊事彻底讲透从原理到实操从普通列表到虚拟列表的坑一次性梳理清楚。先说清楚这里讨论的是FairyGUI也就是FGUI里的GList组件不是Unity的UGUI也不是UGUI里的ScrollView。FGUI的列表和UGUI的列表有一个本质区别FGUI的GList下的每个子项它们的显示层级完全由子对象的先后顺序决定后添加的子对象渲染在上层。这个机制理解透了后面所有的操作逻辑就都顺了。1. 搞懂FGUI里的“层级顺序”到底是什么1.1 列表子项的渲染顺序机制FGUI的显示对象体系是一个树状结构GList继承自GComponent它管理着一堆子对象。这些子对象在树里的排列顺序直接决定渲染时的遮挡关系——排在前面的先渲染排在后面的后渲染所以后面的会盖住前面的。这个逻辑和Unity的UGUI有区别。UGUI里你可以通过调整RectTransform的siblingIndex来控制UI元素的互相遮挡关系FGUI也是类似的思路但具体的手感和接口不太一样。FGUI的GList里每个列表项本质上就是一个GObject你可以通过它的parent也就是GList本身来操作它的位置。实际开发中层级顺序出问题通常有两种情况第一种是静态的就是在FGUI编辑器里某个列表项目的显示顺序不对。这个最简单在编辑器里直接拖动列表项的顺序就行。但只适用于那些固定不变的项比如UI里固定的几个按钮位。第二种是动态的也是大家真正头疼的。运行过程中列表里的数据会变项会被创建、被回收、被重新加载这时候顺序全靠代码控制。加上FGUI的虚拟列表机制你以为是“列表项的层级”问题实际上可能是“数据顺序和显示顺序没对齐”的问题。1.2 为什么说顺序就是层级FGUI文档里有个很容易被忽略的细节它没有像UGUI那种显式的“siblingIndex”概念而是通过父子关系中的先后顺序来决定绘制顺序。你管它叫“层级”也好叫“渲染顺序”也好本质都是同样的东西。所以你在编辑器里看到的“列表”里每一项的排列和运行时的最终显示层级是同一维度的概念。换句话说理解FGUI的层级顺序就是要理解“列表项的排列顺序 渲染遮挡顺序”。怎么证明这一点你在FGUI编辑器里把两个有背景色的重叠列表项交换顺序运行起来你会发现遮挡关系确实变了。但这里有个问题——FGUI编辑器中的层级顺序只在“静态编辑状态”有效。一旦进入运行模式尤其当列表使用itemRenderer回调来动态生成对象时运行时的顺序完全由代码和数据驱动。这也是很多同学第一次在FGUI里做列表时踩坑的地方编辑器里顺序调好了运行起来“不认”。提示FGUI列表项的层级本质上就是它在GList子对象集合中的索引。逻辑越靠前索引越小渲染越靠后也就是越容易被后面的遮挡。想让它置顶显示就是把它移到集合的末尾。2. 运行时调整层级顺序的必备API2.1 AddChild与AddChildAt的置顶秘密FGUI里调整子对象层级最常用的方法就是这两个AddChild和AddChildAt。GComponent的AddChild会把对象追加到子对象集合的末尾也就是说它会被渲染在最上层拥有最高的“显示优先级”。这个特性非常关键。如果你希望某个列表项置顶显示最暴力的做法就是重新AddChild一次但其实在FGUI中更规范的写法是直接用AddChild本身因为它已经帮你把对象放到最后一个位置了。举个最简单的Unity FGUI C#例子// 假设list是一个GListitem是list中的一个列表项 GObject item list.GetChildAt(3); // 拿到第4个列表项 list.AddChild(item); // 直接把它追加到末尾实现置顶执行完这一段这个item在显示上就会盖住其他列表项并且它变成了列表的最后一个子对象。此时如果再去访问list.GetChildAt(list.numChildren - 1)拿到的就是这个item。AddChildAt则可以精确指定插入位置// 把item插到第三个位置索引2相当于把它往上提 list.AddChildAt(item, 2);这个接口相当于先移除再插入只是把两步合成了一步而且内部处理了索引边界问题比手动RemoveChild再AddChildAt更安全。2.2 SetChildIndex与ChangeChildOrder的用法除了AddChild系列还经常会用到SetChildIndex。它可以直接修改某个子对象在父容器中的索引位置作用等同于Unity里的SetSiblingIndex。// 把item移动到索引5的位置 list.SetChildIndex(item, 5);要特别注意的是SetChildIndex移动的是“索引位置”不是“相对层级”。如果你想把一个项移到另一个项的前面你得知道对方当前的索引然后基于它来计算。比如把itemA移动到itemB之前需要先知道itemB的索引bIndex然后执行list.SetChildIndex(itemA, bIndex)。还有一个冷门接口叫ChangeChildOrder这是FGUI内部重排子对象时用的通常在你使用排序功能时会被调用。我们自己做业务逻辑时一般不需要直接碰它用SetChildIndex和AddChild就够了。另外FGUI还提供了两个排序相关的快捷方法sortChildren()和sortChildrenBy。前者按子对象的名称排序后者可以传一个比较函数。这两个方法用得好可以解决很多“无序”的烦恼。比如列表项名称是unit_01、unit_02这种带编号的直接调sortChildren()就能让它们按名称顺序重排。注意sortChildren()是全量重排会改变所有子对象的索引如果在列表滚动过程中调用可能会引起视觉跳动。建议只在确定需要整体排序的时候使用比如打开面板初始化时。2.3 移除再添加与直接改索引选哪个很多新手会纠结一个问题调整顺序到底是用“RemoveChild再AddChild”还是用“SetChildIndex”我的建议是能用SetChildIndex就用SetChildIndex。原因有三一是SetChildIndex更快它不会触发移除和添加带来的消息回调。RemoveChild和AddChild会触发onRemove和onAdd事件如果你的列表项监听了这些事件可能会产生无谓的逻辑操作比如重新绑定数据这成本是可观的。二是SetChildIndex不会破坏对象池状态。在FGUI的虚拟列表里对象池是默认开启的直接用RemoveChild再AddChild有可能导致对象被错误地回收到池子里再次使用时要重新经历初始化流程。三是代码可读性更好。别人看你代码一眼就知道你只是打算调整层级而不是真的把对象从列表里移除。所以在实际开发里我很少直接用RemoveChild去动层级除非我确实要把项从列表中移除。3. 别被虚拟列表坑了层级操作和虚拟列表的冲突3.1 虚拟列表只是“假装”有那么多项FGUI项目里大部分列表都是虚拟列表。啥意思就是FGUI不会为列表里的每一个数据项都生成一个显示对象它只在可视区域内创建足够的对象来填充屏幕。滚上去的项会被回收滚下来的项会复用之前回收的对象。这样就算你有十万条数据内存占用和显示的项数量无关。但虚拟列表也意味着一个残酷的事实你拿到的列表项不一定是它对应的那个数据项。你看起来是在对“第50条数据对应的列表项”操作其实你拿到的那个对象可能刚刚还在显示第30条数据只是被FGUI复用到了第50条上。所以如果你直接对虚拟列表里的某个item执行SetChildIndex效果可能一闪而过甚至完全无效。因为一旦列表滚动或刷新FGUI就会根据数据索引把item重新指定到新位置上你之前调的那个层级会被覆盖。3.2 虚拟列表下调整层级必须从数据层下手虚拟列表的正确做法不是改显示对象的层级而是改数据然后让列表整体刷新。FGUI的列表有个属性叫numItems它是列表当前的数据项数量。当你设置它的值时FGUI会自动根据新的数据量创建或回收列表项。如果你修改了列表的数据源比如某个条目置顶你需要重新设置一遍numItems或者手动调用刷新接口让列表重建一遍。这样才能保证显示顺序和你的数据顺序一致。实际操作时一般流程是这样的// 假设listData是我们维护的数据列表ListSomeData // 现在要把第5条数据置顶 SomeData item listData[4]; listData.RemoveAt(4); listData.Insert(0, item); // 数据上重新排序 list.numItems listData.Count; // 刷新列表 list.scrollPane.ScrollToView(0); // 滚动到置顶项如果项目里用的是GList的itemRenderer回调那么数据顺序变了之后FGUI会自动用itemRenderer重新生成或复用项。此时列表项的显示顺序会严格按照listData的顺序来层级自然就对了。这里有个很容易被忽略的细节itemRenderer不是每次都会调用的。当你只刷新numItems但数据条数没变时FGUI可能只是把已有的item对象按顺序重新绑定不会销毁重建。但只要你改了数据顺序显示顺序就会跟着变因为FGUI内部就是按照数据索引和显示对象索引一一对应的关系来渲染的。提示在虚拟列表中千万别试图通过操作“item的层级”来改显示顺序纯属白费劲。老老实实改数据再刷新这才是正道。3.3 什么时候可以用非虚拟列表来避免麻烦不是所有列表都必须虚拟化。如果你的列表项很少比如不超过20个而且不需要频繁滚动直接关闭虚拟化反而更省心。关闭虚拟列表的办法很简单在FGUI编辑器中选中列表组件取消勾选“虚拟列表”选项。或者在代码里设置list.SetVirtual()为false。非虚拟列表下所有的数据项都会有独立的显示对象你可以随意调整它们的层级顺序不用担心对象被回收。缺点是显而易见的非虚拟列表在数据量大时会卡创建几十上百个显示对象不是闹着玩的。所以我的建议是只有显示项数量少且调整层级的需求非常高频时才用非虚拟列表。比如做一个只有10个槽位的技能快捷键栏要支持拖拽换位这类场景用非虚拟列表会舒服得多。如果是背包这种可能有几百个格子的界面老老实实用虚拟列表层级调整从数据层解决。4. 三种典型场景的层级调整实操4.1 场景一通知消息置顶显示最常见的需求游戏中弹出一堆系统通知最新的那条要显示在最上面旧消息往下沉。这种场景通常有两种做法。如果用的是虚拟列表那直接改数据顺序即可// 新的通知 NotificationData newNotice new NotificationData(...); noticeDataList.Insert(0, newNotice); // 插到最前面 noticeList.numItems noticeDataList.Count;如果用的是非虚拟列表数据改了以后也没必要手动改层级直接刷新numItems也会重新按顺序渲染。所以这种方式是最省心的。还有一种取巧的写法是直接调用noticeList.AddChild(newNoticeObj)把新对象追加到末尾。因为没有修改数据所以下一次刷新时FGUI会按数据顺序重新排列你手动AddChild的效果会被覆盖。因此我不推荐这种写法容易让人误以为“层级已经调好了”结果数据一刷就露馅。4.2 场景二拖拽排序后刷新层级做拖拽排序时核心逻辑是要把“拖拽的目标位置”转换成“数据索引的变化”然后再重新排序数据。最常犯的错是在拖拽过程中直接用SetChildIndex去移动列表项导致拖拽结束时数据顺序和显示顺序对不上。正确流程分四步拖拽开始前记录当前拖拽项的数据索引dragIndex。拖拽过程中根据鼠标位置计算目标索引targetIndex同时可以做视觉上的位置提示比如改透明度、加边框。松手时把数据从dragIndex位置移除再插入到targetIndex位置。刷新列表最好配合scrollPane.ScrollToView(targetIndex)让视觉焦点跟随。如果用的是非虚拟列表并且列表项的显示对象不允许被销毁重建那可以不用数据刷新而是手动操作显示对象的索引。但同理拖拽结束后一定要保证数据和显示顺序一致不要各搞各的。下面给一个非虚拟列表拖拽排序的简例便于理解核心思路// 拖拽结束时的处理 private void OnDragEnd(GObject dragObj, int targetIndex) { int fromIndex dragObj.parent.GetChildIndex(dragObj); if (fromIndex targetIndex) return; // 先调整数据 var data dataList[fromIndex]; dataList.RemoveAt(fromIndex); dataList.Insert(targetIndex, data); // 再刷新列表非虚拟列表也建议走数据刷新避免对象层级混乱 myList.numItems dataList.Count; myList.scrollPane.ScrollToView(targetIndex); }4.3 场景三多个列表项“整体置顶”但保持相对顺序有时候不是置顶一个项而是要把一组项整体提上去且它们内部的相对顺序不能乱。比如好友列表里把在线的好友全部排到前面离线好友往后沉。我的实现思路是先把数据排序按“在线状态”分组组内再按原来的顺序排列最后统一刷新列表。var online dataList.FindAll(d d.isOnline); var offline dataList.FindAll(d !d.isOnline); dataList.Clear(); dataList.AddRange(online); dataList.AddRange(offline); friendList.numItems dataList.Count;这段逻辑简单清晰唯一要注意的是排序的稳定性。FindAll天然保持了原顺序所以不用担心在线好友内部顺序被打乱。如果用的是Sort记得比较器里要带上次级条件比如原始索引否则两次排序结果可能不同。FGUI的列表刷新是同步的numItems一改渲染结果立刻生效。所以这种“数据排序 刷新”的模式完全能满足“整体置顶”的需求而且不会出现视觉闪烁。5. 常见问题与避坑技巧实录5.1 常见问题速查表下面这个表是我做FGUI列表以来踩过或者看别人踩过的坑整理出来供大家对照排查。现象根本原因解决办法运行时列表项层级和编辑器里不一样列表用了虚拟化或itemRenderer动态生成了对象编辑器层级不生效改数据顺序后刷新numItems不要依赖编辑器静态顺序手动SetChildIndex后滑动列表又乱序虚拟列表复用了对象显示顺序由数据索引决定在虚拟列表里改数据而非改对象层级置顶操作只生效一瞬间数据顺序没改被下一次刷新覆盖数据层同步调整顺序再设置list.numItems非虚拟列表里AddChild后滚动就崩溃AddChild打破了对象池和索引的关联避免操作虚拟列表子对象非虚拟列表也尽量用数据刷新列表重新赋值numItems后滚动位置飘了刷新时没有保持滚动位置先记录scrollPane的当前位置刷新后再ScrollToView恢复排序后列表项闪烁itemRenderer里创建了过多的临时对象或逻辑耗时优化itemRenderer减少重复创建和耗时的UI操作5.2 避坑经验一操作GList之前先确认它是不是虚拟列表我见过太多人把虚拟列表当普通列表用结果调试半天发现是虚拟化机制在捣鬼。这里有个简单的判断方法GList的virtualItemCount如果大于0说明这个列表是虚拟化的。也可以在编辑器里看选中列表组件右侧属性面板中“虚拟列表”是勾选状态那就实锤了。代码里也可以用list.isVirtual属性来判断if (list.isVirtual) { // 虚拟列表走数据刷新路线 } else { // 普通列表可以操作子对象层级 }好习惯是不管是不是虚拟列表做层级调整都先想想能不能通过数据驱动实现。数据驱动的好处是UI的表现永远和数据保持一致排查问题时心智负担小得多。5.3 避坑经验二itemRenderer里不要做“重量级”操作列表项刷新的频次远超你想象。滚动一下就可能触发N次itemRenderer调用如果你在里面做了大量的UI创建、数据解析、图片加载卡顿是必然的。我踩过的一个坑是在itemRenderer里动态获取列表项的子对象然后用SetChildIndex调整顺序。表面上看着没毛病但FGUI的流程是“先调用itemRenderer绑定数据再统一布局”你在itemRenderer里改顺序等于在和FGUI内部的排序逻辑打架。结果就是顺序错乱时好时坏。正确的做法是itemRenderer只负责“根据数据刷新当前项的内容”层级顺序由FGUI自身的索引机制管理最多在数据里加个排序字段让数据顺序本身正确。5.4 避坑经验三注意FGUI的“回收”机制FGUI的对象池回收有一个细节列表项对象被回收后它并不会立刻从显示树中移除而是进入一个“隐藏并等待复用”的状态。如果你在列表滚动前对某个item做了层级调整滚动后这个item被回收再被复用时它的层级索引可能会重置。所以如果你想在某个时刻保证特定列表项的层级固定最稳妥的方法是把列表暂停滚动或者关闭虚拟化。比如做一个“抽奖动画”时奖品列表在动画播放中不应滚动。你可以临时把scrollPane.touchable设为false防止玩家滚动等动画播完再恢复。5.5 避坑经验四刷新列表时尽量保持滚动位置列表刷新后滚动条跳到顶部是最常见的体验问题。虚拟列表的刷新尤其麻烦因为FGUI复用对象后滚动位置会失效。解决办法float prevPos list.scrollPane.posY; // 记录当前位置垂直滚动 list.numItems dataList.Count; list.scrollPane.posY prevPos; // 恢复位置这里要注意posY是滚动位置的百分比还是像素值取决于FGUI的版本。在新版本FGUI比如2022.2.7之后中posY指的是像素值。如果是老版本可能要换算。直接用posY设置也行但前提是同一套坐标系。还有一个小技巧如果列表项高度是固定的可以在刷新前算出当前第一个可见项的数据索引刷新后直接ScrollToView到该索引这样也能大差不差地复位。5.6 避坑经验五拖拽排序中别用AddChild做层级提示有的同学做拖拽占位时喜欢把被拖拽的项临时AddChild到列表最后让它盖住其他项视觉上“浮起来”。这个思路本身没错但一定要记得在拖拽结束时把它的顺序“还回去”。更稳的做法是改变被拖拽项的scale或alpha让它视觉上变大变亮或者给列表整体加一个遮罩而不是去动它的层级。这样不会影响FGUI对列表项索引的管理拖拽结束也不用额外恢复顺序。如果你一定想用层级来做拖拽浮起效果建议仅在非虚拟列表下使用并且拖拽结束时主动把item恢复到原索引位置再做数据排序和刷新。6. 经验总结先有秩序再有顺序做FGUI列表的层级调整我的核心心得就一句话顺序的根源是数据不是对象。你可能觉得这句话是废话但真正遇到问题的人往往就是把因果关系搞反了——以为把显示对象位置挪一挪数据就自动对齐了。FGUI的GList是数据和显示对象严格的“一一对应”关系不管你是否开启虚拟化它最终都会按数据索引去渲染列表项。你手动改层级只能维持极短暂的状态一旦列表刷新、滚动或数据变化顺序就会重新被数据决定。与其费劲和框架对着干不如顺着它的设计来——数据排好序界面自然就排好序。尤其是在虚拟列表场景下我强烈建议把“层级顺序调整”等同于“数据顺序调整”在业务逻辑层就把顺序改对了然后刷新列表。这样既能避免对象池的坑又能保证代码逻辑清晰排查问题时也能快速定位是数据的问题还是渲染的问题。最后分享个小技巧当你的列表项需要频繁调整顺序时可以考虑给数据模型加一个sortIndex字段需要调整顺序时只修改这个字段再对数据列表做稳定排序。这样你的列表逻辑永远不会因为“哪个对象该在哪个位置”而陷入混乱你只需要维护一个数字剩下的事情交给FGUI。这个套路我在多个项目里用过稳定可靠推荐一试。