官方：好收到 。
卡是常态 不卡才是意外
解决办法：不用富文本或者少用
2赞
能解决早就解决了！！！
不止富文本，label也卡到怀疑人生
1赞
在浏览器试了下富文本加载要比label 多了将近10倍的时间
先关注一下
对于此问题，给出一个优化建议。
- 建议使用 /n 换行符替换自动换行
- 等 3.6.0 正式版发布后，升级使用 3.6.0 正式版引擎。
经过小规模测试，使用最新社区版打包，在 android 平台下，release 包有 33% 左右的提升，在 ios 平台下，release 包有 25% 左右的提升。
所以你们自动换行存在的意义是什么？
富文本性能很差
确实挺差的，一直这种基础组件不舍得时间去优化。总是迈步搞其他
1赞
说明他们的计算换行算法比你用/n差得多
其实有一点我搞不明白 只要页面上有多一些label 就卡爆了 然后我们浏览别人网页的时候上面全部是label 非常流畅 这是为什么呢？
富文本本质创建label。另外多了一些计算。别人的label并不是你看到的label。也有可能是图片。也有可能缓存模式等做了许多处理。合图等等。char模式等。做了许多优化，才是你看到的
问题就是别人的就是不卡啊 用户才不会管你是不是你看到的label 只要卡就会觉得不好
1赞
花时间，少抱怨
Label / Sprite 这类元素较多的时候, 传统组件模式的缺陷就显露无疑: 每个节点都要去 walk 一次, 每个节点都要单独创建渲染数据. 即使它们都挨在一起.
以至于当界面上有上千个 Label / Sprite 的时候, 就不得不自己写 assembler, 否则性能根本吃不消.
就 2D 而言, 我一直觉得 Laya 1.x 做得更好, 它的各种渲染节点都基于中间层 Graphics 命令流, 不管 Label 还是 Sprite 实际上内部就 g.drawXxx() 而已. 这种机制下, 再复杂的富文本也就一个 Node 包含一堆命令流而已.
而 cc 这个富文本就有点尴尬了, 缺少一个介于 assembler 和 Label 之间的轻量且易用的文本实现, 直接用大量 Label 和 Sprite, 因而效率非常低下.
加黑的部分我十分认同，有时候想获得某段文本的宽度，还必须得先用Label赋值，然后再获取label的宽度才能得到，太二了
一直存在的问题,没对比就没伤害,别人的就是不卡,
1赞
真希望这个问题能解决， 从2.x， label 简直是噩梦， 原生机器都不敢使用太多label， 卡爆炸。。。网页反而流畅不少
1赞
官方现在追求高大上的功能呢,这样才能吸引人用,吸引投资,这种基础的性能优化,只能靠插件大佬和自己了~