我正在尝试查看在Xcode 7中为iOS 7-8-9版本的应用程序编译需要多长时间。
看到了这个问题,Ionic handle delay。答案警告不要依赖NSDate这么短的时间。而是Getting the time elapsed (Objective-c)建议:
img {
display: inline-block;
margin-left: auto;
margin-right: auto;
max-width: 100%;
}
.container {
max-width: 100%;
}
即使导入CFTimeInterval startTime = CACurrentMediaTime();
// perform some action
CFTimeInterval elapsedTime = CACurrentMediaTime() - startTime;
,此代码也无法编译。报告链接器失败:
架构armv7的未定义符号:
" _CACurrentMediaTime",引自:
还有其他方法可以用毫秒或纳秒跟踪短暂时刻吗?
请不要警告使微基准标记不可靠的固有变幻莫测。我只是试图了解时间的粗略。
也许Objective-C或Swift有类似于this Answer的东西,用于构建,运行和分析用Java和其他语言编写的目标JMH, Java Micro-benchmarking Harness的纳米/微/毫/宏基准。
答案 0 :(得分:0)
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应用为App Receipt Validation生成的源代码。 NSDate似乎很好地跟踪微秒。
我没有包含源代码,但您可以通过对事件序列的描述获得主要想法。
SKRequestDelegate
的实现。没有真正的代码,只需通过NSLog进行一些记录。您可以在下面看到块定义仅为22微秒。我们SKRequestDelegate
的实例化更多,大约1,500微秒。 Receigen解密&解析需要大部分时间,大约0.1秒才能执行。然后大约一百微秒通过三次调用块来报告其结果。
2016-09-03 17:13:57.883 XXApp [231:7509]经过时间宣布&填充块:-0.000022
2016-09-03 17:13:57.884 XXApp [231:7509]在实例化
SKRequestDelegate
的实施后经过时间:-0.0015792016-09-03 17:13:57.995 XXApp [231:7509]在Receigen代码称为块后经过时间:-0.112392
2016-09-03 17:13:57.995 XXApp [231:7509]在Receigen代码称为块后经过时间:-0.112482
2016-09-03 17:13:57.995 XXApp [231:7509]在Receigen代码称为块后经过时间:-0.112556
2016-09-03 17:13:57.997 XXApp [231:7509]完成Receigen代码后经过的时间:-0.115133
在运行了几次并得到一致的结果之后,我得出结论,NSDate确实可用于毫秒级微秒级的休闲基准测试。