• Save
Learn about energy consumption and battery life on Android devices
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Learn about energy consumption and battery life on Android devices

  • 7,551 views
Uploaded on

San Francisco Android User Group hosted an event on March 30th, 2010 with Frank Maker, Eric Jung, and Yichuan Wang, a trio of very smart PhD students, who shared what they've learned about power......

San Francisco Android User Group hosted an event on March 30th, 2010 with Frank Maker, Eric Jung, and Yichuan Wang, a trio of very smart PhD students, who shared what they've learned about power consumption / battery life on mobile/Android devices in their years of research. Specifically, they talked about: Mobile Architecture - Talk about differences with desktop/laptop computers, where power goes, etc. Measuring Power/Energy - difference between energy and power, battery technology, why the problem isn't going away anytime soon Software Optimizations - different ideas you can use to lower the power consumption of your application. Hosted by SUPINFO Sponsored by Sun, O'Reilly, and Marakana Organized by Marakana Video by Max Walker Photography by Aleksandar Gargenta

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
7,551
On Slideshare
7,548
From Embeds
3
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
5

Embeds 3

http://www.slideshare.net 2
http://static.slidesharecdn.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Mobile Energy Consumption Frank Maker Eric Jung Yichuan Wang University of California, Davis
  • 2. Outline • Mobile Platform • Measuring Power / Energy • User Profiles (Eric Jung) • Synchronization Manager (Yichuan Wang) • Optimizations • Research • Q&A
  • 3. Mobile Platform
  • 4. How is Mobile Platform Different? Mobile8 Laptop9 Main Purpose Phone Calls Anything Power Budget (Watts) 3 73 Size (cm) 11.9 x 5.98 x 1.15 2.41 x 14.35 x 9.82 Volume (cm3) 81.84 339.61 Cooling Passive Air Forced Air
  • 5. Nexus One BOM * * http://www.isuppli.com/News/Pages/Google-Nexus-One-Carries-$17415-Materials-Cost-iSuppli-Teardown-Reveals.aspx
  • 6. Apple iPhone
  • 7. Battery Technology[3] • Three main problems • Limited power density for passive air cooled systems • Slow battery energy density growth • 30-40% battery lifetime increase • Capacity degrades over time [1] http://www.nexergy.com/ [2] Intel
  • 8. Energy Budget [1] Average Battery Size: 820 - 1150 mAh (3.7V) Component Power Consumption Cellular Model and RF Amplifier 1200mW Application Processor 600mW Memories 200mW User Interface 300mW Audio 300mW Other (BT, Energy Manager, etc.) 400mW Total ~3W 8
  • 9. Measuring Power/Energy
  • 10. Power vs Energy • Energy is power integrated over time • Electic power is “the rate at which electrical energy is transferred by an electric circuit”10 • Electric energy is the total amount of work that can be done by electrons • Analogy with driving a car • MPH power • Distance energy
  • 11. Measuring Energy • Use a model • Google using this for Power Android Developer Profiler Phone 1 • Battery Simulator • Jeffrey Sharkey used Monsoon GPIB • Digital Power Supply DC Power Supply • Make your own!
  • 12. User Profiles Eric Jung
  • 13. User Protection in Mobile Apps • Mobile Apps should not drain excessive energy • Most mobile apps considered “secondary” • Mobile users want to protect battery life for primary uses like phone call/sms, although this may change • User Context should be included in App Design • User context: Identity (user profile), Activity, Time, Location • Programmers should have potential energy use, potential loss of future phone use in mind
  • 14. User Profiles Vary Greatly • Normalized histogram of 53-day call history for 2 users • Usage pattern varies dramatically 5
  • 15. Different Ways to Look at User Profile • Based on different types of profile measurements • Call arrival prob (top) • Ave remaining minutes (bottom) • Data, SMS use not shown • Use user-profile to predict/ reserve battery energy
  • 16. Energy Threshold • For each time t, find energy level that satisfies all future voice with some probability based on history • Example: 85% Threshold based on “binomial call” assumption • 85% probability that calls from history are served • Measures how much battery life is needed
  • 17. Two Example Days • Depending on call day, different actions might be better Light Call Heavy Call
  • 18. Sample App – Data Synchronization • Created sample app that syncs email/twitter • Goal: Balance need for repeated data synchronizations (email, Twitter) with future energy needs
  • 19. Energy Threshold Policy • Policy using energy threshold: 1. Calculate remaining_syncs possible at time t: remaining_syncs = (current battery-energy threshold)/(energy cost to sync) 2. Calculate sync_period given remaining syncs sync_period = (next_recharge-current time)/remaining_syncs Policy: If time since last sync > sync_period, synchronize
  • 20. Simulation • System Parameters: - 16 hour discharge period (i.e. charge every night) - Energy to synchronize measured from voltmeter connected to phone • Compare Markov Decision Process Policy (considered optimal) with threshold 85%, periodic sync policies
  • 21. 20 Min Call Day • Light Call Day: 20 Minutes • On a light call day, we want to synchronize email more often • Dynamic adjust to MDP1 85%  type1 Period  5 Period  10 sync_both 220 220 191 95 mean_tau1 4.35 4.35 5.02 10.03 call load dev_tau1 4.18 4.66 0.16 0.23 minutes t(E=0) 20 960 20 960 20 960 960 20 • Remaining energy E(T) 0.58 0.58 45.33 193.44 lower for 85% • Note: 960 = 16 Hours in minutes threshold • Note 2: Battery is out of 400 (instead of 100) • Syncs More
  • 22. 121 Min Call Day • Heavy Call Day: 121 Minutes • On heavy day, we want to synchronize less to ensure battery life for calls • Dynamic adjust to MDP1 85%  type1 Period  5 Period  10 call load sync_both 23 23 99 59 mean_tau1 39.88 41.43 5.54 11.25 • Periodic syncs too dev_tau1 116.48 119.5 3.25 5.27 much minutes 121 121 82 102 t(E=0) 960 960 566 668 – Battery dies E(T) 0.43 1.52 0 0 before end of day – Calls not all served
  • 23. Things To Consider • User Protection • Ensure that phones reserve resources for its primary use • Resource reserves calculated from phone usage profile • App Specific • Dynamically adjust app processes to user context • What granularity of battery level reserve is needed? • Does app have periodic or one-shot characteristic?
  • 24. Synchronization Manager Yichuan Wang
  • 25. Motivation • 'Internet device' • Direct Interaction vs Data Synchronization  • Data Synchronization as a system service
  • 26. Traditional ways to do Synchronization • Initial effort: to make adoption as easy as possilbe • So what are people using to sync? • Timer • Handler • AsyncTask • Make a optimized version of those APIs
  • 27. Traditional ways to do Synchronization (1 of 3) • Periodically wake up • Pull remote/local changes • Update local/remote data • Optionally update UI to notify user • TimerTask fetchMail  = new FetchMail(); //perform the task once a day at 4 a.m., //starting tomorrow morning Timer timer = new Timer(); timer.scheduleAtFixedRate(fetchMail,     getTomorrowMorning4am(), fONCE_PER_DAY);
  • 28. Traditional ways to do Synchronization (2 of 3) • Handler • private final Handler mHandler = new Handler() {         public void handleMessage(Message msg) {             // Do the deed.             // Repeat every 1 second.             sendMessageDelayed(obtainMessage (TICK_MSG), 3 * 1000);             } };
  • 29. Traditional ways to do Synchronization (3 of 3) • AsyncTask  private class DownTask extends AsyncTask<URL, Integer, Long> {      protected Long doInBackground(URL... urls) {      }      protected void onProgressUpdate(Integer... progress) {          setProgressPercent(progress[0]);      }      protected void onPostExecute(Long result) {          showDialog("Downloaded " + result + " bytes");      }  }
  • 30. New SyncAdapter in Android 2.0 • Google goes one step further • A framework for Account, Contact and Sync management • The new Account&Sync settings • A little rough around the edges
  • 31. Authentication • Starting point: AuthenticationService • listen for intent: android.accounts.AccountAuthenticator • meta-data: unique accountType and other resources • onBind: return Authenticator's binder • Authenticator:  AbstractAccountAuthenticator • Override methods to provide implementation • getAuthToken; addAccount; confirmCredentials • AuthenticatorActivity: The login Screen
  • 32. Synchronization • Starting point: SyncService • listen for intent: android.content.SyncAdapter • meta-data: info about syncAdapter and contact structure • onBind: return SyncAdapter binder • SyncAdapter: AbstractThreadedSyncAdapter • onPerformSync: pull data and update using ContactContract API
  • 33. Internal • ContentService -> SyncManager • ServiceManager->"Content Manager"
  • 34. Optimizations
  • 35. Parsers [11] • Mainly two types • Tree (ex. DOM) • Event (ex. SAX) • Consider how much of the information is used • Tree pre-parses everything, but is take initial hit • Event parses as needed, but spread out
  • 36. Radios[11] • Check if connectivity is available • Reduce data • Tradeoff computation and communication • Bluetooth slow but, low power • Wi-fi fast, but high power • Can use GZip compression
  • 37. Wake Locks / Services • Be conservative • Give user a choice • Can keep phone on longer than necessary • Consider AlarmManager instead • Do you really need it? • setInexactRepeating • Services should be to allow binning short not daemons
  • 38. Use the Cloud, Luke • More scalable • Offloads power usage • Might be more efficient • Communication • energy cost could be an issue • RESTful interface
  • 39. Profiling • Hit the big targets first • Traceviewer • Consider native code • Recycle Java objects • floating point • Hierarchyviewer • matrices • Decrease height of view hierarchy • long loops • Think like C++
  • 40. Sensors • Different rates available • UI, Gaming, Normal, etc • Almost 10x difference from Fastest and Slowest • GPS • Coarse location much cheaper (10x less) • No satellites, LocationManager keeps looking • Let LocationManager find best one for you
  • 41. GPS Acquisition Time
  • 42. Research
  • 43. Motivation • Industry collects est. 13 million phones each year • Estimated to be only 10% of 130 million taken out of service • ReCellular found 80% were still functional • Surveys find people replace about every 4 years • Battery worn out • Want something new
  • 44. Challenges • ReCellular received 1,100 different handset in 2008 • Heterogeneity • Operating System • Accelerators • Radios • Searching configurations for optimal energy point to run repurposed phone at
  • 45. Solution(s) • Artificial Intelligence to find best operating point • Solar panel power supply to remove worn battery • Use offline Markov Decision Process to find optimal point
  • 46. References 1. Cellular Phones as Embedded Systems, Yrjö Neuvo, International Solid-State Circuits Conference 2004 2. Augmented Smartphone Applications Through Clone Cloud Execution 3. UC Davis EEC216 - Professor Rajaveen Amirtharajah 4. Powermonkey-eXplorer, https://powertraveller.com/iwantsome/primatepower/powermonkey-explorer/ 5. Lumedyne V-Power Energy Harvester Technology, http://www.lumedynetechnologies.com/Energy %20Harvester.html 6. Thermo Life, http://www.poweredbythermolife.com/thermolife.htm 7. Geared Turbine, http://www.kidwind.org/xcart/product.php?productid=42&cat=4&page=1 8. http://www.google.com/phone/static/en_US-nexusone_tech_specs.html 9. http://www.apple.com/macbookpro/specs.html 10. http://en.wikipedia.org/wiki/Electric_power 11. http://dl.google.com/io/2009/pres/W_0300_CodingforLife-BatteryLifeThatIs.pdf 12. http://www.recellular.com/images/ReCel_Sustainability.pdf 46
  • 47. Thanks Frank Maker flmaker@ece.ucdavis.edu fmaker@handycodeworks.com Eric Jung eajung@ucdavis.edu Yichuan Wang yicwang@ucdavis.edu
  • 48. Binomial Call Energy Threshold : probability of call arrival based on call profile : random variable denoting call arrival at time t • Assume each call minute is a binomial variable with probability : CDF of remaining call time after time t • Energy threshold :
  • 49. GPS Power Cycling