When Microwatts Are Precious: Battery Tips for Wearable Apps

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


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


Terminology Examples
●

Device
●

●

Omate TrueSmart

●

I'm Watch

●

●

Google Glass

Samsung Gear 2 / Gear 2 Neo

Accessory
●

●

●

SONY SmartWatch/SW2
Samsung Gear Fit

Hybrid
●

Pebble


Sources of Power Drain
●

What
●

●

CPU

●

Radios (WiFi, mobile data, Bluetooth, etc.)

●

“Disk” I/O

●

●

Screen

Sensors (accelerometer, camera, GPS, etc.)

Where
●

Wearable

●

Tethered Device (accessory or hybrid)


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


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


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...


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


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


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


Formal Research
●

●

"How is Energy Consumed in
Smartphone Display
Applications?"

"An Analysis of Power
Consumption in a Smartphone"


Power Drain: Screen
●

Component Most Likely to Vary
●

Manufacturer focus on power consumption

●

Radical form factors
–
–

E-ink displays

–
●

Google Glass
No display at all

Phone/tablet analogue: ~10% battery life per hour
of screen time


Power Drain: Screen
●

Mitigation
●

Use notification APIs, if offered
–

●

Be careful about overriding screen timeouts
–

●

Versus trying to wake up the device yourself to flash the
screen
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


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


●

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


●

Mitigation: Sensible Network Practices
●

GZIP

●

Binary Instead of Text?
–

●

Favor protobuf & Thrift over JSON & XML

Client-side caching
–

ETag, If-Modified-Since, and kin


●

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


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


Power Drain: I/O
●

Mitigation
●

Memory caching for reads
–

●

Memory buffering for writes
–

●

For network, two-tier cache where appropriate
Example: logging

Consider I/O optimizing for what the wearable
needs
–

Example: flat file appending vs. database updating


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


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


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


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)


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


Marketing for Power Management
●

●

Objective: Minimize Blame
Approach: Don't Oversell What Will Get You
Blamed
●

Keep marketing material in line with chosen
defaults


Side Effects
●

Techniques Help Everywhere!
●

Traditional mobile apps
–

●

Web apps
–

●

Still batteries, just bigger
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?


When Microwatts Are Precious: Battery Tips for Wearable Apps

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to When Microwatts Are Precious: Battery Tips for Wearable Apps

Similar to When Microwatts Are Precious: Battery Tips for Wearable Apps (20)

More from CommonsWare

More from CommonsWare (20)

Recently uploaded

Recently uploaded (20)

When Microwatts Are Precious: Battery Tips for Wearable Apps