使用自定义字体显示 NSAttributed 字符串需要更多时间

本文介绍了使用自定义字体显示 NSAttributed 字符串需要更多时间的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我正在使用 Core Text 以列方式显示 NSAttributed 字符串.它工作正常.使用系统字体时，无论是在模拟器还是在设备上都没有延迟地显示但是当使用自定义字体时，需要更多的时间来显示设备中的内容.但在模拟器中，结果很快.

I am displaying NSAttributed string column wise using Core Text. It is working fine. When using system font, it is displayed without any delay both in simulator and device. But when using custom font, more time is taken to display the content in device. But in the simulator, the result is quick.

- (void)updateAttributedString { // Existing Code if (self.text != nil) { self.attributedString = [[NSMutableAttributedString alloc] initWithString:self.text]; NSRange range = NSMakeRange(0, [self.text length]); // Regarding Fixed font // [ self.attributedString addAttribute:NSFontAttributeName value:[UIFont fontWithName:@"TAUN_Elango_Abirami" size:20] range:range];//This is my custom font // Regarding custom Font using below code if (self.font != nil) { CTFontRef font = [self createCTFont]; [self.attributedString addAttribute:(NSString *)kCTFontAttributeName value:(__bridge id)font range:range]; CFRelease(font); } } } - (CTFontRef)createCTFont; { CTFontRef font = CTFontCreateWithName((CFStringRef)self.fontName, self.pointSize, NULL); return font; }

如果我添加以下代码行，

If I add the following line of code,

[self.attributedString addAttribute:(NSString *)kCTFontAttributeName value:(__bridge id)font range:range];

在设备中显示属性字符串很慢.但是，在模拟器中它很快.如果我不添加那段代码，文本会在模拟器和设备中快速显示.

displaying the attributed string is slow in device. But, in simulator it is quick. If I don't add that piece of code, the text is displayed quickly in both simulator and device.

推荐答案

一次性创建您的字体对象并保留它.如果您有多个并且需要跨对象共享，我可能会将它们缓存在静态字典中.不要每次更新字符串时都创建一个新字符串.字体对象几乎肯定会在第一次需要它时(而不是您创建它时)完成所有复杂的解码工作.系统字体总是被加载和解码，但如果没有引用它们，自定义字体可能不会保留.

Create your font object one time and hold onto it. I'd probably cache them in a static dictionary if you have multiple and need to share across objects. Don't create a new one every time you update the string. The font object is almost certainly doing all its complicated decoding work at the point that it's first needed (not the point that you create it). System fonts are always loaded and decoded, but custom fonts likely aren't kept around if nothing is referencing them.

您可能还想在这里试验 UIFont 而不是 CTFont.UIFont 是一个更高级别的对象，我的经验是它缓存更多.我还没有探索过这种特殊情况.一般来说，除非你真的需要 Core Text，否则你通常应该使用 UIKit 类型.这可能是违反直觉的，因为不是更低的级别更快吗?"好吧，如果您确切地知道自己在做什么，较低级别的可以更快.但真正较低的水平只是意味着你必须自己照顾更多的东西".信任 UIKit 通常是更好的一阶解决方案，直到您知道自己需要更细粒度的东西.

You may also want to experiment with UIFont rather than CTFont here. UIFont is a higher-level object, and my experience with it is that it caches more. I haven't explored this particular situation. In general, you should generally use UIKit types unless you really need Core Text. This can be counter-intuitive, since "isn't lower level faster?" Well, lower level can be faster, if you know exactly what you're doing. But really lower level just means "you have to take care of more stuff yourself." Trusting UIKit is usually the better first-order solution until you know you need something more fine-grained.

模拟器会更快也就不足为奇了.这是在 Mac 上运行的，它的处理能力和磁盘速度比 iPhone 快得多.当您在模拟器上运行时，它们实际上只是在特殊 UI 中运行的 Mac 应用程序；它不像 Android 使用的那样是一个完整的模拟器.

It is not surprising that the simulator would be faster. That's running on a Mac which has dramatically more processing power and a much faster disk than an iPhone. When you run things on the simulator, they're actually just Mac apps that run in a special UI; it's not a full emulator like Android uses.