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)

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (7)

Similaire à Tuning Android Applications (Part Deux)

Similaire à Tuning Android Applications (Part Deux) (20)

Plus de CommonsWare

Plus de CommonsWare (20)

Dernier

Dernier (20)

Tuning Android Applications (Part Deux)