使用 XCode 和工具提高 iPhone 应用程序性能
我已经断断续续地尝试仪器一段时间了，但我仍然无法执行以下操作（得到任何合理的结果）：确定或估计多次调用的函数的平均运行时间。
例如，如果我使用 CADisplayLink 以 60 Hz 驱动我的 gameLoop，我想看看循环平均运行需要多长时间...... 10 毫秒？ 30 毫秒等。
我已经接近“CPU 活动”仪器，但结果不一致或没有意义。时间分析器似乎很有希望，但我所能得到的只是“运行时间的百分比”......并且我想要一个实际运行时间。
I've been experimenting with Instruments off and on for a while and and I still can't do the following (with any sensible results): determine or estimate the average runtime of a function that's called many times.
For example if I'm driving my gameLoop at 60 Hz with a CADisplayLink I'd like to see how long the loop takes to run on average... 10 ms? 30 ms etc.
I've come close with the "CPU activity" instrument but the results are inconsistent or don't make sense. The time profiler seems promising but all I can get is "% of runtime"... and I'd like an actual runtime.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不确定乐器是你最好的选择。仪器会对您的代码进行采样，这意味着（除其他外）它会影响时序。如果您想知道循环需要多长时间，那么您应该在代码中添加一些内容来计算并保留或显示每个循环所花费的时间。
实际的运行时间可以通过以下方式获得：
如果您计算每个循环的时间，则获得平均值很容易，因为您可以在显示平均值之前对时间求和、对循环进行计数并除以。
当然，循环中的任何内容都会影响时间，但这种影响很小。
I'm not sure instruments is your best bet here. Instruments samples your code, meaning (amongst other things) that it affects timing. If you want to know how long a loop takes then you should put something in the code to calculate and either retain or display the amount of time each loop is taking.
An actual runtime can be had by:
Getting an average is easy if you have a time calculated per loop since you can sum the times, count the loops and divide before you display the average.
Anything in your loop affects the timing, of course, but this affects in a minimal way.
您应该尝试使用 Shark 用于您所说的时间分析。
You should try using Shark for the time profiling of which you speak.
我尝试过 Time Profiler，但它没有为您提供方法的平均或总运行时间。它只是告诉您在录制期间您的代码在某个方法中花费了多少时间。它告诉您您的代码在某个方法中花费了大量时间，但没有告诉您这是否是因为该方法运行一次并花费了很长时间，或者该方法是否被调用了多次但运行得非常快。如果是前者，那么您应该集中精力使该方法更快。如果是后者，您应该让代码更少地调用该方法。你必须弄清楚哪个是你自己。让事情变得更加困难的是运行循环，它具有触发定时器服务或 I/O 等事件的输入源。这些被传递给可能是苹果的处理程序。如果 Apple 的某个处理程序花费了很长时间，那么 Time Profiler 会将其显示为热点，但除非您知道该处理程序正在做什么以及为什么对此无能为力。苹果的东西甚至不一定从你的调用堆栈端的任何地方调用，所以你不能很容易地优化。我在 OpenGL ES 分析器方面取得了更大的成功，因为它的 API 统计信息为您提供了 OpenGL ES 调用的调用计数、总时间和平均时间。如果您不使用 OpenGL ES，则对您没有帮助。
I've tried Time Profiler but it doesn't give you an average or total run time for a method. It just tells you how much time your code is spending in a method during your recording. It tells you your code spends a lot of time in a method but doesn't tell you whether that's because that method ran once and took a long time or whether that method was called many times but ran real fast. If its the former then you should concentrate on making the method faster. If it's the latter you should have your code call the method less often. You have to figure out which it is yourself. Making things more difficult is the Run Loop which has input sources that fire off events like the timer service or I/O. These get passed to handlers which could be Apple's. If one of Apple's handlers is taking a long time then Time Profiler shows it as a hot spot but unless you know what that handler is doing and why there's not much you can do about it. Apple's stuff is not even necessarily called anywhere from your end of the call stack so you can't optimize very easily. I've had more success with OpenGL ES Analyzer as its API Statistics gives you call count, total time, and average time for OpenGL ES calls. Doesn't help you if you aren't doing OpenGL ES.