如何分析单点触控应用程序？
我正在尝试使用 Instruments 分析我的 iPhone 应用程序中的性能问题。我在调试模式下编译并安装了我的应用程序，创建了一个“时间分析器”并成功记录了相关时间间隔的一些数据，但我还没有弄清楚如何分析我正在记录的数据。
我了解探查器通常是如何工作的，我对 Rational Quantify 有相当多的经验，但在这种情况下我被难住了。
我想看到的内容：我编写的哪些函数是给定时间段内的 cpu 性能瓶颈？
我所看到的：许多看似微不足道的噪音显然与我自己的应用程序代码无关：http://screencast.com/t/3gYOuwua3
我尝试过各种过滤器，但没有一个真正有帮助。我应该如何进行？
谢谢，
阿德里安
I am trying to analyze a performance issue in my iPhone app with Instruments. I compiled and installed my app in debug mode, created a "Time Profiler" and successfully recorded some data of the time interval in question, but I haven't figured out how to analyze the data I am recording.
I understand how a profiler usually works, I have quite a bit of experience with Rational Quantify, but in this case I am stumped.
What I would like to see: Which of the functions I coded are the cpu performance bottlenecks during the given time period?
What I do see: Lots of seemingly insignficant noise apparently with no relation to my own application's code whatsoever: http://screencast.com/t/3gYOuwua3
I've tried all kinds of filters, but none really helped. How should I proceed?
Thanks,
Adrian
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这很常见......
首先，“自我”时间在任何真正的软件中几乎毫无用处。
它所做的只是让你看着它然后“嘎嘎！”。
如果你碰巧在某个时间点冻结它，你会看到一个调用堆栈有很多层，并且在堆栈的顶端，它要么被
在您可以控制的代码中很少找到程序计数器。
因此，即使您确实在代码中找到了超过百分之几的自我时间，修复它也无法节省更多的时间。
另一方面，堆栈上的其他代码行又如何呢？
如果你冻结它 10 次，其中有 5 次，某一行特定的代码在堆栈上，你就知道该行，如果你可以避免执行它，大约可以为你节省 50% 。
我不寻找“慢功能”或“热点”。
我使用的技术是这个，还有一个还有更多原因。
This is so common...
First of all, "Self" time is nearly useless in any real software.
All it does is make you look at it and go "gack!".
If you happened to freeze it at a point in time, you would see a call stack many layers deep, and at the tip of the stack it would either be
It is seldom to find the program counter in code you have any control over.
So even if you did locate more than a few percent of self time in your code, fixing it can't conceivably save any more than that.
On the other hand, what about the other lines of code on the stack?
If you froze it 10 times, and on 5 of those times, a particular line of code was on the stack, you know that line, if you could avoid executing it, would save you 50%, roughly.
I don't look for "slow functions" or "hot spots".
The technique I use is this, and there are a lot more reasons why.