Upload
commonsware
View
106
Download
0
Tags:
Embed Size (px)
DESCRIPTION
from the 2014 Wearables DevCon
Citation preview
Copyright © 2014 CommonsWare, LLC
When Microwatts Are Precious:
Battery Tips for Wearable Apps
Copyright © 2014 CommonsWare, LLC
The Problem: Power
● Wearables = Small Batteries● Classic model: battery size proportional to screen
size● Wearables avoid bulk, make problem worse
● Slow Improvement Curve● Power per unit volume or unit mass getting better● Well behind pace of Moore's Law
Copyright © 2014 CommonsWare, LLC
Presentation Terminology
● Device● Runs a mainstream mobile operating system, designed for
multiple form factors– Today: Android, Tizen– Tomorrow: who knows?
● Accessory● Runs some dedicated OS● Most/all app logic resides on tethered phone or tablet
● Hybrid: dedicated OS, but apps run on wearable
Copyright © 2014 CommonsWare, LLC
Terminology Examples
● Device● Google Glass● Omate TrueSmart● I'm Watch● Samsung Gear 2 / Gear 2 Neo
● Accessory● SONY SmartWatch/SW2● Samsung Gear Fit
● Hybrid● Pebble
Copyright © 2014 CommonsWare, LLC
Sources of Power Drain
● What● Screen● CPU● Radios (WiFi, mobile data, Bluetooth, etc.)● “Disk” I/O● Sensors (accelerometer, camera, GPS, etc.)
● Where● Wearable● Tethered Device (accessory or hybrid)
Copyright © 2014 CommonsWare, LLC
The Real Problem: Time
● Developers Do Not Grow On Trees● Net: Only So Much Development Time
Available for Power Optimization● Must also have time for postage-stamp UX,
integrating with tethered app or back-end systems, and so on
Copyright © 2014 CommonsWare, LLC
The Real Real Problem: Blame
● Blaming the App● “When I use this app, my wearable's battery life
goes down the tubes”● Effect: poor reviews and ratings
● Blaming the Wearable● “I'm always having to charge this @#%@$*!!! thing”● Effect: depressed market for wearables... and apps
that support wearables
Copyright © 2014 CommonsWare, LLC
Measure Twice, Code Once
● Ideal: Low-Level Battery Consumption Data from the Wearable● Accurate measurement of point-in-time power
consumption● Best if part of the wearable firmware itself,
available via tools– …unless you are good with a multimeter and have very
steady hands...
Copyright © 2014 CommonsWare, LLC
Measure Twice, Code Once
● Less Ideal: Accurate Data for Related Platform● Identify device with better battery information with
components of similar style to wearable– Similar: WiFi radios– Dissimilar: screen technology (e-ink/Mirasol vs.
AMOLED)● Measure power drain on the test device, develop
custom heuristics to apply to wearable
Copyright © 2014 CommonsWare, LLC
Measure Twice, Cut Once
● What Would Be Useful: Advice from Manufacturers● Devices with API changes for dealing with power
– E.g., WIMM One and Internet● General “these things are BAD” recommendations
Copyright © 2014 CommonsWare, LLC
Measure Twice, Cut Once
● What Really Happens: Learn From Others' Pain● Find other people who took measurements, or
otherwise beat their head against various walls– Usually by testing smartphone hardware
● Learn how they coped● Implement similar approaches in your app
Copyright © 2014 CommonsWare, LLC
Formal Research
● "How is Energy Consumed in Smartphone Display Applications?"
● "An Analysis of Power Consumption in a Smartphone"
Copyright © 2014 CommonsWare, LLC
Power Drain: Screen
● Component Most Likely to Vary● Manufacturer focus on power consumption● Radical form factors
– Google Glass– E-ink displays– No display at all
● Phone/tablet analogue: ~10% battery life per hour of screen time
Copyright © 2014 CommonsWare, LLC
Power Drain: Screen
● Mitigation● Use notification APIs, if offered
– Versus trying to wake up the device yourself to flash the screen
● Be careful about overriding screen timeouts– Implement your own timeout, if concerned that device
default is too low● Focus on “at a glance” UX
– Wearables not meant for long-term viewing
Copyright © 2014 CommonsWare, LLC
Power Drain: Internet
● Expectation vs. Reality● Expectation: power drain proportional to bandwidth
used– As rough analogue to radio time
● Reality: cool-down period– Full-power radio stays at full power, before going to
low-power, before going to standby– Spends many seconds in full- or low-power after you have
stopped transferring– Net: additional power drain beyond transfer time
Copyright © 2014 CommonsWare, LLC
Power Drain: Internet
● Mitigation: Fewer, Bigger Transfers● Pre-load likely material, even if not 100% certain will need● Think two-way sync vs. independent upload, download
schedules● Cache and upload periodically versus uploading in real
time● Adjust Web service API
– Denormalize– APIs that request arbitrary collection of stuff
Copyright © 2014 CommonsWare, LLC
Power Drain: Internet
● Mitigation: Sensible Network Practices● GZIP● Binary Instead of Text?
– Favor protobuf & Thrift over JSON & XML● Client-side caching
– ETag, If-Modified-Since, and kin
Copyright © 2014 CommonsWare, LLC
Power Drain: Internet
● Mitigation: Synchronize With Other Apps● Try to “warm up” the radios once for all versus
independent behavior● Examples
– WIMM One– Android SyncAdapter– Android inexact alarms
Copyright © 2014 CommonsWare, LLC
Power Drain: Local I/O
● Once Again, Size Matters● More efficient to do fewer larger I/O operations
than lots of smaller I/O operations for same amount of data
● Probably not a major area of concern for wearables– Usually not dealing with lots of data– Exception: images
Copyright © 2014 CommonsWare, LLC
Power Drain: I/O
● Mitigation● Memory caching for reads
– For network, two-tier cache where appropriate● Memory buffering for writes
– Example: logging● Consider I/O optimizing for what the wearable
needs– Example: flat file appending vs. database updating
Copyright © 2014 CommonsWare, LLC
Power Drain: CPU
● Wearables Want to Sleep● Mobile devices have well-established patterns for
turning off cores or putting entire CPU in sleep mode
● Mitigation: Don't Pester the Wearable● Device: frequent wakeups for data sync, etc.● Accessory: frequent pushes of content to the
wearable
Copyright © 2014 CommonsWare, LLC
Power Drain: Sensors
● Amount Depends Upon Sensor● GPS is rather expensive● Camera is expensive, while in use (e.g., AR)
● See What Sensors are “Free”● Example: accelerometer “always on” for detecting
when watch face should light up
Copyright © 2014 CommonsWare, LLC
Power Drain, Accessory Style
● Drain on the Accessory● Updating display contents frequently
● Drain on the App (On Tethered Device)● Same sorts of stuff as for power drain on wearable
device
Copyright © 2014 CommonsWare, LLC
Adapting for Power Management
● Check for APIs for Battery Level● More likely on a device than on an accessory
● Alter Behavior as Battery Drops● Less-frequent updates● Suspend unnecessary overhead (e.g., analytics
logging)
Copyright © 2014 CommonsWare, LLC
UX for Power Management
● Defaults with Control● Steer the user towards power-saving behavior via
sensible defaults– Expectation management
● Allow user to “tune” behavior to be more or less aggressive depending upon wishes
● Remember: this is a new space! You may not know how users will really use your wearable app!– Help users understand power implications of
configuration changes
Copyright © 2014 CommonsWare, LLC
Marketing for Power Management
● Objective: Minimize Blame● Approach: Don't Oversell What Will Get You
Blamed● Keep marketing material in line with chosen
defaults
Copyright © 2014 CommonsWare, LLC
Side Effects
● Techniques Help Everywhere!● Traditional mobile apps
– Still batteries, just bigger● Web apps
– E.g., reduced transfer time
● May Require Server-Side Changes● If it's not your server, can you create an app server
that performs aggregation, etc. functions?