When Microwatts Are Precious: Battery Tips for Wearable Apps


Published on

from the 2014 Wearables DevCon

Published in: Technology
  • Be the first to comment

  • Be the first to like this

When Microwatts Are Precious: Battery Tips for Wearable Apps

  1. 1. When Microwatts Are Precious: Battery Tips for Wearable Apps Copyright © 2014 CommonsWare, LLC
  2. 2. 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
  3. 3. 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
  4. 4. 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 Copyright © 2014 CommonsWare, LLC
  5. 5. 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) Copyright © 2014 CommonsWare, LLC
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. Formal Research ● ● "How is Energy Consumed in Smartphone Display Applications?" "An Analysis of Power Consumption in a Smartphone" Copyright © 2014 CommonsWare, LLC
  13. 13. 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 Copyright © 2014 CommonsWare, LLC
  14. 14. 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 Copyright © 2014 CommonsWare, LLC
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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 Copyright © 2014 CommonsWare, LLC
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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? Copyright © 2014 CommonsWare, LLC