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.
You may also want to experiment with
UIFont
rather thanCTFont
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.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.