如何找出 mach_msg_trap 等待的内容？
我在目标上分析了我的 iPhone 应用程序，根据 Instruments 的说法，65% 的时间花在 mach_msg_trap 上。
我有一个永远运行的后台线程，并使用 performSelectorOnMainThread:withObject:waitUntilDone: 将结果发送回主线程，大约每 2 秒一次。我不会等到完成。
I a profiling my iPhone application on target, and according to Instruments 65% of the time is spent in mach_msg_trap.
I have a background thread that runs-forever and send results back to the main thread using performSelectorOnMainThread:withObject:waitUntilDone:, aproximately every 2 seconds. I am not waiting until done.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事实证明，我的应用实际上并没有将 65% 的时间花在
mach_msg_trap函数上。这是我仪器中的配置错误。采样器工具默认为所有样本计数，这将测量所有线程，无论其状态如何。
而是切换到运行采样时间，这将反映当前的实际工作负载。
仪器屏幕截图 http://developer.apple.com/library/mac/qa/qa2009 /images/qa1619_running_sample_times.png
Turn out my app is not actually spending 65% of it's time in the
mach_msg_trapfunction. It was a configuration error in Instruments on my part.The Sampler tool defaults to All Sample Counts, this will measure all threads regardless of their state.
Instead switch to Running Sample Times that will reflect the current actual workload.
Screenshot of Instruments http://developer.apple.com/library/mac/qa/qa2009/images/qa1619_running_sample_times.png
如果您不希望主线程除了等待该后台线程（或等待用户输入）之外执行任何操作，则无需担心 - 您的应用程序在大多数情况下根本没有什么可做的。
如果您希望主线程积极执行其他操作，请更新您的问题来描述这一点。在这种情况下，您可能需要查看 mach_msg_trap 的完整调用堆栈，因为它通常位于调用堆栈的底部，实际浪费时间的地方更靠上。
If you're not expecting your main thread to be doing anything other than waiting on this background thread (or waiting for user input) there's nothing to be concerned about -- your application simply has nothing to do most of the time.
If you're expecting the main thread to be actively doing something else, please update your question to describe that. In this case, you might want to look at the full call stacks to mach_msg_trap as it's often at the bottom of a call stack where the actual time-waster is further up.