我想看看在Xcode 7中编译iOS版本7-8-9的应用程序需要多长时间才能执行。
看到了这个问题，获取经过的时间(Objective-c)。答案警告不要依赖NSDate来获得如此短暂的时间。相反，这个答案建议:
CFTimeInterval startTime = CACurrentMediaTime();
// perform some action
CFTimeInterval elapsedTime = CACurrentMediaTime() - startTime;
即使导入了#import <QuartzCore/QuartzCore.h>，这段代码也无法编译。报告链接器失败:
架构armv7:
未定义符号_caccurrentmediatime "，引用自:
有没有其他的方法来跟踪毫秒或纳秒的短暂时刻?
请不要对导致微基准测试不可靠的固有的变幻性进行警告。我只是想大致了解一下时间。
也许Objective-C或Swift有类似JMH的东西，JMH是Java微基准测试工具，用于构建、运行和分析用Java和其他语言编写的针对Java虚拟机的纳米/微/毫/宏基准测试。
NSDate
其他人警告说，NSDate在用于微基准测试时可能会有点抖动。但对于日常使用，它可以正常工作。
NSDate *start = [NSDate date];
// …
NSTimeInterval timeInterval = [start timeIntervalSinceNow];
NSLog(@"elapsedTime after Check call: %f" , timeInterval );
可能有更好的方法，但这确实有效。例如，我对iPod touch第5代的方法调用进行计时，在几次运行中，它始终花费0.21到0.25秒。在几次测试中，切换到iPad Air同样的方法持续花费0.11到0.13秒。当然，这两种设备上的差异约为10-20%。但是随便观察一下，这就可以满足你的需要了。只是要确保多次运行您的测试。
使用接收代码运行的示例
示例运行，执行一些代码，这些代码利用由Receigen Mac应用程序生成的源代码进行应用收据验证。NSDate似乎可以很好地跟踪微秒。
我不包括源代码，但您可以通过对事件顺序的描述获得主要思想。
- 定义并填充一个代码块。不执行业务逻辑，只是创建Objective-C块(闭包)。
- 实例化了我的
SKRequestDelegate实现。没有真正的代码，只是一些日志通过NSLog。 - 执行生成的接收码。这是一堆模糊的C代码，通过调用OpenSSL来解析苹果的应用收据来做一些解密工作。在解密和解析之后，Receigen通过调用我们在上面定义的块来报告其结果。对于我们的三个应用内购买产品，这个块被调用一次。
- 在接收生成的代码返回后，最后一次捕获运行时间。
您可以在下面看到块定义仅为22微秒。SKRequestDelegate的实例化时间要长得多，大约在1500微秒左右。接收解密&解析花费了大量的时间，执行大约0.1秒。然后在大约100微秒内通过三次调用该块来报告其发现。
2016-09-03 17:13:57.883 XXApp[231:7509] elapsedTime after declare &-0.000022
2016-09-03 17:13:57.884 XXApp[231:7509]实例化
SKRequestDelegate实现后的elapsedTime: -0.0015792016-09-03 17:13:57.995 XXApp[231:7509] elapsedTime: -0.112392
2016-09-03 17:13:57.995 XXApp[231:7509] elapsedTime: -0.112482
2016-09-03 17:13:57.995 XXApp[231:7509] elapsedTime after reeigen code called the block: -0.112556
2016-09-03 17:13:57.997 XXApp[231:7509] elapsedTime after reeigen code done: -0.115133
在运行了几次之后，结果一致，我得出结论，NSDate对于毫秒-微秒范围内的临时基准测试确实很有用。