1 page.title=Tracking Memory Allocations 2 parent.title=Articles 3 parent.link=../browser.html?tag=article 4 @jd:body 5 6 <p>Writing efficient mobile applications is not always straightforward. In 7 particular, Android applications rely on automatic memory management handled by 8 Dalvik's garbage collector, which can sometimes cause performance issues if you 9 are not careful with memory allocations.</p> 10 11 <p>In a performance-sensitive code path, such as the layout or drawing method of 12 a view or the logic code of a game, any allocation comes at a price. After too 13 many allocations, the garbage collector will kick in and stop your application 14 to let it free some memory. Most of the time, garbage collections happen fast 15 enough for you not to notice. However, if a collection happens while you are 16 scrolling through a list of items or while you are trying to defeat a foe in a 17 game, you may suddenly see a drop in performance/responsiveness of the 18 application. It's not unusual for a garbage collection to take 100 to 200 ms. 19 For comparison, a smooth animation needs to draw each frame in 16 to 33 ms. If 20 the animation is suddenly interrupted for 10 frames, you can be certain that 21 your users will notice.</p> 22 23 <p>Most of the time, garbage collection occurs because of tons of small, 24 short-lived objects and some garbage collectors, like generational garbage 25 collectors, can optimize the collection of these objects so that the application 26 does not get interrupted too often. The Android garbage collector is 27 unfortunately not able to perform such optimizations and the creation of 28 short-lived objects in performance critical code paths is thus very costly for 29 your application.</p> 30 31 <p>To help you avoid frequent garbage collections, the Android SDK ships with a 32 very useful tool called <em>allocation tracker</em>. This tool is part of DDMS, 33 which you must have already used for debugging purposes. To start using the 34 allocation tracker, you must first launch the standalone version of DDMS, which 35 can be found in the <code>tools/</code> directory of the SDK. The version of 36 DDMS included in the Eclipse plugin does not offer you ability to use the 37 allocation tracker yet.</p> 38 39 <p>Once DDMS is running, simply select your application process and then click 40 the <em>Allocation Tracker</em> tab. In the new view, click <em>Start 41 Tracking</em> and then use your application to make it execute the code paths 42 you want to analyze. When you are ready, click <em>Get Allocations</em>. A list 43 of allocated objects will be shown in the first table. By clicking on a line you 44 can see, in the second table, the stack trace that led to the allocation. Not 45 only you will know what type of object was allocated, but also in which thread, 46 in which class, in which file and at which line. The following screenshot shows 47 the allocations performed by <a 48 href="http://code.google.com/p/shelves">Shelves</a> while scrolling a 49 ListView.</p> 50 51 <a href="images/ddms_allocation_trackerl.png"> 52 53 <img style="cursor:hand;width: 320px; height: 250px;" src="images/ddms_allocation_tracker.png" border="0" alt="" /> 54 </a> 55 56 <p>Even though it is not necessary — and sometimes not possible — to 57 remove all allocations for your performance critical code paths. the allocation 58 tracker will help you identify important issues in your code. For instance, a 59 common mistake I have seen in many applications is to create a new 60 <code>Paint</code> object on every draw. Moving the paint into an instance field 61 is a simple fix that helps performance a lot. I highly encourage you to peruse 62 the <a href="http://source.android.com/">Android source code</a> to see how we 63 reduce allocations in performance-critical code paths. You will also thus 64 discover the APIs Android provide to help you reuse objects.</p> 65
