iOS：如何識別Xcode儀器的泄漏？

Question

我利用探查器來查找內存泄漏，並遇到了這個問題：

我切換到通話樹。

因此，我可以單擊它以找到更多有關它的信息：

但這並沒有給我任何線索。 我怎么知道導致泄漏的原因？

更新：

• 上面顯示了帶有顯示的系統庫的調用樹。
• 有關泄漏對象的信息：

• 關於您在應用中為重現此漏洞所做的操作的一些說明：

應用啟動（前景）時，我們的應用正在與REST-API同步。 這始終在我的iOS 7 / iPhone 4S上運行。 但是另一位開發人員擁有iOS7 / iPhone 5，很少遇到無法同步的問題。 經過十天的觀察和到處放置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。 iPhone 4S上的iOS 7.04（確定），iPhone 5（稀有案例）

我希望這有幫助。 謝謝

Answer 1

隨着泄漏中紅色尖峰出現的威脅，總泄漏的內存為1.06kb，這極不可能是問題的根源（甚至與之無關）。

就您的應用程序導致其他應用程序拋棄而言，這本身不是問題，並且我對此不必擔心（盡管要成為一個好公民，您確實應該盡量減少這種情況）。 更直接的功能問題是為什么您的應用程序無法同步以及這是否確實是由於應用程序自身內部的內存警告（或更准確地說，是您的應用程序無法響應內存警告而釋放足夠的資源）導致的，在后續的內存分配中失敗）。

在我看來，第一個問題是您是否真的在應用中收到內存警告。 通常，如果應用程序確實有內存警告，我會在控制台中看到類似以下的內容：

Dec 15 11:12:26 Robs-iPad myapp[2224] : Received memory warning.

但是我在控制台轉儲中看不到上述內容，因此讓我想知道您是否真的收到內存警告。

我可能建議在您的應用程序委托中插入顯式日志記錄：

- (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];
}

這將導致在控制台中看到以下內容：

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

但是關鍵目標是確認您是否確實在收到內存警告，以及這是否與應用程序的同步失敗真正相關。

但是讓我們假設問題確實是內存警告的結果。 這就引出了兩個問題：首先，首先要采取什么措施來減輕內存警告（例如，使用@autoreleasepool來減輕高水位線，如果不是絕對必要，則不要同時在內存中保留大量資源，使用imageWithContentsOfFile而不是imageNamed ？ 其次，您在響應內存警告時正在做什么（例如，您正在清除緩存等）？

因此，如果您確實確認內存警告確實是問題的根源（並且首先這樣做），那么在同步過程中查看分配圖可能很有意思（並確認活動字節的峰值，例如以及最終的活動字節數）。 查看問題中的分配圖，它看起來並不算太糟（即，沒有大幅度的波動），但是再一次，您還沒有與我們共享“活動字節”的數量，因此很難說。

但是當您模擬內存警告時，我絕對不會擔心1kb的泄漏。 這比您需要擔心的任何嚴重症狀更令人煩惱。 留意泄漏，但要注意（a）大泄漏； （b）您代碼中的代碼，而不是框架中的代碼。

---

我在下面的原始答案是對原始問題的回答，該問題僅僅是“似乎與我的代碼不符的工具所顯示的這種泄漏是什么”。 我將其保留在這里以供參考：

---

這可能表明泄漏不在您的代碼中，而是在系統框架（您已隱藏）中。

您可能要分享：

• 顯示系統庫的調用樹；

• 有關泄漏對象的信息（因此，不僅是“調用樹”，而且還有“泄漏”列表）；

• 關於您在應用中為重現此漏洞所做的操作的一些描述；

• 您看到此問題的iOS版本本身顯示出來，您沒有看到哪些版本（框架本身並非沒有泄漏，但因iOS目標而異）； 和

• 您正在運行的Xcode版本。

坦白說，鑒於（a）泄漏量可忽略不計，您可能最終無視此問題； （b）沒有跡象表明問題出在您的代碼中； （c）iOS框架確實存在無法控制的泄漏。 但是，如果您擔心，請分享一些上述信息，我們也許可以提供進一步的觀察。