使用UBOGlobal的话，属于使用legacy-pipeline：
可以在PipelineSceneData.h中添加C++的getter/setter，并在cocos-engine/native/tools/swig-config/pipeline.i中注册PipelineSceneData的getter/setter。
之后重新编译引擎，在game.ts可以通过cclegacy.director.root.pipeline.pipelineSceneData获取到PipelineSceneData，并调用setter设置数据。
随后在updateGlobalUBOView通过pipeline找到PipelineSceneData，调用getter获取数据并设置。
如果是需要后处理，推荐使用新的自定义渲染管线，能比较容易的添加shader参数。
可以参考cocos-engine/editor/assets/builtin-pipeline.ts
收到，感谢感谢~
ok,好的
快发版了吧
ok，晚一些我提交一下
麻烦处理下这里，一帧处理不完的函数直接放到尾部这种操作，需要考虑下顺序吧，比如同一时间WebSocket发来的消息过多一帧处理不完，处理过程中再有消息过来，下一帧会处理后发过来的消息，搞出很多莫名其妙的问题
请问下，你的383不是从dashboard下载，而是从论坛下载的？
是dashboard下载的
我这边目前有个bug，android 端websocket 会出现数据解析错误的情况，是因为这个引起的么？web端不会出现这种情况
web不会有问题，原生才有，只是处理顺序错误，解析出错应该不会
我这边用381,383，调用view.setDesignXX， 通过view.on也是监听不到 canvas-resize的。
是ios 手机没错吧
有可复现的demo吗，目前您这边是确认这个引起的？理论上这个并不会改变回调的顺序
没有复现的，肯定会改变，现在是把回调缓存了，然后_functionsToPerform的锁就解开了，如果在处理这些回调的过程中，_functionsToPerform又有插入回调，并且超过16ms没处理完这一帧的回调，就会再把剩下没处理的回调再放到 _functionsToPerform后面，我这么说不知道能理解不
那你屏蔽那个的处理，就没再出现websocket的问题了？
我临时处理是把剩下的消息放到_functionsToPerform头部，能解决顺序错误的问题，但是vector头部插入性能相对低一些
收到，感谢反馈，我们这边会在下个测试版本修复
感谢指出此问题，之前的确漏考虑了顺序。已经在此 PR 中修复：
并添加了对应单元测试例。github ci 会对每次提交的 PR 做验证。
网页就能复现的，或许不是因为canvas-resize这个消息，下次我完整流程跟踪一下再汇报一次，383主要是调用view.setDesignXX这个之后不用再发canvas-resize 就能很好适配了，384不行，必须要手动触发
在场景中创建一个按钮并绑定点击事件，再创建一个节点，让这个节点全屏遮住按钮，并监听点触摸事件，在回调函数中设置event.preventSwallow = true 按钮上的点击事件不会被触发。这个问题有办法解决吗?
