Ios 由于内存压力，可靠地强制后台应用程序终止

我试图了解导致iOS系统重新启动由于内存压力而终止的应用程序的条件。然而，创造足够的内存压力一直很困难

目前我的方法是通过Xcode启动我的应用程序，在后台运行它，然后启动一个消耗内存的助手应用程序。它在NSTimer循环中分配内存位，直到iOS系统将其杀死。幸运的是，Xcode告诉我，我的主应用程序“由于内存压力而终止”

---

我正在寻找一种更可靠的方法来实现这一点。是否有内存分配技术或专用API更适合于此目的？

我想您想要完成的是测试您是否正确保存了状态，以便在重新启动时导航回原来的位置

---

我建议设置一个标志，这样当你的应用程序检测到它被移动到后台时，（ApplicationIdentinterBackground:），它会要求更多的时间，所有的状态都会改变，然后要么坐在旋转循环中直到被杀死，要么执行“退出（0）”。您应该能够看到应用程序在Xcode中“死掉”，然后可以重新启动它。

您描述的行为让我有点惊讶，但有一些想法：

据我所知，iOS不保证放弃应用程序的顺序，也不保证放弃所有后台应用程序（或者它是否只是试图放弃足够的应用程序来缓解内存压力）。这份报告提供了一些线索，但我不能担保。但是操作系统有着一些复杂的逻辑，所以我不太愿意就确保某个特定应用程序被抛弃所必须采取的步骤做出任何明确的声明

这个被抛弃的后台应用程序的顺序问题将受到您允许助手应用程序崩溃的影响。后台应用可能不会很快被抛弃，无法满足助手应用的分配尝试。因此，在iOS放弃你的主应用程序之前，助手应用程序可能会崩溃

我可能会建议对helper应用程序进行稍微不同的设计，这样当它收到内存警告时，它会释放它请求的所有内存并再次启动该进程。在我的“原因内存压力”应用程序中，我实际上在收到内存警告时停止分配和重新启动分配之间等待了几秒钟

但是，归根结底，我认为您可能需要确保helper应用程序不会崩溃，以确保您充分利用内存压力系统

您描述了在Xcode中等待调试器报告应用程序已终止。我可能建议您重复您的实验，直接在设备上运行主应用程序，而不是通过调试器。我之所以提出这个建议，是因为在理论上，我认为应用程序连接到调试器的事实可能会影响决定丢弃哪些应用程序时的优先级计算

由于应用程序将被终止，因此通过调试器运行它没有任何意义，因为如果操作系统执行某些操作来重新启动应用程序（例如后台

NSURLSession

、推送通知等），您的调试会话仍将消失。因此，通过调试器运行它来观察“如果操作系统重新启动我的应用程序怎么办”的问题是没有意义的

就个人而言，在诊断被丢弃、重新启动等应用程序的行为时，我使用Xcode设备管理器，并在那里观察设备的控制台。您可以在控制台中观察应用程序的任何NSLog语句，也可以观察应用程序被丢弃、应用程序被重新启动（如果操作系统确实在做一些事情来重新启动它）等情况

---

把你的应用程序给我妻子。。。保证崩溃。@Rob-帮助程序收到didReceiveMemoryWarning消息，iOS系统随后会立即终止帮助程序，但不会终止主程序。我正在5s上测试。在尝试了您的所有建议后，我的助手应用程序会消耗内存，直到收到内存警告，几秒钟后释放所有内存，然后再次启动，但下次会消耗10%以上的内存，直到应用程序崩溃。我认为问题在于5s内存太多，因为很容易让iPod touch抛弃其他应用程序，但在5s上，我需要启动一些游戏，然后运行helper应用程序。我希望苹果能让这一切变得简单。