我正在尝试了解导致iOS系统重新启动因内存压力而终止的应用的条件。尽管如此，创造足够的记忆压力仍然很难。
目前我的方法是通过Xcode启动我的应用程序，将其作为背景，并启动一个吃内存的帮助应用程序。它在NSTimer循环中分配内存位，直到iOS系统终止它为止。当我很幸运时，Xcode告诉我，我的主应用程序是“因内存压力而终止”。
我正在寻找一种更可靠的方法来实现这一目标。是否有更好的内存分配技术或私有API用于此目的？
答案 0 :(得分：5)
我对你描述的行为感到有些惊讶，但有些想法：
据我所知，iOS不保证应用程序被丢弃的顺序，也不保证所有后台应用程序都会被抛弃（或者它是否会尝试放弃足够的应用来缓解内存压力状况） 。 Handling low memory conditions in iOS and Mavericks提供了一些线索，但我无法保证。但操作系统正在使用一些复杂的逻辑，所以我会毫不犹豫地对必须采取的步骤做出任何坚定的声明，以确保特定的应用程序被抛弃。
这个背景应用程序被抛弃的顺序问题会受到您允许助手应用程序崩溃这一事实的影响。后台应用程序可能不会被足够快地抛弃以满足您的帮助应用程序的分配尝试。因此，在iOS开始抛弃您的主应用程序之前，帮助应用程序可能会崩溃。
我可能会建议辅助应用程序的设计稍有不同，这样当它收到内存警告时，它会释放它请求的所有内存并再次启动进程。在我的“因果记忆压力”应用程序中，我实际上在收到内存警告和重新启动分配的过程之间等待几秒钟停止分配。
但是，最重要的是，我认为您可能希望确保帮助应用程序不会崩溃，以确保您充分运用内存压力系统。
您描述在Xcode中等待调试器报告应用程序已终止。我可能会建议重复您的实验，直接在设备上运行主应用程序，但不能通过调试器。我建议这样做，因为理论上可能会让我觉得你的应用程序附加到调试器的事实可能会影响优先级计算，以确定哪些应用程序将被抛弃。
由于应用程序将被杀死，无论如何都无法通过调试器运行它，因为如果操作系统执行某些操作来重新启动应用程序（例如后台NSURLSession，推送通知等），调试会话无论如何都会消失。因此，通过调试器运行它是没有意义的，以便观察“如果操作系统重启我的应用程序会怎么样”的问题。
就个人而言，在诊断被抛弃，重新启动等应用程序的行为时，我使用Xcode设备管理器，并在那里观察设备的控制台。您可以在控制台中观察任何应用程序的NSLog语句，以及观看被放弃的应用程序，重新启动应用程序（如果操作系统确实在重新启动它），等等。
答案 1 :(得分：1)
我认为您想要完成的是测试您是否已正确保存状态，因此重新启动时您将返回到原来的位置。
我建议设置一个标志，这样当你的应用程序检测到它已被移动到后台时（applicationDidEnterBackground :)，它会要求更多时间，所有状态都会发生变化，然后要么处于旋转状态循环直到被杀死，或执行`exit（0）'。您应该能够看到应用程序已在Xcode中“死亡”，然后您可以重新启动它。