我需要帮助找出在我的应用程序中后台执行的代码。如果我在我的应用程序中运行仪器中的活动监视器，即使按下主页按钮，它也会一致地使用大约1％的CPU。
这是，我假设，一旦它的backgroundTimeRemaining过期，就会导致iOS将我的应用程序从暂停状态踢出。即使在显然没有发生任何事情的屏幕上，即使我只是让手机睡了几分钟，应用程序仍会使用CPU时间并被踢出暂停状态。
我已经在我的应用程序中完成了对NSTimers的项目范围搜索，以确保在我离开应用程序后没有任何事情被解雇，并且在应用程序接收网络消息的热门地点放置断点，但似乎什么都没有被击中。
我已经确认，当它没有连接到调试器时仍然会发生这种情况，当我按下主页按钮时，其他应用程序似乎变为0或更接近0 CPU利用率。
什么工具可以帮助我实现目标并找出后台运行的代码？
编辑1 ：在Petesh发表评论后，我更多地使用了仪器中的Time Profiler，并发现我可以设置检测范围，并在我将应用程序放入代码后仅查看代码运行暂停状态。我找到了一些不应该运行的代码，我修复了它，但是应用程序在几分钟后仍然被踢出暂停状态！
活动监视器现在只显示0.1-0％的CPU使用率，而应用程序是后台运行的。再次运行Time Profiler会发现，我认为唯一运行的是主运行循环。在后台约一个小时的时间277毫秒。如果我检查“反转调用树”框，则显示时间主要花费在mach_msg_trap上，总时间为46毫秒。我不确定这是否是正常行为。
我已经解决了我的一些问题，但最重要的部分仍然存在。什么阻止我的应用程序停留在暂停状态？
编辑2（固定！）：经过深入挖掘后，我找到了罪魁祸首。第三方库正在调用beginBackgroundTaskWithExpirationHandler:，然后在完成时从不调用endBackgroundTask:。因此，我相信iOS认为该应用程序仍在尝试执行后台任务，并且在某个后台时间结束后，即使它没有真正做任何事情，它也终止了应用程序。
仪器中的活动监视器现在在初始后台代码运行后的整个时间内确实显示0％。
自从我第一次提出这个问题以来，我不确定是不是这个或者是我修复的所有内容的组合，但不管怎样，它已经修复了！
编辑3 ：经过一番研究后，我发现它实际上并不是第三方图书馆的错。该库正在侦听applicationDidEnterBackground通知，因此它可以刷新它的队列。但是在我们自己的applicationDidEnterBackground中，我们还有一个强制刷新队列。因此，它尝试两次启动后台任务，只完成一次。糟糕！
答案 0 :(得分：2)
如果您仔细阅读原始问题的所有编辑内容，您可以看到解决问题的详细信息和思考过程，但我正在写这个答案，以便人们获得主要内容。
要弄明白在后台占用CPU的是什么： 只需使用Instruments Time Profiler中的检查窗口即可。我能够完全归零我需要的部分。然而，这并没有帮助我找出为什么我的应用程序过早终止。
找出我的应用被终止的原因：
真正的答案就在我面前。无论我在哪里有后台处理程序，我都必须单步执行所有代码。对于beginBackgroundTaskWithExpirationHandler:的每次通话，都需要对endBackgroundTask:进行相反的调用。
我的案子中还有一些未解决的问题。我希望在Instruments中运行更多的内存分析，以确保即使有多个应用程序运行，我的应用程序也可以更长时间处于暂停状态。但这可能是一个永无止境的过程，因为你从未真正知道该阈值的确切位置。