Tuning Android Applications (Part Deux)

Tuning Android
Applications
(part deux)

Copyright © 2011 CommonsWare, LLC

What I'll Be Yammering About
● You Missed It
– Traceview
– MAT
● Now
– Battery and Bandwidth
– Top Ten Tuning Tips


Bandwidth &
Battery
Measurement

Bandwidth Issues
● Too Much In General
– Users on metered plans pay through the nose
– Users on “unlimited” plans hit the, um, limits
● Too Much At Poor Times
– While the user is trying to use bandwidth for
other purposes (e.g., streaming video)
– When the user is on mobile data instead of WiFi


Measuring Bandwidth
● Option #1: Find an App
– Bandwidth Monitor
– Traffic Monitor
– Network Traffic Detail
– Etc.


Measuring Bandwidth
● Option #2: TrafficStats
– Static methods to report bandwidth
consumption to date
● Entire device, all networks
● Entire device, by network (mobile data vs. WiFi)
● Per UID (all, TCP vs. UDP)
– Transmit (Tx) vs. Receive (Rx)
– Bytes vs. Segments vs. Packets

Measuring Bandwidth
● Option #1: TrafficStats
– Take snapshots at points in time
● Delta between values = consumed bandwidth
– Two Integration Styles
● In test suites, to determine if your mitigation
strategies are working
● In production, for traffic shaping


Measuring Bandwidth
● Option #2: ICS Settings
– Chart of bandwidth consumed
– Ability to see per-application and set limits
– Downside: hardware only?


Measuring Bandwidth
● Option #3: Wireshark
– Requires rooted device or integration at WiFi
access point
– Gives you full logs of all activity
● Determine not only how much bandwidth, but what
it is being used for


Issues with Battery
● You Get Blamed
– Your app shows up on the battery consumption
Settings screen, users get irritated
● You Want to be Friendly
– Dynamically adjust your behavior to deal with
low battery conditions


Measuring Power Usage
● Qualcomm MDP and Trepn
– Pros
● Highly detailed information, down to the component
and process
● Graphs (on-device) and logs (for offline analysis)
– Cons
● Trepn only works on Qualcomm MDP
● MDP is frakkin' expensive (~$1,400)


● PowerTutor
– Pros
● Free!
– Cons
● Accuracy so-so for Nexus One, worse for other
modern devices
● No logging


● Settings' Battery “Blame Screen”
– If you don't show up here, how bad can it be?
● adb shell dumpsys batteryinfo
– Tons of data
– Difficult to grok


Top Ten Tuning
Tips
(totally)


Measure, Measure, Measure
● Don't Start Hacking Away
– Example: randomly removing accessor methods
● Identify Problem Area First
– What is too slow, or leaking, or whatever?
● Cure What Ails Ya
– Premature optimization helps nobody


Recycling: It's Good for the “Urf!”
● Adapter View Recycling
– Rows in lists
– Pages in ViewPager
● Bitmaps
– If it has a recycle() method, use it!


Activities Stay Active
● Activities Not Destroyed to Free Heap Space
– BACK button, finish(), configuration change
– Process termination (may not call
onDestroy())
● Mitigation Strategies
– Activity recycling
– Time-based belt-tightening


Threads: More Than a Panacea, But...
● The Good
– Move stuff off the main application thread
● The Bad
– Most devices in use still single core
– Threads consume more CPU time
● The Ugly
– Thrashing among too many threads

Robbing Peter to Pay Paul
● Threads
● Caching
– Trading off RAM to save disk I/O, or CPU time, or
bandwidth
– Trading off disk space to save bandwidth, or CPU
time
– Ensure you don't trade too much (whack-a-mole)


Hardware Is Real. Really Real.
● Emulator Is Slower At...
– CPU
● Emulator Is Faster At...
– Disk I/O
– Network (usually, compared to wireless data)
● Net: Test on Hardware Too


Globals, Processes, and Cavemen
● Global Scope: Risk of Memory Leaks
– Tempting as central holding spot for data
– Reason why considered bad form in standard
Java development
● Extra Processes: Just Say No!
– Usually add no value
– Consume extra RAM, CPU time


YAGNI
● You Ain't Gonna Need It
– Downloading and caching data that might not
get used
– Fancy plug-in architecture for an app with no
plug-ins
● Constrained Devices Need Constrained Plans


Don't Be Chatty
● JNI/NDK
– Each context switch from Java to C/C++ (and
back) adds overhead
● IPC
– Every call between processes adds overhead
– Includes sendBroadcast()!
● Aim For Coarse-Grained Protocols


Lather. Rinse. Repeat.
● Keep Testing and Tuning
– Major application releases
– Major OS releases
● Example: rumored AsyncTask thread pool shrinkage
– Major device style releases
● Example: multi-core


Tuning Android Applications (Part Deux)

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (7)

Similar to Tuning Android Applications (Part Deux)

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

More from CommonsWare

More from CommonsWare (20)

Recently uploaded

Recently uploaded (20)

Tuning Android Applications (Part Deux)