when microwatts are precious: battery tips for wearable apps

Copyright © 2014 CommonsWare, LLC

When Microwatts Are Precious:

Battery Tips for Wearable Apps


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● Google Glass● Omate TrueSmart● I'm Watch● Samsung Gear 2 / Gear 2 Neo

● Accessory● SONY SmartWatch/SW2● Samsung Gear Fit

● Hybrid● Pebble


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)


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

– Google Glass– E-ink displays– No display at all

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


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


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

– 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


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

– 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?

when microwatts are precious: battery tips for wearable apps

Technology

power wearables

power optimization

amoledmeasure power

additional power drain

sources of power drain

analysis of power consumption

power radio stays

time power consumption