iOhYes Retired


A podcast by iOS developers for iOS developers, delivering news, tips, and rants for professional iOS/Mac developers, with something for enterprise and indie developers alike.

Hosted by Darryl Thomas and John Sextro.

← Previous Episode   |   Next Episode →

104: Power Struggles

March 10, 2016 at 3:00AM • 45 minutes • Wiki Entry

Discussion - Energy Efficiency for iOS Apps

Are you telling me I have to worry about my app’s power consumption?

  • This is iOS. I thought Apple was taking care of that for me...right??

What is Energy?

  • Power is an instantaneous measurement of energy at any given point in time
  • Energy is power used over time (Joules measured over watt-hours)
  • Low power used over a long(er) period of time can amount to the same energy expenditure as short bursts of high power (more on this later)

Major sources of energy consumption/power draw

  • Device wake
    • Aside from being powered off, a device in its sleep state is consuming the lowest amount of energy possible
    • Whenever possible, avoid preventing the device from sleeping or forcing it to awaken
    • Use technologies like push and background tasks judiciously
  • CPU Usage
    • An idle CPU uses ~10x the power of a sleeping CPU
    • Just 1% CPU use costs 10% more than idle
    • 10% CPU use costs 200% that of an idle CPU
    • 100% CPU can result in 1000% (10x) power draw compared to idle
  • Networking / Bluetooth
  • Graphics/animation/video
  • Sensors
    • Location (Wi-Fi/GPS)
    • Accelerometer
    • Gyroscope
    • Magnetometer
  • Disk IO. Use batch operation whenever possible

Mitigating energy costs

  • Batching, Batching, Batching
    • Operations have a dynamic and fixed energy cost
      • Fixed cost represents the energy used while the device is waiting to enter an idle state
      • The same amount of work, performed across multiple threads, can have a significantly lower total energy cost compared against single-threaded work requiring a longer time to execute
    • Network and other inter-device (BT, for example) operations require radios to be powered up. Avoid continuous communications and state polling, batching operations whenever possible
    • Defer any operations that aren’t time-sensitive to time that the app will be otherwise active (take advantage of fixed cost you’re already having to pay)
  • Prioritize operations using Quality of Service Classes (iOS 8+)
    • Classes
      • User-interactive
      • User-initiated
      • Utility
      • Background
    • Can be set on both NSOperationQueue and individual NSOperation objects
    • GCD queues can be created with QOS class attributes
  • Use timers efficiently, or better yet, avoid them
    • GCD provides mechanisms you can use instead of timers, for example dispatch_block_wait()
    • If you must use timers (not just NSTimer: basically anything that takes a time interval as a deadline), take advantage of APIs that allow for timer coalescing using tolerances.
  • Minimize I/O
  • React to Low Power Mode (iOS 9)
    • NSProcessInfoPowerStateDidChangeNotification
    • [[NSProcessInfo processInfo] isLowPowerModeEnabled]

Instruments to the Rescue

  • Energy Diagnostics Logging

Other Resources




Alternative show title suggestions

  • Power Draw
  • Contribute to Sleep
  • Don’t write an app
  • (You should) Get off of the main thread
  • They DID bone it
  • I ripped them off

Show Notes & Links Presented by CacheFly

Tweet Shoutouts