4

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

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

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

4

2 回答 2

5

我对您描述的行为感到有些惊讶，但有一些想法：

  1. 据我所知，iOS 不保证应用程序被抛弃的顺序，也不保证所有后台应用程序都将被抛弃（或者它是否会尝试抛弃足够多的应用程序以缓解内存压力状况）。iOS 和 Mavericks 中的处理低内存条件提供了一些线索，但我不能保证。但是操作系统涉及一些复杂的逻辑，所以我会犹豫对必须采取哪些步骤来确保放弃特定应用程序做出任何坚定的声明。

  2. 然后，您允许帮助应用程序崩溃这一事实会影响后台应用程序被抛弃的顺序问题。后台应用程序的丢弃速度可能不足以满足您的帮助应用程序的分配尝试。因此，帮助应用程序可能会在 iOS 开始抛弃您的主应用程序之前崩溃。

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

    但是，最重要的是，我认为您可能希望确保帮助应用程序不会崩溃，以确保您充分锻炼内存压力系统。

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

    由于该应用程序将被终止，因此无论如何通过调试器运行它是没有意义的，因为如果操作系统执行某些操作来重新启动应用程序（例如后台NSURLSession、推送通知等），您的调试会话无论如何都会消失。因此，通过调试器运行它以观察“如果操作系统重新启动我的应用程序会怎样”的问题是没有意义的。

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

于 2014-01-04T03:36:38.183 回答
1

我假设您想要完成的是测试您是否已正确保存状态，以便重新启动时您将导航回您所在的位置。

我建议设置一个标志，这样当您的应用程序检测到它被移到后台时（applicationDidEnterBackground :)，它会要求更多时间，是否所有状态都发生变化，然后要么处于自旋循环中直到被杀死, 或执行‘exit(0)’。您应该能够看到该应用程序在 Xcode 中“死亡”了，然后您可以重新启动它。

于 2014-01-03T22:32:48.807 回答