ios - 如何在简单的应用程序上调试严重的内存问题

Question

我在我的应用程序中遇到了内存问题，但我还没有找到一种方法来找出哪些对象/类正在使用该内存。

该应用程序很简单，是一个带有图片库 View 的 View Controller ( GridView 就像 Instagram Explore；带有 xib 单元格的 Collection View )，当您点击其中一个时，它会将您带到下一个屏幕，这是同一组图像，但作为垂直列表(带有 xib 单元格的 uitableview)。图像是从网络异步下载的。

当我在两个屏幕上滚动时，应用程序使用的内存不断增加，并且每次打开列表屏幕时速度也越来越快。然后，使用内存减少的唯一时刻(我的意思是急剧减少，比如从 1.8GB 到 200MB)是当它达到设备的限制时，然后问题一次又一次地出现。此外，有时系统无法减少使用的内存并且应用程序崩溃(“由于内存问题而终止的 iOS 应用程序”)。

我不认为这是布局问题，我已经检查了所有这些，还使用了内存图调试器，只发现了“malloc”问题，这让我无处可去，没有类，没有行，什么都没有。另外，Instruments 工具太复杂了，我还不知道怎么处理。

我已经阅读了一些教程并尝试了一些解决方案，但没有任何效果。其中包括:https://krakendev.io/blog/weak-and-unowned-references-in-swift , http://iosbrain.com/blog/2018/07/22/finding-memory-leaks-with-the-xcode-memory-graph-debugger-and-fixing-leaks-with-unowned/ , https://www.youtube.com/watch?v=1LnipXiSrSM&t=1697s , https://developer.apple.com/videos/play/wwdc2018/416/

有人可以给我一些关于如何正确调试内存问题以找出其确切来源的其他建议或教程吗？

Answer 1

大多数现代内存调试策略都适用于识别和解决强引用循环。但这不是你的问题。当您面临内存压力时，大部分内存都会恢复，这一事实表明存在缓存问题。无论您做什么进一步的诊断，都只能确认此行为。

要解决这个问题，请为您的缓存设置合理的限制并避免不给您控制权的缓存(例如 UIImage(named:))，问题可能会得到解决。如果没有看到图像是如何被检索的(例如确保 URLSession 的缓存是合理的)以及它们在下载后是如何被缓存的(例如第三方异步图像检索库通常给你控制缓存)。

并且，假设您(或您的第三方库)正在缓存，请确保:

• 在模拟器上测试您的应用，手动选择“调试”»“模拟内存警告”。这将有助于确认应用程序是否正在响应内存压力。根据您的描述，我认为我们已经知道是这种情况，但这是一个很好的诊断。

  请注意，虽然我们始终希望确保我们的应用程序正确响应内存警告，但当您遇到内存警告时，可能已经太晚了(例如，应用程序可能正在进行一系列分配，并且可能在您的应用程序完成之前失败有机会对警告使用react)。在出现内存警告之前，您想尽一切努力管理缓存。

• 您正在缓存原始负载(包含压缩的 jpg/png Assets 的 Data 对象)而不是 UIImage 对象(一旦它们重新使用，未压缩，如果你不小心的话可能会很大)，或者

• 如果您确实缓存了 UIImage 对象，请确保根据您的 UI 调整它们的大小。

  例如 100x100 的图像在 3x 比例下将占用 120kb，但如果图像是 1000x1000px，即使 ImageView 只有 100x100pt，未压缩的图像将占用 4mb，即每个像素 4 字节，无论压缩 jpg 的大小如何/png 负载。

• 如果您正在使用 NSCache，请设置 countLimit或 totalCostLimit .

• 如果您要自己收集(数组或字典)下载的图像，请确保对内存压力做出响应。例如，在 Swift 中:

  NotificationCenter.default.addObserver(forName: UIApplication.didReceiveMemoryWarningNotification, object: nil, queue: .main) { [weak self] _ in
      // do whatever you need to remove your cached objects here
  }
  

  我不认为这是这里的问题(因为您的应用程序正在响应内存压力)，但您可能想要检查您的应用程序是否有任何其他 (a) 大； (b) 自己下载并保存在内存中，并做出相应的响应。

FWIW，我认为你已经做了足够的诊断来确定问题的根源(它在内存压力下被清除的事实确实指向缓存问题)，但如果你想学习“分配”工具仪器，查看这些旧的 WWDC 视频 Fixing memory issues和 iOS App Performance: Memory .它们很老并且专注于 Objective-C，但是如果您想加快使用 Instruments 的速度，那里概述的技术仍然适用。但是，正如我所说，我认为您已经确定了这个问题。