When things get messy, you need to use proper tools to solve your problems. We'll demonstrate how to use traceview and dmtracedump for debugging those nasty little bugs and errors.
4. Profiling (1)
• form of dynamic program analysis that measures,
for example, the space (memory) or time
complexity of a program, the usage of particular
instructions, or the frequency and duration of
function calls.
• Most commonly, profiling information serves to aid
program optimisation.
5. Profiling(2)
• It is very important for Android applications to
perform all operations as fast as possible.
• if your application is has long execution time and
everything else fails, you’ll need to use profiling
to debug those nasty errors and bugs
7. Trace files(1)
• to use profiling, we first need to generate log files
containing the trace information you want to
analyse.
• two ways:
1. Use Debug class
2. Use the method profiling feature of DDMS
to generate trace logs (less precise)
8. Trace files(2)
• Include the Debug class in your code and call its
methods such as startMethodTracing() and
stopMethodTracing(), to start and stop logging of
trace information to disk.
• your application must have permission to write to
external storage
9. Traceview(1)
• graphical viewer for execution logs that you create by using
the Debug class to log tracing information in your code
• can help you debug your application and profile its
performance
• two layouts
1. Timeline panel - describes when each thread
and method started and stopped
2. Profile panel - provides a summary of what
happened inside a method
10. Traceview(2) - Timeline panel
Each thread’s execution is shown in its own row, with time
increasing to the right. The thin lines underneath the first row
show the extent (entry to exit) of all the calls to the selected
method.
12. Traceview(4)
• table shows both the inclusive and exclusive times
(as well as the percentage of the total time):
1. exclusive time - time spent in the method
2. inclusive time - time spent in the method
plus the time spent in any called functions
• The last column in the table shows the number of
calls to this method plus the number of recursive
calls
13. dmtracedump
• generates the call stack data as a tree diagram,
with each call represented as a node.
• it shows call flow (from parent node to child nodes)
using arrows
• Graphviz Dot utility is needed to create graphical
output
15. Strict mode(1)
• You should avoid performing long running
operations on the UI thread. This includes file and
network access.
• StrictMode you can instruct the Android system to
crash your application if it performs long running
operations, e.g. I/O in the user interface thread.
18. Real world example
• client reported that application has long startup
time on Samsung devices
• tested on Samsung Galaxy Tab 2.0. - startup time is
longer than 25 seconds
19. • firstly we scanned the app with StrictMode - no
long running operations were found on the UI
thread
20. • secondly, we optimised ActiveAndroid ORM
library by manually specifying database models in
Android manifest
• with this step we optimised app startup by 4
seconds
• after that debugging didn’t help, so we needed to
use profiling
23. • after examining the tracefile, we noticed strange
behaviour with MagicViews external library
• turns out that this library scans all asset folders
(either our application or external dependencies
assets) looking for custom fonts
• after replacing MagicViews with custom
implementation of UI elements, we downgraded the
app startup time to less than 2 seconds
24. Conclusion
• Profiling is something we usually use as a last
resort
• it will not automatically fix all of your problems,
but it’ll just give you a brief insight to your
application behaviour
• TraceView is deprecated - use Android Device
Monitor (tools/monitor) instead