问题：
如果项目中使用了xib来创建视图，并且xib中包含了一些iOS系统中不支持的字体，如图：
那么在低系统版本中，这个视图的加载就会异常缓慢，使用iPhone4S iOS8.1.2测试结果显示单独加载这3个Label就需要大概3秒多钟的时间！但是第二次进入时间正常。
分析：
iOS8
当我们在xib中把字体改为system的时候，加载速度变得正常起来，那么有理由相信是字体导致了整个界面的加载变慢。
使用Time Profiler来验证一下：
发现时间都花在了CoreText的一些底层操作上，猜想就是系统在寻找支持的字体。
把修改字体的过程写在代码里：
- (void)viewDidLoad {
[super viewDidLoad];
self.lblTest.font = [UIFont fontWithName:@"STHeitiSC-Light" size:18];
NSLog(@"%@",_lblTest.font);
// Do any additional setup after loading the view from its nib.
}
此时Time Profiler：
可以看到现在相同的方法，执行效率立马高了很多（因为没花时间找）。
这里是加载字体的主要方法。
iOS9
当换成iOS9系统进行相同Time Profiler时，我试着去找相同加载字体的方法，但是貌似两者的call tree也有较大的不同，是苹果修改了这个字体加载致缓的Bug还是其他原因就不得而知了，总之在iOS9上，对于找不到的字体，系统会很快做出反应。
还有一点比较奇怪的是，我在xib中使用的是STHeitiSC-Light，实际最后加载出来Label的字体却被替换成了另外一种：PingFangSC-Light
我以为是因为字体不存在造成了替换，后来发现就算你的系统下载了STHeitiSC-Light，也会在iOS9中被替换为PingFangSC-Light。
最后看了些资料，最后发现是因为iOS9更新之后对于“黑体”字的改进，苹果推出了自己的黑体：苹方
为了界面统一的关系，估计苹果会把所有的黑体改成自家的苹方字体来以示统一。
但是TMD又奇怪了，如果在代码中规定字体：
- (void)viewDidLoad {
[super viewDidLoad];
self.lblTest.font = [UIFont fontWithName:@"STHeitiSC-Light" size:18];
NSLog(@"%@",_lblTest.font);
// Do any additional setup after loading the view from its nib.
}
输出如下：
所以这个字体到底是什么规律加载的，真的是有点懵逼。
使用xib的call tree：
红框部分为主要加载字体的方法，对比iOS8发现两者的加载方式几乎完全不一样了。
iOS9舍弃了之前那种又臭又长的加载方式，使用新库： libFontParser.dylib来解析字体，提高了速度。
使用代码的call tree：
红框部分为主要的两个字体加载方法。
与iOS8类似，但是仔细观察发现iOS9中也引入了新库: libFontParser.dylib来帮助解析字体。
小结一下：
系统差异：
9使用了libFontParser.dylib，使得加载速度和方式上有了改变，不会造成8上的异常卡顿。
并且libFontParser.dylib在xib和UIFont方法中都发挥了作用，猜测是一个字体加载的统一库。
xib和代码的差异：
两系统下xib方式的加载确实存在很大的差异，光看9下的表现，字体更像是“画”出来的，而8下xib字体的寻找仍然走的是fontWithDescriptor：这样的UIFont方法。
代码方法的话，都走UIFont方法，只不过9使用了libFontParser.dylib
疑惑：
- 1 不管是iOS8还是9，两者使用xib都无法加载到STHeitiSC-Light，虽然两者系统的字体库都支持该字体，并且字体存在。
- 2 iOS9下xib不能加载到STHeitiSC-Light，代码法却仍然生效。
对于以上两个问题，做的分析还不够，自己学的也不多，还不知道原因。
希望有了解的可以多多指教。
字体下载：
苹果开放了字体下载的API，可以对设备支持的字体但又不在本地的字体进行下载，直接上代码：
NSMutableDictionary *fontAttrs = [NSMutableDictionary dictionaryWithObjectsAndKeys:@"STHeitiSC-Light", kCTFontNameAttribute, nil];
CTFontDescriptorRef desc = CTFontDescriptorCreateWithAttributes((__bridge CFDictionaryRef)fontAttrs);
NSMutableArray *descArray = [NSMutableArray new];
[descArray addObject:(__bridge id)desc];
CFRelease(desc);
//封装成一个CF的字体对象
//将对象传入，进行下载
CTFontDescriptorMatchFontDescriptorsWithProgressHandler((__bridge CFArrayRef)descArray, NULL, ^bool(CTFontDescriptorMatchingState state, CFDictionaryRef _Nonnull progressParameter) {
NSDictionary *progressDic = (__bridge NSDictionary *)progressParameter;
NSLog(@"state: %u",state);
NSLog(@"progress: %@",progressDic);
return YES;
});
return YES;
//
注意的一点是：CTFontDescriptorMatchingState，它描述了当前查找字体的“状态”
kCTFontDescriptorMatchingDidBegin, // 开始匹配。
kCTFontDescriptorMatchingDidFinish, // 结束匹配。
kCTFontDescriptorMatchingWillBeginQuerying, // 与服务器连接前会是此状态
kCTFontDescriptorMatchingStalled, // 挂起，等待服务器回调时是此状态
kCTFontDescriptorMatchingWillBeginDownloading, // 将要开始下载
kCTFontDescriptorMatchingDownloading, // 正在下载
kCTFontDescriptorMatchingDidFinishDownloading, // 完成下载
kCTFontDescriptorMatchingDidMatch, // 已经匹配
kCTFontDescriptorMatchingDidFailWithError // 发生错误，可能会多次发生
官方文档：
In iOS 6.0 and later, apps can download on demand available fonts that are not installed using the CTFontDescriptorMatchFontDescriptorsWithProgressHandler
function. Fonts downloaded this way are not installed permanently, and the system may remove them under certain circumstances. Fonts available for downloading are listed in as “Additional Information” in iOS 6: Font list and iOS 7: Font list. DownloadFont (in the iOS Developer Library) demonstrates the download technique. Downloading fonts on demand is unnecessary in OS X because all available fonts are installed with the system.
大致意思就是，以这种方式下载的字体并不是永久保存的，在特定条件下可能会被系统删除，可支持下载的字体可以在
iOS 6: Font list
iOS 7: Font list.
DownloadFont
进行查找。