是否有适用于 iPhone 应用程序的非采样时间分析工具？
我曾尝试使用 Instruments 和 Shark 来分析 iPhone 应用程序，但两者都使用数据采样方法，即定期截取线程堆栈的屏幕截图。
我更希望有一个全面覆盖的分析工具，它可以记录每个函数调用以及函数及其子例程所花费的时间。直观上这似乎比获取样本更好。像 Windows 上的 AQtime 这样的东西会很棒。
所以我的问题是：
- 基于样本的分析是否可信并且与基于函数调用的分析一样有用？
- Instruments 或 Shark 可以进行此类分析吗？
- 是否还有其他更接近我想要的工具可用？
I have tried Instruments and Shark to profile an iPhone app, but both use a data sampling approach, by regularly taking screenshots of thread stacks.
I would prefer to have a full coverage profiling tool, which would record every single function call and the time spent in functions and their subroutines. This seems intuitively better than getting samples. Something like AQtime on Windows would be great.
So my questions are:
- Can sample-based profiling be trusted and be as useful as function-call-based profiling?
- Can Instruments or Shark do this type of profiling?
- Are there other tools available, which would be closer to what I want?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我发现 Shark 使用的时间分析对于确定代码中的瓶颈非常准确。您可以通过使用
Config | 显示 Mini Config 编辑器来更细粒度地调整采样间隔。显示迷你配置编辑器并降低采样时间。Xcode 3.2 中的 Instruments 现在也有一个不错的 Time Profiler 工具，尽管它仅适用于 Mac。我发现 Instruments 非常适合分析，但如果系统负载过重，它可能会丢失样本。一般来说，我从 Instruments 开始，因为它很容易使用，然后如果我需要更详细地了解正在发生的情况，则转向 Shark。
如果您确实想做基于函数调用的分析，我会考虑 DTrace。我写了几篇关于使用 DTrace 调整 Cocoa 应用程序的文章 此处 和 此处。后一个甚至展示了使用自定义 DTrace 脚本调整 iPhone 应用程序启动时间的示例。
不幸的是，DTrace 目前不能在 iPhone 本身上运行，但您仍然可以通过在模拟器中运行应用程序来使用它收集许多有趣的信息。虽然确切的计时信息与设备上的信息相差甚远，但准确了解哪些方法执行了多少次以及以什么顺序执行可以提供一些关于在哪里进行优化的线索。我使用 DTrace 为 Shark 和 Instruments 收集的信息提供不同的视角，并回答有关我的应用程序的具体问题。
I've found that the time profiling used by Shark is very accurate for determining what your bottlenecks are in your code. You can adjust the sampling interval to be more fine-grained by showing the Mini Config editor using
Config | Show Mini Config Editorand lowering the sample time.Instruments in Xcode 3.2 also now has a nice Time Profiler instrument, although that's Mac-only. I've found that Instruments works well for profiling, but it can drop samples if the system is under heavy load. Generally, I start with Instruments, given how easy it is to use, then move on to Shark if I need a more detailed view of what's going on.
If you really want to do function-call-based profiling, I'd look at DTrace. I've written a couple of articles about tuning Cocoa applications using DTrace here and here. The latter one even shows an example of tuning the startup time of an iPhone application using a custom DTrace script.
Unfortunately, DTrace currently does not run on the iPhone itself, but you can still gather a lot of interesting information using it by running your application in the simulator. While the exact timing information will be nowhere near what it is on the device, knowing exactly what methods are executed how many times and in what order can give some clues as to where to optimize. I use DTrace to provide a different perspective on information gathered by Shark and Instruments, and to answer specific questions about my application.
是的，堆栈采样可能违反直觉，但它是可信的。请查看此链接和第一条评论。
这不是问“这花了多长时间？”
这是关于（以怀疑的声音）“那纳秒有必要吗？”
Yes, stack sampling can be counterintuitive, and yes it can be trusted. Look at this link, and the first comment.
It's not about asking "How long did this take?"
It's about asking (in a doubtful voice) "Was that nanosecond necessary?"