Find abandoned memory

The Allocations profiling template uses the Allocations and VM Tracker instruments to measure general and virtual memory usage in your app. However, to track down abandoned memory that’s been allocated but isn’t needed again, focus strictly on the Allocations instrument. This instrument measures heap memory usage and tracks allocations, including specific object allocations by class.

Launch Instruments.

In the profiling template selection dialog that appears, click Allocations.

Choose your device and app from the target device and process lists.

Click Choose to create a trace document.

Click the Allocations instrument in the timeline pane.

The Mark Generations button appears in the filter and configuration bar at the bottom of the detail pane.

Click the Record button () in the toolbar (or press Command-R) to begin recording.

Perform a short sequence of repeatable actions in your app.

In order to accurately generate trends, this should be a set of actions that starts and finishes with the app in the same state.

Click the Mark Generation button in the filter and configuration bar.

A flag appears in the track pane to identify the generation.

A list of generations you’ve marked is shown in the detail pane. Each generation includes a list of allocations that has occurred since the previous generation.

You can also mark generations after you’re done recording by dragging the inspection head in the track pane’s timeline to the desired location and clicking Mark Generation.

Perform steps 8 and 9 several times while monitoring the detail pane until you see whether memory is growing without limit.

Important: During the first few iterations, extra allocations may occur due to caching. Therefore, it is important to create a few initial generations for the purpose of establishing a baseline. Then, create additional generations for true analysis.

Click the Stop button () in the toolbar (or press Command-R again) when you’re ready to stop recording.

Scan through the generations in the detail pane and find one that seems representative of repeated memory growth.

The Growth and # Persistent columns tell you how much additional memory and how many allocations have occurred since the previous generation. If your app returns to its original state after an operation, you shouldn’t expect there to be growth from generation to generation.

Click the disclosure triangle () of a generation to display new objects that have been allocated since the prior generation.

Look for objects that are persisting. If you identify one, click the disclosure triangle () to display its instances.

Select an object instance.

Press Command-3 to display a stack trace for the selected instance in the extended detail area of the inspector.

This stack trace provides the complete list of method calls responsible allocating the instance.

Click the Collapse button () in the extended detail area to hide system calls in the stack trace. This makes it easier to locate your app’s methods.

Calls made by your app are colored black and preceded by a user code icon ().

Control-click on an entry in the detail pane, in the popover that appears choose Reveal in Xcode to show the source in Xcode.

Screenshot showing the popover for opening the user symbol in Xcode

Determine whether the allocation is useful. If it’s not, it’s abandoned memory that needs to be resolved.

Because abandoned memory is still referenced by your app, Instruments can’t determine its importance. To find abandoned memory, use generational analysis to ensure that memory does not continue to grow while repeatedly performing the same set of operations. For example, ending and starting a new game, opening and closing a window, creating and deleting a contact, or setting and unsetting a preference are all operations that should conceptually return your app to a previous and stable memory state. Extensive cycling through such operations many times should not result in unexpected or unrestrained memory growth. Instruments helps you correlate periods of memory growth with specific object allocations, so you can release them and reduce your app’s memory footprint.

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末双吆,一起剝皮案震驚了整個濱河市斑胜,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌左敌,老刑警劉巖,帶你破解...
    沈念sama閱讀 211,639評論 6 492
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件俐镐,死亡現(xiàn)場離奇詭異矫限,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,277評論 3 385
  • 文/潘曉璐 我一進(jìn)店門叼风,熙熙樓的掌柜王于貴愁眉苦臉地迎上來取董,“玉大人,你說我怎么就攤上這事无宿∫鹛” “怎么了?”我有些...
    開封第一講書人閱讀 157,221評論 0 348
  • 文/不壞的土叔 我叫張陵孽鸡,是天一觀的道長蹂午。 經(jīng)常有香客問我,道長彬碱,這世上最難降的妖魔是什么豆胸? 我笑而不...
    開封第一講書人閱讀 56,474評論 1 283
  • 正文 為了忘掉前任,我火速辦了婚禮堡妒,結(jié)果婚禮上配乱,老公的妹妹穿的比我還像新娘。我一直安慰自己皮迟,他們只是感情好搬泥,可當(dāng)我...
    茶點(diǎn)故事閱讀 65,570評論 6 386
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著伏尼,像睡著了一般忿檩。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上爆阶,一...
    開封第一講書人閱讀 49,816評論 1 290
  • 那天燥透,我揣著相機(jī)與錄音,去河邊找鬼辨图。 笑死班套,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的故河。 我是一名探鬼主播吱韭,決...
    沈念sama閱讀 38,957評論 3 408
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼鱼的!你這毒婦竟也來了理盆?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 37,718評論 0 266
  • 序言:老撾萬榮一對情侶失蹤凑阶,失蹤者是張志新(化名)和其女友劉穎猿规,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體宙橱,經(jīng)...
    沈念sama閱讀 44,176評論 1 303
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡姨俩,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,511評論 2 327
  • 正文 我和宋清朗相戀三年蘸拔,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片环葵。...
    茶點(diǎn)故事閱讀 38,646評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡都伪,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出积担,到底是詐尸還是另有隱情讲弄,我是刑警寧澤锅减,帶...
    沈念sama閱讀 34,322評論 4 330
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響壳嚎,放射性物質(zhì)發(fā)生泄漏娄周。R本人自食惡果不足惜绎橘,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,934評論 3 313
  • 文/蒙蒙 一迟赃、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧渴庆,春花似錦铃芦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,755評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至耸弄,卻和暖如春咧虎,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背计呈。 一陣腳步聲響...
    開封第一講書人閱讀 31,987評論 1 266
  • 我被黑心中介騙來泰國打工砰诵, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人捌显。 一個月前我還...
    沈念sama閱讀 46,358評論 2 360
  • 正文 我出身青樓茁彭,卻偏偏與公主長得像,于是被迫代替她去往敵國和親扶歪。 傳聞我的和親對象是個殘疾皇子理肺,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 43,514評論 2 348

推薦閱讀更多精彩內(nèi)容