我應該使用什麼儀器工具來了解我的Monotouch應用的內存使用情況？

Question

我一直在閱讀很多有關跟蹤Instrument的內存使用情況，但幾乎沒有與Monotouch結合使用的內容。

似乎有是三個oposing索賠這裏：

1. 使用儀器的分配的效用。 「活動字節數」是應用程序使用的物理內存量。
2. 使用內存監視器插件。從進程列表中，選擇您的應用程序並檢查「真實內存」列。這是當前正在使用的RAM數量。
3. 使用虛擬機跟蹤器並進行自動快照。 「髒大小」，如果你在之後。

從我注意到：

• 「實內存」只要GC被觸發
• 即使我的「活字節」保持30MB左右我最終會給內存警告下降
• 隨着「Live Bytes」的不斷增加，「Real Memory」可以顯着增加，容易增長到200MB或更多。
• 在使用QLPreviewController並查看一個瘋狂的大Word文檔（1000頁）時，滾動瀏覽該文檔會瘋狂地增加真實內存。如果收到內存警告，則實際內存，不是實時的字節。最終，應用程序將崩潰; Monotouch問題還是Apple的問題？
• 有時候，真實記憶似乎會增長，沒有什麼能阻止它。再說一遍，GC似乎很清楚它的大塊。這裏沒有真正的模式。

那麼正確的答案是什麼？有一個嗎？

編輯：我附上了兩張圖片。一個顯示我的應用程序生命中某個階段的內存使用情況，以及稍後的第二個階段。這兩個圖像都反映了用戶界面中同一點的內存使用情況，其中只有兩個控制器在屏幕上。也許有人仍然可以評論這些數字，特別是神奇的「Memory Tag 70」。

Answer 1

儀器在某種意義上是一個黑盒子，但這裏是我怎麼想的是：

似乎有是三個反對的權利在這裏：
1.使用*分配*儀器的實用程序。 「活動字節數」是應用程序使用的物理內存量。

我不確切知道「Live Bytes」是什麼，但它不是應用程序使用的物理內存量。I 認爲它是所有ObjectiveC對象使用的物理內存量（如果此理論正確，「實時字節」不包含託管代碼使用的任何內存，也不包含ObjectiveC對象間接使用的任何內存（如圖像數據） ，這似乎是真的）。如果你想追蹤泄露的對象，「實時字節」是非常有用的，但它並不是一個很好的指示實際使用內存的指標。

2。使用內存監視器插件。從進程列表中，選擇您的應用程序並檢查「真實內存」列。這是當前正在使用的RAM數量。

這有點接近：「真正的內存」是應用程序正在使用的物理內存量與其他應用程序不共享。應用程序使用的物理內存總量爲「虛擬內存」，但應用程序之間會共享大塊的「虛擬內存」（即共享庫當然會在內存中使用內存時使用內存，但由於它是不可變的，它將只會爲所有進程加載一次，但它會被添加到每個進程的「虛擬內存」中，因此，如果將所有進程使用的「虛擬內存」合計在一起，則將超出設備的實際物理內存。

3。使用VM Tracker並製作自動快照。 「髒大小」，如果你在之後。

正確。 「髒大小」是你所追求的 - 然而這與「真實存儲器」密切相關，它只是將「真正的存儲器」分成不同的類別，因此你可以很容易地看到使用存儲器的內容。

對於由於圖像泄漏而使用大量內存的典型情況，其過程如下所示：
1.使用內存監視器驗證您的應用程序確實存在內存問題。
2.在VM Tracker /「Dirty Size」中看到很多內存被圖像數據使用（這就是神奇的「內存標籤70」）。
3.使用Allocations找出創建CGImages的位置，查看相應的堆棧跟蹤並追蹤爲什麼這些圖像沒有被釋放。

雖然每個應用程序都不同，所以不可能想出適用於所有情況的簡短配方。

• 「實內存」只要GC被觸發
• 即使我的「活字節」保持周圍30MB我最終會給內存警告
• 隨着不斷的「活字節」下降，「真正的內存「可以顯着增加，容易增長到200MB或更多。

所有這些都在上面解釋。

• 在使用QLPreviewController和觀看的insanly大Word文檔（1000頁），通過該文件滾動將增長真正的記憶像瘋了似的。如果收到內存警告，則實際內存，不是實時的字節。最終，應用程序將崩潰; Monotouch問題還是Apple的問題？

這可能是你的問題太:)這是不可能說沒有真正瞭解其中的內存去。

• 有時，真實記憶似乎會增長，沒有什麼能阻止它。再說一遍，GC似乎很清楚它的大塊。這裏沒有真正的模式。

你的意思是說你正在看着真正的內存增長，而你的應用程序什麼都不做？如果你真的在你的應用中做某件事，這是完全正常的。