Last week I gave a talk at the GTUG (Google Technology User Groups) meeting, hosted in Tel-Aviv’s Google offices. In my lecture, I showed how to take an Android app and check why the hell it’s not running smooth as I want it to be. Tips and best practices on that matter you can find dozens, but learning how to actually use tools exists for that purpose is much better! The slides from that lecture can be found here http://www.slideshare.net/udini1/android-preformance, but they don’t contain much info. This post will cover all the subjects I covered in the lecture, hope it’ll be informative to you all.
Traceview
This is the first tool anyone should use when there’s a laggy part in the app, and that’s the Traceview. This tool comes with the SDK, and gives performance profiling information for each method, in a nice graphical interface. All you need to do is to start the profiling, via DDMS or a short line of code (check out the Debug class), and stop it when the laggy part finished. The information will be shown like that:
This is the list of all the methods that were running on that period of time. The important parts are the percentage of the time consumed by each method. “Inclusive %” means the running time percentage for this method AND its child functions. The “Exclusive %” means the same but only for the function itself, without its child functions. You can easily drill down on each function, and see which of its child functions took most of the running time.
On the picture above we can easily see that the onClick function on the Main class took 99% percent of the running time, and its child function, findDivisors2(), was the heaviest inside it. We found the problem! we can now go to the function’s algorithm and try to change it to work faster.
BUT, what about this case:
Here we see that the Garbage Collection (executed by the startGC() function) is taking 96 percent of the running time (Yeah…I know…I went too far with that example ) . Should be go and debug the GC’s algorithm? probably no… The issue here may be allocation of too much object on a short time, or a memory leak, god-forbid..
Helping out the GC
In order to find memory issues, there are 2 tools which I particularly like. The first one is the SDK’s Allocation Tracker. Why? It’s convenient to use (embedded in the DDMS) and it gives vital information:
After you start tracking the allocation, using the button, you can get the currently allocated object at any time by clicking the “Get Allocations” button. The list of allocated object will be loaded with sweet info like allocation size, and stacktrace for the location where each object was allocated, giving you the power to catch that punk who’s creating all those String[] objects.
The second tool is the Eclipse Memory Analyzer Tool, or “Eclipse MAT”. This is tool who gets an HPROF file, and analyze it. HPROF is a standard for presenting heap memory snapshot. You can dump an HPROF file from within the DDMS, or by code. The problem is, There aren’t any good HPROF analyzers for the Dalvik VM heap dumps (which is the one we just got from the DDMS). But since we do have those for the J2SE VM, the Android gods sent us the “hprof-conv” (bundled in the SDK) which converts that alien dump to something analyzers can read. So, after dumping the heap info using the code or DDMS using this button:
We’ll use the hprof-conv to convert from Android’s HPROF file, to a standard HPROF file. After that, we’ll open the file in Eclipse MAT, and we can get some cool reports like those:
Another interesting stuff is also the Histogram view, allow us to see all the classes and how many objects each one has. That way it’s easy to see if the GC got overdosed by a particularly class. A dominator tree is also useful, it’ll help getting to know who’s creating what, finding the root for evil.
GUI Optimization
I’ll start with a nice tip for sluggish GUI – if the UI is slow-responding and/or laggy, check the Logcat. If you see GC entries which show running time of more than 16ms each, it’s probably causing the GUI problems, and needed to be checked by the methods suggested above.
layoutopt – That’s a nice console tool, which takes xml file and prints problems and tips regarding the layout in the XML. For instance, it can tell if there’re any redundant layouts, or too many Views, and even if the number of nested layouts is too high (should be 10 at most). It runs small amount of tests and probably won’t solve the question of life for you, but it can spot some problems you might missed.
Hierarchy Viewer – That’s a must-have tool for anyone who writes any layout on Android. This tool show the views tree of the currently presented layout on the device, and lets you analyze the time consumption for each component, and compare to the other components. There are also good non-performance related information there, like the properties for all components, and a layout view, to see where each component is positioned on the screen.
StrictMode
StrictMode is sort-of a problems detector. It’s developers tool, used by code, and allows you to create a set of rules the current thread, or the entire machined running it, must obey. If there’s a violation of one of the rules, it can notify by log message or a dialog, letting you know there’s a problem right on that very moment. Usually it’s used to find slow operations, like disk writes or network operations, on the UI threads. These operations burden the UI thread, making the user experiencing laggy UI movement.
That’s an example of defining a set of StrickMode rules :
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .penaltyLog() .penaltyDeath() .build());