3

我正在开发我的小应用程序，我正在实施 didReceiveMemoryWarning 等，但我觉得我没有很好地掌握测试我正在实施的内容的最佳方法。

首先，显然在模拟器中，didReceiveMemoryWarning 对于不在前台的应用程序不会触发，直到该应用程序被带回前台，根据这个问题- 实际上，这符合我自己的经验，但我很容易忽略它，因为它没有任何意义。（为什么我要延迟清理内存，直到我回到前台并可能再次需要该数据？）这是否与实际硬件的行为相匹配？如果是这样，除了 didReceiveMemoryWarning 之外，清理 applicationWillEnterBackground 中的任务是否有意义？

其次，一般来说，在模拟器中触发“模拟内存警告”菜单项的好策略是什么，以便以可能在实际硬件上发生的方式触发内存警告？

4

2 回答 2

3

Q1：这是否与实际硬件的行为相匹配？

  • A: 是的，模拟器和实际设备在这方面的行为是相同的（例如，如果您的应用程序被挂起并且没有运行后台任务，则它不会接收applicationDidReceiveMemoryWarning）。

Q2：清理任务有意义applicationWillEnterBackground吗？

  • A1：只有在您的应用程序必须为完全重启做好准备的情况下。如果您的应用程序保持暂停状态并且用户对其他应用程序执行了很多操作，则您的应用程序可能会完全卸载 - 即使该应用程序可能仍然在任务切换器中可见，当用户下次激活它时，您的应用程序委托将接收application:didFinishLaunchingWithOptions:（不 applicationWillEnterForeground:）。
  • A2：我不会费心清理内存，但您应该确保在applicationWillEnterBackground完成时，所有用户偏好和其他内容都已保存，以便应用程序知道下次激活时再次占用的位置。

Q3：触发“模拟内存警告”菜单项的好策略是什么？

  • A1：我怀疑是否可以制定通用策略，因为每个应用程序都不同。
  • A2：使用一个特定的案例：在我的应用程序中，我不使用应用程序委托applicationDidReceiveMemoryWarning来缓解内存压力，而是依靠这样一个事实，即当发送内存警告时，iOS 也会调用viewDidUnload某些不在其中的视图控制器采用。因此我通常使用内存警告模拟来测试我的视图控制器是否viewDidLoad正确viewDidUnload平衡。
  • A3：具体示例：我的应用程序使用选项卡，所以我最喜欢的场景是 1）使用被测视图控制器（VC）显示选项卡；2) 导航到不同的选项卡；3）模拟内存警告（iOSviewDidUnload在被测VC中调用）；4) 导航回原始选项卡（iOSviewDidLoad在被测 VC 中调用）。
  • A4：如果您想使用类似的方法，那么您必须为您的应用确定哪些视图可能会被 iOS 卸载。在我（有限的）经验中，这些往往是不相关的视图，例如不同选项卡上的视图。
于 2012-12-31T17:51:12.117 回答
1

这是我对你的第二个问题的回答——它也回答了你的第一个问题：

我使用“模拟内存警告”功能有效地重现了子视图控制器消耗足够内存以致其父视图控制器必须释放资源的问题。

例如，考虑一个显示相机/照片库（即 UIImagePickerController）的子视图控制器。这会占用大量内存。如果选择器控制器消耗的内存超过可用内存，父视图控制器将被卸载，一旦父视图控制器再次显示（当子弹出时），将再次调用父视图控制器。这意味着 viewDidLoad 中设置的任何变量都将被再次设置，可能存在内存泄漏或错误指针。

“模拟内存警告”有助于发现这些问题。您可以进入子视图控制器，选择“模拟内存警告”，然后弹出视图控制器并检查问题。

请注意，“didReceiveMemoryWarning”比实际尝试释放内存更相关（恕我直言）让您知道它发生了。

于 2012-12-31T15:02:55.453 回答