一个CoreText排版性能问题
来源:互联网 发布:linux已安装软件位置 编辑:程序博客网 时间:2024/05/22 17:38
伊书的阅读器是用CoreText排版的,在中文字体的选择上,自带的字体中只有黑体,后来发现日文字体Hiragino也是可以用于中文,而且显示效果比黑体好很多,于是选用了这个字体。但在CoreText排版中遇到个问题,用Hiragino字体排版速度非常慢,几乎是默认黑体的100倍,以下是用Instrument Time Profiler查看排版同一章内容的时间消耗:
Hiragino:
黑体:
时间都消耗在CTFramesetterCreateWithAttributedString里,CoreText又不开源,看不到内部实现,在TimeProfiler里再继续展开,到最后只能看到时间分别耗在两个TRunGlue::ComputeEndIndex()里,看不出什么头绪。
后来用Instrument Allocation查看APP的内存分配时,发现用Hiragino字体排版生成的CTRun非常多,一章内容有2万多个CTRun。按理说,若一篇文章字体格式全部一样,渲染到frame之前CTRun只会有一个,渲染到frame后一行一个CTRun,怎样都不应该出现这么多CTRun。
再测了用黑体排版生成的CTRun次数,这次符合预期,只有70多个:
可以猜测到用Hiragino字体速度慢就是因为生成了大量的CTRun,那为什么会出现这样的情况?断点进入渲染处,打出其中一行CTLine数据,如下:
发现一些文字自动被转为黑体了。原因是Hiragino只支持部分中文字体,而那些不支持的中文字体就要用黑体代替,又因为一篇文章里会交错出现很多Hiragino支持和不支持的字,于是无法用一个CTRun表示一整段文字,每个交错都用一个新的CTRun,导致CTRun非常多,排版处理逻辑变复杂,耗时变高。
终于找到问题的原因,但如果想用Hiragino字体显示中文,这个问题还是无解的。其实在iOS4.x里是没有这个问题的,估计当时CoreText还没有为字体问题拆分多个CTRun,在5.0才开始这样做。除了使用Hiragino字体会遇到这个问题外,在中英混杂的文字里用英文字体也有这样的问题,因为英文字体不支持中文显示,还是会被拆分成很多个CTRun,用CoreText注重性能的人可以注意下这个问题。
- 一个CoreText排版性能问题
- CoreText基础-排版必修课
- CoreText基础-排版必修课
- CoreText基础-排版必修课
- CoreText基础-排版必修课
- iOS文字排版(CoreText)
- 文本排版之----CoreText
- coretext IOS文字排版
- iOS文字排版(CoreText)
- CoreText文字排版
- CoreText-文字排版
- 基于CoreText的排版引擎
- iOS文字排版(CoreText)那些事儿
- 基于 CoreText 的排版引擎:基础
- 基于 CoreText 的排版引擎:进阶
- 基于 CoreText 的排版引擎:基础
- 基于 CoreText 的排版引擎:进阶
- 基于CoreText的排版引擎:基础
- android JNI utils/Log.h 找不到 解决方法
- SSH开发中解决mysql数据库的乱码问题
- iax联机
- How tomcat works 读书笔记十五 Digester库 上
- 统计每一个字母在一句话中出现的数量
- 一个CoreText排版性能问题
- 轻松学习Ionic (一) 搭建开发环境,并创建工程(2015-10-26更新)
- MySQL案例分享之系统消息
- 计算几何
- 第十三周项目五(1)之统计字符串中(大/小写)字母个数
- Android中Touch事件的处理逻辑
- c语言没有次方符号
- struts标签
- 在搭建mysql-mmm环境时报错