2

我正在使用儀器和分配儀器。我只測試與我的應用程序的固定交互。iPhone:儀器分配穩步增加

我有一個導航控制器,深入4個階段。前兩個階段是標準的表格視圖控制器,後兩個階段是具有動態加載圖像的自定義控制器。

所以我跑我的工具應用程序(通過運行與性能工具 - >分配),然後執行以下交互:

1. App Loads 
2. I wait a bit until allocations graph stabilizes 
3. I tap/push into my navigation controller until the deepest level. 
4. I wait for the images to load and for the allocations graph to stabilize. 
5. I tap back out of the navigation controller until I'm back to the root level. 
6. I wait for the allocations graph to stabilize. 
7. GOTO 3. 

現在我已經注意到的是,從3每次迭代到7之間分配圖顯示稍高的值。因此,即使我正在做同樣的事情,並且所有視圖控制器的dealloc被調用,整體分配也在增加。

所以時間軸看起來大致是這樣的:

1. Start: 1mb 
2. Push controllers/Load images: 4mb 
3. Pop controllers: 1.1mb 
4. Push controllers/Load images: 4.1mb 
5. Pop controllers: 1.2mb 
6. ... etc ... (always increasing slightly) 

所以我的問題是這是否意味着我有泄漏或這正常嗎?分配圖數據實際上代表什麼?爲什麼即使我突然回到初始狀態,價值也在增加?我擔心,如果我的應用運行時間足夠長,即使所有用戶都在做的是推送和彈出視圖控制器,它也會消耗太多內存。

任何想法都會有所幫助。

回答

0

您可能有泄漏。檢查可以幫助您找到它們的泄漏儀器。

+0

感謝您的建議。你是對的,使用泄漏儀器,我發現我有3個泄漏從一開始。我將不得不做一些挖掘,看看究竟發生了什麼。 – nebs 2010-06-29 20:24:38

+0

如果你有一個視圖控制器,你推,然後彈出,內存的使用應該是完全一樣的,你第一次推它之前?或者它是否正常上漲〜0.2mb? – 2011-11-05 04:58:15

0

是的,這是一個泄漏。沿線的一個視圖控制器缺少一些東西。

0

如果您正在加載圖像,那麼很有可能您正在使用[UIImage imageNamed:],導致系統緩存並可能導致您的內存使用。但總之是的,你有一個泄漏。

+0

好點。雖然我所指的圖像加載不使用imageNamed,但實際上我使用imageNamed作爲自定義表格單元格和按鈕背景圖像。但我不認爲這有助於整體撥款增加。由於imageNamed緩存圖像不會避免在隨後的推/拉上重新加載它們嗎?或者它的工作方式不同? – nebs 2010-06-29 20:33:32

+0

我很確定imageNamed泄漏已被修復 – cobbal 2010-06-29 21:43:11

1

這是在模擬器還是在設備上?

由於驗證設備上存在問題很好,因爲有些系統庫在設備上比在模擬器中更頻繁地釋放內存。

如果Leaks什麼也沒有顯示,那是因爲即使你不認爲你是某個地方,你仍然在參考內存。爲了幫助追蹤,請突出顯示內存正在增加的一小部分圖形,然後選擇「已創建且仍然存在」。現在你可以看到分配的內存,並開始追蹤問題出在哪裏。

+0

它在模擬器中。感謝您的建議。事實上,我確實有泄漏,3。我必須深入挖掘一下,看看究竟在哪裏。 – nebs 2010-06-29 20:23:46

1

如果你有最新的iPhone SDK,它自帶的樂器版本(2.7我相信)有一個HeapShot功能。您可以觀看一些WWDC的10個視頻獲取更多信息,但基本上當您第一次彈出控制器時再拍攝一次,然後再次彈出時再次拍攝。它會顯示在兩個時刻不同的內存分配。

+0

是的,我正在使用新的SDK和儀器2.7。這聽起來像一個很酷的功能,我會def。檢查出來,謝謝。 – nebs 2010-06-29 20:23:10

+0

Heap Shot功能聽起來就像這種內存行爲所需要的一樣。我已經用它來解決類似的問題。 – 2010-06-30 13:01:56