使用sort对节点进行排序在原生不奏效

原来如此,大佬威武,不过我已经用2.x开始项目了,直接改zindex就好了

在web生效的

下面的可以,sort不行

试过了,不行

被弃用原因

2赞

巧的是,昨天是deadline,使用的是UITransform的priority进行排序,结果原生不生效,最后在父节点统一重新排序,逐个进行setSiblingIndex最后成功。

不生效的问题是因为原生用的children和js用的children不是同一个对象,需要额外操作接口同步一次

不是吧那意思是一套代码不通用??

一开始是通用的,直接口号: 抹平平台差异,一套代码发布多平台,后来开始原生化后,这个口号就是个笑话,
同为开发者,我个人认为不可能完全抹平差异,但是至少在有差异的接口给点提示吧
原生化后还有很多坑等着踩呢

你可以先调用 children.sort(…) 排序,然后判断 if (sys.isNative) 用排序后的 children 循环调用 child.setSiblingIndex(index)

忘了说,web环境下 最好再调用一次 parent._updateSiblingIndex()

你这个回答和我上面的图非常贴切,只从开发者角度考虑问题,而没想过用户做一个通过y坐标改变渲染顺序的游戏以及用户做一些窗口层级管理的都要去重新实现以前的 zIndex 功能

如果所有接口都照这样搞迟早要完

说再多你不如看看这个

这个帖子里面的代表的是功能… 作为一个开发者应该都能理解吧

从投票就能看出来大家更喜欢 zindex(priority) 而不是 setSiblingIndex

…我不知道该不该吐槽你的理解能力,就是因为两个接口功能不一致,引擎现在还废除了 priority,导致大家只能用 setSiblingIndex 来实现 priority 的功能,这样说你明白了吧?

而且在我眼里,priority 和以前的 zIndex 功能都是一样的,大家并不在乎它叫什么名字,只是要它的功能

你论坛里面一搜,保证有人问你这个问题,我之前还回复过

而且废除了 priority 还让我们用 setSiblingIndex 代替,两个接口的功能不一致,大家还更喜欢 priority 的功能,为什么要废除呢?我倒是想问问

你的脑回路我理解不通,你说的都是无关的,我已经说过了是功能不同,而不是你说的命名,接口

至于有什么不同,我引用楼上的回答,你还有什么疑问?

回家了,正好用电脑回复你,

前提

不改引擎,不封装工具函数

场景1:横版游戏(DNF)

  • 用一句代码实现渲染层级的正确变更?
    答案:

    priority

    this.node.getComponent(cc.UITransform)!.priority = node.position.y
    

    setSiblingIndex

    请回答?

场景2:UI 渲染层级管理

  • 如果有 A(内容)B(弹窗), C(提示)三个预制体,实例化这三个预制体(同一父节点),必须保证提示在弹窗上展示,弹窗在内容上展示,怎么一句代码实现?

    答案:

    priority

    // 内容 0-99,弹窗 100-199,提示 200-299
    this.node.getComponent(cc.UITransform)!.priority = 对应类型范围
    

    setSiblingIndex

    请回答?

我还是这张图

1赞

来回答一下?老哥? 别静音

从你上面一条发言就知道,搞了半天原来你是一个连 priority 和 siblingIndex 区别都不知道的小菜鸡,还搁这儿装呢,:joy: