ios - 可靠地强制后台应用程序因内存压力而终止

Question

我试图了解导致 iOS 系统重新启动因内存压力而终止的应用程序的条件。不过，产生足够的内存压力一直很困难。

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

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

Answer 1

我对您描述的行为感到有点惊讶，但有几点想法:

1. 据我所知，iOS 不保证应用程序被丢弃的顺序，也不保证所有后台应用程序都将被丢弃(或者它是否会尝试丢弃足够多的应用程序以缓解内存压力情况) . Handling low memory conditions in iOS and Mavericks提供了一些线索，但我不能保证。但是操作系统正在处理一些复杂的逻辑，所以我不愿就必须采取的步骤来确保放弃特定应用程序做出任何坚定的声明。

2. 这个被抛弃的后台应用程序的顺序问题会受到您允许您的助手应用程序崩溃这一事实的影响。有可能后台应用程序的丢弃速度不够快，无法满足您的助手应用程序的分配尝试。因此，在 iOS 开始放弃您的主应用程序之前，辅助应用程序可能会崩溃。

   我可能会建议助手应用程序的设计略有不同，这样当它收到内存警告时，它会释放它请求的所有内存并再次启动进程。在我的“Cause Memory Pressure”应用程序中，我实际上在收到内存警告时停止分配和重新启动分配过程之间等待了几秒钟。

   但是，归根结底，我认为您可能希望确保辅助应用不会崩溃，以确保您充分发挥内存压力系统的作用。

3. 您描述了等待 Xcode 中的调试器报告应用已终止的情况。我可能建议重复您的实验，直接在设备上运行主应用程序，而不是通过调试器。我之所以这样建议，是因为我认为您的应用程序附加到调试器这一事实在理论上可能会影响确定要放弃哪些应用程序的优先级计算。

   由于应用程序将被终止，无论如何通过调试器运行它是没有意义的，因为如果操作系统做了一些事情来重启应用程序(例如后台NSURLSession，推送通知等)。 ), 你的调试 session 无论如何都会消失。因此，通过调试器运行它以观察“如果操作系统重新启动我的应用程序会怎样”问题是没有意义的。

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