iOS：如何识别 Xcode 仪器的泄漏？

Question

我已经使用分析器来查找内存泄漏并遇到了这个问题：

我切换到调用 Tree。

所以我可以点击它来了解更多信息：

但这并没有给我任何线索。我应该如何知道导致泄漏的原因？

更新：

• 上面显示的带有系统库的调用树已更新。
• 泄露的对象信息：

• 关于您在应用中为重现此泄漏所做的操作的一些描述：

我们的应用在启动（前台）时与我们的 REST-API 同步。这始终适用于我的 iOS 7/iPhone 4S。但是另一位开发者拥有 iOS7/iPhone 5，并且很少遇到不同步的问题。经过 10 天的观察并把NSLogs 到处放，我们昨晚发现了这个：

Dec 15 03:18:58  appname[4801] <Warning>: A gateway to the host server is working via WWAN.
Dec 15 03:18:58  appname[4801] <Warning>: Syncing...
Dec 15 03:18:58  appname[4801] <Warning>: Eventname to be fired: f11-reachability
Dec 15 03:18:58  appname[4801] <Warning>: Sync event IOS_REACHABILITY reached.
Dec 15 03:18:58  appname[4801] <Warning>: Sync: IOS_SYNC_WITH_SERVER is true
Dec 15 03:18:58  appname[4801] <Warning>: Animating indicator...
Dec 15 03:18:58  appname[4801] <Warning>: Getting last timestamp: 1387003344.407783 then calling syncWithServerWithDate
Dec 15 03:19:27  com.apple.launchd[1] <Notice>: (UIKitApplication:com.apple.mobilecal[0x45fb]) Exited: Killed: 9
Dec 15 03:19:27  com.apple.launchd[1] <Notice>: (com.apple.afcd) Idle-exit job was jettisoned. Will bypass throttle interval for next on-demand launch.
Dec 15 03:19:27  com.apple.launchd[1] <Error>: (com.apple.afcd) assertion failed: 11B554a: launchd + 35697 [3C91C465-EFA6-32C7-A677-DD0B5FDEE0DC]: 0x9
Dec 15 03:19:27  com.apple.launchd[1] <Notice>: (com.apple.absd) Idle-exit job was jettisoned. Will bypass throttle interval for next on-demand launch.

第三次尝试同步（按下主页按钮并返回前台）给了我们这个，这表明内存不足：

Dec 15 03:25:18 C1 appname[4801] <Warning>: Getting last timestamp: 1387003344.407783 then calling syncWithServerWithDate
Dec 15 03:25:29 C1 profiled[6244] <Notice>: (Note ) profiled: Service stopping.
Dec 15 03:25:40 C1 crash_mover[6248] <Notice>: (Warn ) <crash_mover.m mv_recursive:98> Moving './LowMemory-2013-12-14-160222.plist' -> '/var/mobile/Library/Logs/CrashReporter/LowMemory-2013-12-14-160222.plist'

所以我想我试试探查器，看看有没有发现什么。

为了重现它，我启动了应用程序，转到主屏幕，然后按Simulate a Low Memory，然后单击应用程序回到前台。这就是我得到红色尖峰的地方。

• 您正在运行的 Xcode 版本。

Xcode 5.02。 iOS 7.04 在 iPhone 4S (OK), iPhone 5 (rare edge case)

我希望这会有所帮助。谢谢

Answer 1

正如 Leaks 中的红色尖峰出现的威胁一样，泄漏的总内存为 1.06kb，这极不可能是您的问题的根源（甚至也不相关）。

就您的应用程序导致其他应用程序被抛弃而言，这本身不是问题，我不太担心（不过，要成为一个好公民，您确实应该尽量减少这种情况） .更直接的功能问题是您的应用程序无法同步的原因以及这是否真的是应用程序本身内存警告的结果（或更准确地说，您的应用程序未能充分释放资源以响应内存警告，导致在随后的内存分配中失败）。

在我看来，第一个问题是您是否真的在应用中收到内存警告。一般来说，如果应用程序确实有内存警告，我会在控制台中看到类似以下内容：

12 月 15 日 11:12:26 Robs-iPad myapp[2224]：收到内存警告。

但我没有在您的控制台转储中看到上述内容，所以我想知道您是否真的收到了内存警告。

我可能会建议在您的应用委托中插入显式日志记录：

- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application
{
    NSLog(@"%s", __FUNCTION__);

    // free whatever caches or other temporary resources you can here
}

或在视图控制器中进行特殊处理：

- (void)didReceiveMemoryWarning
{
    NSLog(@"%s", __FUNCTION__);

    [super didReceiveMemoryWarning];

    // do whatever you want to free resources here

    [[[UIAlertView alloc] initWithTitle:nil
                                message:@"didReceiveMemoryWarning"
                               delegate:nil
                      cancelButtonTitle:@"OK"
                      otherButtonTitles:nil] show];
}

这将导致在我的控制台中看到以下内容：

12 月 15 日 11:12:26 Robs-iPad myapp[2224]：-[AppDelegate applicationDidReceiveMemoryWarning:] 12 月 15 日 11:12:26 Robs-iPad myapp[2224]：-[ViewController didReceiveMemoryWarning]

但关键目标是确认您是否真的收到内存警告，以及这是否与您的应用同步失败真正相关。

但让我们先假设问题确实是内存警告的结果。这会导致两个问题：首先，您首先要采取哪些措施来减轻内存警告（例如，使用@autoreleasepool 来减轻高水位标记，如果不是绝对必要的话，不要同时在内存中保存大量资源，使用imageWithContentsOfFile 而不是imageNamed)？其次，您在做什么来响应内存警告（例如，您是否正在清除缓存等）？

因此，如果您确实确认内存警告确实是问题的根源（并首先这样做），那么在同步过程中查看您的分配图可能会很有趣（并确认实时的峰值数量）字节，以及活动字节的最终数量）。查看您问题中的分配图，它看起来并不算太糟糕（即没有剧烈波动），但是再一次，您没有与我们分享“活动字节”的数量，所以很难说。

但是当您模拟内存警告时，我绝对不会担心 1kb 的泄漏。这比您需要担心的任何严重症状更令人烦恼。注意泄漏，但要关注 (a) 大泄漏； (b) 那些在你的代码中，而不是在框架中。

---

下面我的原始答案是对原始问题的回应，该问题仅仅是“似乎与我的代码不对应的仪器显示的这种泄漏是什么”。我会留在这里以供参考：

---

这可能表明泄漏不在您的代码中，而是在系统框架中（您已隐藏）。

您可能想分享：

• 显示系统库的调用树；

• 关于泄漏对象的信息（因此，不仅是“调用树”，还有“泄漏”列表）；

• 您在应用程序中为重现此泄漏所做的操作的一些描述；

• 您会看到哪些 iOS 版本会出现此问题，哪些版本您不会（框架本身并非没有泄漏，但会因 iOS 目标而异）；和

• 您正在运行的 Xcode 版本。

坦率地说，鉴于 (a) 泄漏的大小可以忽略不计，您最终可能会忽略此问题； (b) 没有迹象表明问题出在您的代码中； (c) iOS 框架确实存在您无法控制的漏洞。但是，如果您担心，请分享上述一些信息，我们或许可以提供进一步的观察。