上面不是说了吗？修改zIndex本来就是更新渲染次序跟事件排序次序的，你不需要排序的时候不要修改zIndex，在你上层逻辑里面更新记录，最终需要排序的时候统一设置节点的zIndex就好了呀。
自己解决了，密钥密码和别名密码取一样就好了
主程同学，我从1.10的项目上升级上来，drawcall从原来的100左右升到了180左右，请问是正常吗？
游戏里有很多战斗用的音效，本身就已经让包体变大了，如果2倍速，4倍速都要多做一份这个倍速的音效，那包体得增大多少倍？而且也不能让正在播放的音效变成其他倍速的音效啊
看起来使用的还是竖屏的宽高，检查下有没有设置横屏成功呢。
也可能是设置横屏的时机不对，应该是在注册转屏监听之后
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(statusBarOrientationChanged:)
name:UIApplicationDidChangeStatusBarOrientationNotification object:nil];
RichText不能够下对齐，所有内容会上下居中。导致大字体比常规字体下探。
正确图片
错误图片
material设置自定义属性报错,直接修改.mtl文件的_props能正常工作,应该是编辑器的锅
感谢反馈，不太正常，2.0，2.1 , 2.2，渲染流程都做了很多改动，不太好确定是由什么导致的。请问你的场景是什么样的构成，某种组件很多么
感谢你的反馈，请问下是什么材质，是你自己写的effect么？什么情况下设置会出现这个问题呢？自定义的什么属性？，普通的材质的话我这边复现不出来
感谢反馈，在zIndex中确实还有可优化的空间，我们会持续优化的。但是你说的这个需求其实是没有必要的，[quote=“yoline, post:138, topic:85555”]
2.平常给100个child改 zindex 是 zindex = xxx 这样的写法。但如果可以给一个别的变量，就像引擎中的_localZOrder可以让开发者直接操作，这样就可以100个child localZOrder = xxx,这样写就不会触发帧结束sortAllChildren了，可以更自由的批量修改child的zindex，然后修改完之后，手动调用sortAllChildren，来让批量修改的localZOrder生效，这样性能就很容易提高了
[/quote]
如果你需要达到这样的目的，换句话说这个变量其实就起到了一个缓存的作用。既然单单只是一个缓存的作用，引擎没有必要增加一个新的变量，你在自己的组件中用变量缓存就ok了。等全部计算好之后，再一次性设置好所有的zIndex就行了
1赞
确认了一下，目前确实只支持水平对齐，不支持垂直对齐，抱歉。你应该可以通过手动调整模拟下这个效果
这种畸形的需求是因为引擎没有达到性能期盼，而对于在线项目又无法热更引擎改动。算啦，你们知道这个问题就行了，也没办法等你们解决zindex性能低的问题，不想再来一次强迫玩家集体升级2.2，然后集体趴窝的悲剧
引擎组只是建议哦，从没强迫过，你说这话就不厚道了[quote=“yoline, post:163, topic:85555, full:true”]
这种畸形的需求是因为引擎没有达到性能期盼，而对于在线项目又无法热更引擎改动。算啦，你们知道这个问题就行了，也没办法等你们解决zindex性能低的问题，不想再来一次强迫玩家集体升级2.2，然后集体趴窝的悲剧
[/quote]
zindex性能有毛病就是有毛病，不是你觉不觉得空间的问题，显得我跟这跟多为难你似的，2.2发布的时候zindex的性能你们就压根没测试，害得我好长时间来排查问题，结果居然还是1.9.3的老毛病，zindex性能低
一千来个子节点排个序这哪是需要空间不空间的问题，哪个引擎都应该很简单的满足千来个节点的排序问题，一定要把话说脸上才明白咋回事
不是厚不厚道，对2.2也是很期待的，有问题也可以理解，写代码快十年了啥觉悟都有，而是2.2你们没有经过严格的性能测试，都没想到会是一个已经优化完的部分再次出问题，还是owen协助测试才发现根本原因是zindex
老实说，
就算是收费引擎，运营项目也不敢说拿来就升，
最起麻的性能、稳定性还是要跑到心里有谱。
我们的项目还没正式推的，升2.2.0测试到现在才敢准备发。。。
太急了不好
大家都是写代码的，
谁也不敢保证没bugs，也不敢保证不踩老坑。。
我等创建节点的性能优化好了再升级
也是个巧合，独立开发者没有资金聘人员来做性能测试，而ccc独立开发者相较其他引擎多不少，而我一个人来做运营开发和客服等等，也就经常顾不上一些严谨操作，这样的情况升了版本发现性能有点问题，在公司也不会出现这种问题