请问RichText组件的性能问题有优化计划吗？
好的，感谢。我目前就用as编译吧····
2.3版本richtext加入了label的缓存模式
用2.2打包安卓时，发现main.js吧热更目录添加到搜索路径的那几句代码删了，导致热更内容不生效。
不知道2.3是否依然存在此问题。
···
if (cc && cc.sys.isNative) {
let hotUpdateSearchPaths = cc.sys.localStorage.getItem(‘HotUpdateSearchPaths’);
if (hotUpdateSearchPaths) {
jsb.fileUtils.setSearchPaths(JSON.parse(hotUpdateSearchPaths));
console.log(’[main.js] 热更新SearchPath: ’ + JSON.parse(hotUpdateSearchPaths));
}
}
// 这是为了解决一个重启的 bug 而添加的
cc.director.startAnimation();
···
这个缓存模式，满足不了大量非重复富文本的需求（比如文字挂机类游戏），原因在于每次设置string耗时时间过长，文字越多耗时越长，甚至一段仅有几个字但是有较多换行的文本也是如此；奇怪的是，同样的文本内容，1.x版本耗时大概只是2.x版本的1/4甚至更少。
了解，我们还会持续进行优化，你说的慢是在原生平台还是在web平台？我们测试看下问题，缓存模式主要解决的是批次的问题。
lable这个东西着实令人头疼
testScript.zip (908.8 KB)
麻烦看下这个测试工程 编辑器内没问题。web运行出错。一个本应该被导出的量，没有导出引起的（2.2.2版本之前都是可以的，就2.3.0-rc1不行）
[ERROR] Failed to invoke JavaScriptJavaBridge_callStaticMethod, location: D:/cocos/CocosCreator2.2.2/resources/cocos2d-x/cocos/scripting/js-bindings/manual/JavaScriptJavaBridge.cpp:604
建议打印这句话的时候把调用的函数名字打印出来。现在只知道有个函数参数错了，不知道是哪个
好的，谢谢
请问3D粒子有使用文档了么？
跟了去github好像直接是Creator3D的文档？
我想提前了解下3D粒子的能力、看下怎么在2D里使用3D粒子系统。
看表现你这 v_uv0.x 浏览器上的值不是 0 - 1 吧，检查下传入的 v_uv0 的值怎么算的
3D 粒子是从 Creator 3D 迁移过来的，模块是一样的，可以先看Creator 3D关于粒子的文档，我们之后再优化一下文档
全平台都是如此。渲染压力倒是其次（虽然一个RichText设置一段文本后可能会达到几十个DrawCall），这个可以通过缓存模式进行一定的缓解，问题应该是在RichText组件的具体实现上。比如CCRichText.js中对于定宽换行的处理函数_updateRichTextWithMaxWidth就有很大的性能问题：_measureText函数本身就已经比较费时，然后在一个while里大量调用_measureText计算宽度直至达到限制的行宽，这个耗时肯定很大。更恐怖的是对于根据格式切分出来的每一段文本的每一行都有可能要进行这个处理，这个累加起来太致命了
请问你有什么好的建议或思路么，这个一直是我们label上的性能热点，一直没有好的解决方案
顶多编辑器里面设置的好直接走配置，别实时计算了，动态赋值这好像也没啥好的处理方案吧
发现一个小Bug 在编辑器内新建一个场景，不执行保存场景的操作下，这个场景的 json里的uuid是一个默认的 uuid 但是右键显示这个场景的uuid是正确的，执行保存场景操作后场景 json内的uuid才被刷新成正确的uuid
这会有什么问题么
RichText的measureText消耗是必定的，
不算又怎么能实时调整内容呢。。。。
我们聊天栏的优化也就是分帧计算出每行的meta（记录行高、行宽、可直接用于创建Label或Image的文本fragment列表），
结合视图裁剪及Label复用，
才将性能消耗降低到可接受的程度。