The best way to solve a performance problem with an Android application is to profile the application by tracing the execution. This way, you can make decisions on what to improve based on real data and detect bottlenecks in the application. In the Android SDK, the Debug object handles the profiling, and the TraceView utility is used to view the generated trace file. I will describe how to profile using the tools included in the Eclipse Android SDK plugin, but you can also use the traceview command.
Keep in mind that a .trace file can get pretty big, so be careful to trace only the parts of the application that are problematic. If you have no idea what to profile, you can trace at large the first time and drill down to specific sections later on. Also, execution is slowed down when methods are traced, so you should only compare traced execution time with another traced time.
Profiling from the code
Profiling for the code allows you to analyse a section which you already suspect is problematic. To profile from the code :
- Add calls to the Debug class methods where you want to start and stop profiling. To start profiling in any method, add the following method calls :
Debug.startMethodTracing("logname");And to stop profiling, add the following call :
Debug.stopMethodTracing();
Those calls don’t need to be in the same method, but make sure the stopMethodTracing will be reached. Also, your application must have permission to write to the SD card, or else you will get an exception Unable to open trace file “/sdcard/logcat.trace” : Permission denied.
- Start the application and execute the problematic operation to trace it. A message is displayed in the Logcat output when the profiling starts and stops, and a logname.trace file will be created at the root of the file system of the device.
- Navigate to the root of the SD card of the device, and copy the .trace file to the desktop. Open the .trace file with eclipse and it will be shown in the trace tool. See the Analyzing the .trace file section below to check the result.
Profiling from Eclipse
Profiling during debugging can allow you to pinpoint a problem appearing at random times during the execution or for which you are unsure which lines of code are causing the problem.
- In the DDMS perspective, click the Start Method Profiling button.
- Press the same button again (Stop Method Profiling) to stop profiling. The result will appear immediately in Eclipse.
Analyzing the .trace file
When opening a .trace file, the following window is shown :
At the top, each thread has its own timeline. In this application, there is only a main thread, the other threads are system thread. In my opinion, the most interesting columns are :
- Incl CPU % : Percent of the total CPU time used by this method, including the execution time of all the child methods.
- Incl CPU Time : CPU time in milliseconds used by this method, including the execution time of all the child methods.
- Calls + RecurCall/Total : The number of calls to the child method by the parent method (and recursive calls) /Total calls to the method for the whole .trace file.
You can drill down on any method to see the child methods and analyse them. In that case, drilling down on the generateRandomNumber method shows that the child method saveRandomNumber makes up the bulk of the execution time. In fact, if you look at the Calls column you can see that it was called 1000000 times. The method was called multiple time for the test, but for a real profiling case this is where you should paid attention : the number of calls may be reduced, or the execution of the method optimized.
| Reference: | Using Android Traceview in Eclipse from our JCG partner Cindy Potvin at the Web, Mobile and Android Programming blog. |
