涨姿势了
3赞
牛批…
2赞
大佬牛逼upupup
1赞
大佬，在你的demo中发现一个问题，就是当节点数从295到296，dc就会直接从8到601，然后再增加节点数，都是600往上走了，
2赞
还有一个思路就是定义一个 item_list组件，支持设置各个层级，定义add_item方法，添加时把item不同部位放入指定的层级，item自己有个组件，对各个部位设置层级用。这样子节点预设和列表预设都不需要改，也起到了改变渲染顺序的效果，虽然不是直接修改渲染顺序。这样避免修改源码，native自然也可以兼容。
2赞
层级结构不变，不同层级设置不同 group。然后直接用多个 camera，每个 camera 渲染不同的 group，不能实现你们要的合批效果吗？
3赞
这样不能通用，而且一个UI节点不至于要多个摄像机哟。而且这个UI不一定永远在顶层呢。。
没用过group，我试一试
1赞
这样做如果父节点位置、透明度变化了，是不是同步修改不同层级的node？
2赞
多谢反馈，我测一测
1赞
是的，而且这样的代码写一次就一劳永逸了
每个批次渲染有容量限制，需要额外处理一下。
1赞
除此之外，还有个优化点。滑动列表超出view的aabb包围盒的item，可以不提交渲染命令（比如opacity设为0之类的）。这样 的话，864728298用户提出的合批断掉的问题（也就是一个批次容量超出的问题），就不复存在了
1赞
1赞
情况还蛮多的，还有anchor变化、删除，这些都要同步，如果我直接对着原父节点操作，其他层的节点如何感知到？需要自己封装操作节点的入口吗？
1赞
好吧，那这个就不方便喽
这个方案我也是做到一半发现native不好处理，现在项目里用的是跟你类似的方法，实际情况没有这么复杂，我只在代码里同步位移和删除操作
。不过不是很通用就是了。
1赞
深度优先换广度优先，会破坏遮挡关系，慎用
比如按原本逻辑，一个同级节点的所有子节点会先渲染（置于底层），用你的方案会导致这个节点的子节点后渲染（置于顶层）
遮挡关系破坏以后，事件分发顺序也要改，明显造成的问题更多
除非渲染树一开始就按广度优先设计，然而这有不符合直观逻辑，一个节点的所有子节点按直观应当被当做整体处理，也就是遍历父节点的过程会遍历所有子节点，这个只有深度优先符合
1赞
引擎组：“年轻人，你们考虑过的优化，我们都考虑过了，现在是最佳方案了 [抽烟]”
4赞
是的，会影响遮挡关系。所有子节点会永远处于所有父节点上。