图7 OpenUDID部分源码
这段代码是从开源代码库OpenUDID中直接私有化出来的一份代码，并维持了原有OpenUDID的逻辑。它在主线程中通过for循环100次来尝试获取标识从org.OpenUDID.slot.0到 org.OpenUDID.slot.99的UIPasteboard对象，并从每个获取到的剪贴板对象中获取OpenUDID的值，并保存起来。按照OpenUDID的逻辑，从100个剪贴板里取出的OpenUDID值可能会有不同，但是它最终回取出现次数最多的一个OpenUDID值作为最终的OpenUDID结果。
如此频繁地调用UIPasteboard的接口去获取对象会阻塞主线程吗？验证一下。
验证主线程调用UIPasteboard的影响
首先写一个循环来测试UIPasteboard的API的耗时情况
图8 主线程UIPasteboard测试代码
循环创建100个UIPasteboard对象，并为向每个UIPasteboard对象都存入100个字符串。并打印对每个UIPasteboard对象的操作时间，执行上述代码后，结果如下：
图9 主线程UIPasteboard测试代码执行输出结果
从打印结果可以看出，获取并对UIPasteboard进行操作的确是一个比较耗时的操作。按此结果100次循环需要50秒，这样的话App肯定是启动不了的。
但这是测试Demo的极端耗时操作，而OpenUDID对于剪贴板的频繁操作仅仅是尝试获取剪贴板对象，这个操作的耗时不至于卡死App，所以此时单看主线程的堆栈信息不能说明什么问题。需要再看其他线程堆栈。
子线程调用栈分析
图10崩溃子线程堆栈信息一
