Tuning Android Applications (Part One)

Tuning Android
Applications
Copyright © 2011 CommonsWare, LLC

What I'll Be Yammering About
● Now
– Traceview
– MAT
● After the Keynote
– Battery and Bandwidth
– Top Ten Tuning Tips


Traceview

Two Types of CPU Problems
● Generally slow
– Foreground
– Background
● UI “janky” (sluggish, jerky, non-responsive)
– Work being done on the main application thread
that perhaps should not be


Finding Your CPU Problems
● StrictMode
– Reports problems with main application thread
● Roll-Your-Own Timing
– E.g., TimingLogger
● Traceview
– Analyze method traces collected from VM
– Shows you where all the time goes

Collecting Trace Data
● Start/Stop from DDMS
– Choose your process
– Toggle toolbar button
● Start/Stop from Java
– android.os.Debug
– startMethodTracing()
– stopMethodTracing()


Loading Traceview
● DDMS in Eclipse
– Stopping collection auto-loads Traceview
● Standalone DDMS
– Stopping collection auto-loads standalone
Traceview (Android 2.2+)
● Trace-on-External-Storage
– Import into Eclipse
– Run traceview from command line

The Traceview Window
● Top = Timeline
– Rows = threads
– Shows which threads were active at which times
during test period
● Bottom = CPU Consumers
– Call tree of methods, showing which methods
are consuming what amount of time, calls
– Color coding matches timeline

Finding Hot Spots
● Sort table
– Exclusive = time taken up just in this method
– Inclusive = time taken up in method and any
methods it invokes (tree)
● Find your code
– Appearing in left column
– In “parents” of other things consuming lots of
time

Limitations
● Disables JIT
– Result: all Java code slower than normal
● Does Not Profile Native Code
– Result: native code a “black box”
● Overall Result: Absolute Times Inaccurate
– Looking for relative times compared to other
Java code


Memory Analysis
with MAT

Two Types of Memory Issues
● Running out of heap
– OutOfMemoryError
● Running out of stack
– StackOverflowError
– If stack trace shows mostly Android UI rendering
code, use Hierarchy View to identify deepest
portions of view hierachy, try to eliminate layers


Finding Your Heap Problems
● Allocation Tracking
– Through DDMS, records all allocations
● Exception: primitive arrays
– See who allocates what, try to figure out why
● Memory Analyzer (MAT)
– Examine heap dump
– Find out what is not getting garbage collected
– Find out how many objects exist, sizes

Collecting Heap Dumps
● From DDMS
– Select your process
– Click toolbar button
● From Java
– android.os.Debug
– dumpHprofData()


Loading MAT
● DDMS/Eclipse
– Dump automatically loaded into MAT
● Standalone DDMS
– Run hprof-conv on HPROF file, then open in
MAT
● Java
– Copy file from emulator, run hprof-conv,
open

Finding Your Leaks
● Completely Closed Application
– All activities destroyed via BACK (or equivalent)
– In theory, none of your objects should appear
– Open the Histogram
– Enter package in “Regex” (com.yourfirm.*)
– See what crops up
● “Merge Shortest Path to GC Roots” context menu,
excluding weak references, to find out what is
holding these Copyright © 2011 CommonsWare, LLC
things

Finding Where The Heap Went
● Live Application
– Finding out where all the RAM is going
– Back in Histogram, sort by # of objects
– Looking for unusual stuff with lots of objects
● Bitmaps
● Your objects
● Objects from third-party JAR


Finding Where The Heap Went
● Live Application
– Bring up the Dominator Tree
– Sort by shallow heap (objects' own memory) or
retained heap (memory object is responsible for)
– Again, hunt for unusual stuff with lots of heap


Limitations
● Only Tracks Bitmaps on Honeycomb
– Previously was “native” memory, counted
against heap but not visible to MAT
– Recommendation
● Focus MAT use on Honeycomb
● Secondary usage on earlier OS levels


Tuning Android Applications (Part One)

More Related Content

Viewers also liked (19)

Similar to Tuning Android Applications (Part One) (20)

More from CommonsWare (20)

Recently uploaded (20)

Tuning Android Applications (Part One)