Achieving All-day Battery Life

JON ANDREWS: Good morning.

Thank you for coming to see our session on achieving all-day battery Life.

It's an area I am really excited to get to talk to you about. My name is Jon Andrews from Core OS, and my colleague, Soren Spies, will also be joining me.

So I hope that you all charged your phones last night and didn't get to see this this morning.

We want you to see this much later in the day.

In fact, we'd like you to see it even later than you've been able to see it to date. We are going to walk through some aspects of achieving all-day battery life under iOS.

We will cover what users expect from all-day battery life, computing energy in general, improvements we've made to the OS in terms of energy, your role in helping us and the customers achieve all-day battery life, and then Soren will give you a much deeper dive on how your software can be modified in order to help achieve those goals.

So let's look at what all-day battery life is.

Users don't just use their phone for eight or ten hours in one go.

They actually spend some intense time using it, maybe in the morning, as they are commuting to work, and then the phone's pretty much idle, and then it's doing some background work, some maintenance work, talking to the network, maybe downloading your mail.

But these kind of patterns go on throughout the day, with bursts of workload and then some periods of idle.

And in order to achieve all-day battery life, you really want to keep that low.

So the average energy during the day is low.

And that's what we are looking for in efforts from you and we have been looking at in the OS. So let's look at the fundamentals of how you compute energy.

Energy has two components, power and time, and the time element is often one that is forgotten.

You can do a really intense operation that uses a lot of power, but you want to know how long you are doing it for. If we look at standby, it doesn't use much power, but you are able to stay in standby for a very long period of time.

Playing audio is one of the other very low power use cases that we have on our device, and that's why we are able to offer great playback time.

But as you get further up into the more intense workloads, you use more power and, therefore, we do expect the time you use the device to decrease.

So it's pretty easy to achieve all-day battery life if your workload looks like idle. And that doesn't mean you can't have it be really intense and have high power bursts, as long as the average is low.

Now our devices are getting increased dynamic range.

We are starting to get close to MacBook territory, where you can get a huge amount of performance out of the system, so you want to use it very carefully.

The other thing to remember is that as we increase the dynamic range, the efficiency of our hardware gets better with every generation. So we are going to give you a better ability to achieve those low-power operations, but you can also make use of the higher peak performance for intense operations and a snappy user experience.

So let's now look at that from an app life cycle perspective.

The area under this graph represents the energy used by an application.

You launch the application, and there's some work that goes on, to initialize your application, maybe you have some animations at the beginning.

And then there's some bursts of activity as your user interacts with your application.

There's always some fixed cost here that you need to keep in mind, and that's the one that the system and, you know, the frameworks are using, and the user workload is then on top of that. Of course, the user finishes using your application, and you want to do some operations as the app goes into the background, and then ultimately, your application is suspended.

But here you can see there's the time element, with both the fixed and dynamic costs.

Now, we also need to think about that just from a system perspective too.

So let's look at what a system looks like in standby.

Most of the components here are in some form of sleep state.

The display is off, memory is in sort of a refresh mode and using actually very little power, and some of the radios are on, just to allow them to accept incoming traffic and wake the system up. This is a great low-power mode. Then we talked about user idle, and here more components of the system are awake.

You can see that the display is on and active, and that brings up a certain amount of soft systems with it.

The other components, like the CPU and GPU, are mostly inactive and have small periods of inactivity, so the cycle here is really low.

If we were to animate that, and show you what the energy would look like, you get this really nice slow drain on the user's battery throughout the day, and hopefully now this is going into the evening and you are going to bed plugging your phone in.

However, if you were to program an intense game, 3D game, you are making the most use of our system.

You've really got all the components lit up, you are probably using the CPU a lot in order to feed the GPU for some complex rendering, and you've got the audio system up because there's some game audio that you want to play.

So you'd expect that the power used is higher and the time that the battery will last is shorter. So there's three components to a very simple strategy that we have for optimizing for energy.

You want to do less work.

And you want to then think about whether that work needs to be done now or whether you could do it later.

And then when you eventually do that work, you want to do it as efficiently as possible. Soren will go into more details on this in the next part of the talk.

So let's talk about what we did in iOS 9.

We already had best-in-class battery life.

However, we really thought we could do better, and our customers wanted us to do better.

You wanted us to do better.

So we set out to improve battery life on our existing hardware, offering up to an hour of additional battery life by optimizing the OS and many of the applications that are integrated inside it.

Now, this may seem familiar to some of you because we did this, a similar effort, in OS X Mavericks.

We eliminated polling from applications, frameworks, drivers. We optimized the kernel. We applied our quality of service to threads, adopted more NS operations, scheduled IO with a correct quality of service. We coalesced timers to reduce the amount of wakes on the CPU and rate-limited applications with things like App Nap.

We reimplemented our CPU power management so the overhead of achieving those powers from a system perspective were significantly lower.

Then we added what turned out to be a really popular feature in adding the "Significant Energy" identification to the battery menu so you could see which applications were drawing a lot of power from the battery. So going back to iOS now, look at how we applied those, we really focused on the iPhone.

That was a device that we got the most feedback that people wanted to improve battery life.

However, these improvements applied to all our iOS products, to some extent.

Now, let's go through those three components to the strategy.

Doing less work. We want to, again, optimize for the idle workloads and particularly looked at the sleep timers, the amount of time the system takes to go to sleep after the user is finished interacting with it. Those are now optimized based on what the user was doing with the device.

Did they actually not interact with a notification or did they interact with it? So we reduced the number of CPU wakes in idle, and then we've added a pretty cool feature in terms of face-down detection.

So if you have the phone with the screen toward the table, say, and a notification comes in, the screen won't light to process that notification. We'll do the minimal amount of work to have the system ready so that when the user picks the phone up, the notification is available to them.

So now moving on to doing work later.

We've made a lot of effort to defer work until the device is plugged in.

There's no point doing background operation, maintenance operation, that the user doesn't need right now. They may be a daily activity. You can do that when they charge the phone because we know they are going to charge it at some point during the day. And we can also, therefore, defer networking to when you're on Wi-Fi because people charge on their Wi-Fi. And then we've leveraged the persistent connection API even more so that when the radios are on, we are doing work that's appropriate, even if the radios came on to do some background work. Now, it's all well and good to do that work, but we want to be able to do it as efficiently as possible.

So we made a number of changes. We've optimized our iOS and networking stack to work best with LTE networks and specifically our own LTE radios.

We, again, optimized our power management to reduce the overhead of keeping the system in its low power state.

And we reduced the cost of our own logging mechanisms so that they don't interact with the system. And, of course, we continue to optimize our numerics libraries so that they are best optimized for each piece of hardware.

And there's a session, I believe tomorrow, on that.

So we talked about user feedback and how that was added in Mavericks. We already had the battery setting, which showed you application usage and allowed for -- gave you information around environmental factors and suggestions for the user as to who to improve battery life.

We've gone one stage further here and added per-app screen on and background time to this setting panel.

So you can see there's a control in the corner there -- let me go back and forward -- you see that small control that allows you to switch mode here.

And then we've added Low Power Mode.

This is a user preference that will extend battery life.

It limits CPU, restricts background operation so that the background app refresh mechanism we introduced a few years ago is disabled in this mode.

We turn off discretionary and background work, so if you have downloads that are scheduled in the background, they won't happen until the user comes out of this mode.

And mail fetch is disabled. People get lots of email and therefore it's a big drain on their system.

We talked a little bit about OS. Now let's talk about some things we are going to give you to help improve battery life.

Well, we've brought the energy gauges that we had in OS X over to iOS, and we've done that in a rather thoughtful way in bringing gauges that make the most impact on iOS. So we've added a location instrument in addition to the other instruments that are there. We've also written an entirely new iOS Energy Guide that's up on our website, alongside an improved OS X Energy Guide.

Now, what can you do with these instruments? We want you to go and optimize the power of your application.

Let me just give you a very simple example.

If you are playing full-screen video, we have an optimization, like many of the TVs you probably have at home, that reduces the backlight, adjusts the gamma to compensate, and gives the same visual image.

Now, that is a small reduction in energy, but because of the time component, the energy saved is pretty substantial.

And we can get an additional hour of battery life if you're watching full-screen video, just from this simple mechanism.

However, if you put any UI on the screen, that mechanism is disabled, and we've seen applications that have full screen, fully transparent UI layers that completely disable this mechanism and therefore give no benefit to the user. Now let's just talk about OS X for a moment. We talked a little about iOS. We introduced the MacBook earlier in the year. That's our first fanless system and, therefore, it is somewhat thermally constrained. It's designed to work best with really bursty workloads.

We've optimized the OS to work hand in hand with that machine.

So you should be tagging any work with the appropriate thread quality of service. Use the gauges and instruments that we already have available on OS X. And then make sure you've prioritized your work using NSOperation and GCD. If you have work that's user initiated, make sure it's tagged as such, but if it's background work, tag it as that, and the OS will schedule that work to give great performance and also be able to manage the power and thermals of that device. Okay. So, just to recap, energy is power times time. Always remember that time component when you are thinking about optimizing energy of your application for all-day battery life.

The hardware is getting a larger dynamic range. So when you are doing operations, really think about how you are doing them efficiently, when you are doing them, and do you, in fact, even need to do them at all? And make your application as low power as possible on an average so that you are able to achieve all-day battery life.

And now I'm going to hand it over to my colleague Soren who is going to go into more detail.

SOREN SPIES: Good morning. Thank you. Really glad you're here to learn about energy efficiency, hoping to empower you so that you can understand how your code is at the center of all-day battery life.

We are going to talk about two big things, but first we are going to start out with some principles about how what Jon talked about, and we are going to tie that to the user and how the user is the key to getting the right time scale in your app. We are going to talk about where energy goes, in particular on CPU and GPU is important for both OS X and iOS.

Throughout this part of the talk, I am going to be explaining to you how to achieve low average power so that you do get that all-day battery life. We are also going to talk specifically about iOS. There's a number of hardware components in our iOS devices that you can take advantage of, which you need to be careful about in both the power and time components so that you do get that all-day battery life. And then finally I will talk a little bit about how you can integrate this understanding into your development process so that each day you are thinking a little bit about energy.

Before I go a little bit farther, I can't see too well out there, but can you raise your hand if you have an LED light bulb somewhere in your home.

Okay. You know about LED light bulbs. Good work. You probably still have a few incandescents left. I know I do. I recently replaced the ones in my fridge. That's an interesting place to put LED light bulbs. Raise your hand if you leave your lights on all the time when you are not home. Okay. We have one person who does that, and he's my office mate, so I am going to give him a hard time .

He's not even the one who leaves his light on in the office. Okay. So key here, when we switch to LED lights, we bring the power down, but we don't just leave them running all day. We still turn them off so we get the time down. And there's probably a lot of equipment in your houses, networking, maybe DVRs, even computers and servers, that is running all the time, and you might not think about it because it doesn't light up like a light. But I am going to try to help you think about that better in software because software ultimately controls all the light switches in our hardware, and we've got to get those light switches off most of the time in order to get all-day battery life.

So let's talk about the strategy.

Ultimately, we want to be doing user-driven work. We want the user to be benefiting from that energy in the battery. They own it.

There's a lot of times when software is like, oh, I have something to do right now. Can I do it? Oh, yeah, let's do it. Let's do it again.

Don't. Just don't.

We've got to eliminate any kind of polling or timers. Computers operate so much more quickly than people do -- literally between keystrokes. Even if you are a super-fast typist, 100 words a minute, between keystrokes at a microsecond scale, we can idle parts of the system. The processor can actually go to sleep between keystrokes, and typically, you know, click or tap, there's a lot of computer time between user interactions. So you want your software to not be trying to run at computer speed unless it's doing work directly for the user.

So you want to respond to the user. That's great. Use all of our super-powerful hardware, and then back to idle, totally flat, zero.

Jon talked about delaying work. A lot of times, you can actually delay work indefinitely. Do I need this right now? I don't need this right now. Maybe it can wait a little while.

Then it turns out I didn't need that after all. That's less work.

But also if the user doesn't need it right now, there's a great benefit in deferring it, in saying hey, system, please do this, but anytime in the next hour, ten minutes, any kind of leeway you can give, whether it's a timer or whether -- although, hopefully, there's no timers -- or just a download and upload, because then the system will schedule it with other work that may otherwise happen. So you can kind of batch things together.

Finally, batching is important for getting efficiency. You want to turn on that hardware, there is some cost to turn it on, you want to use it before you turn it off. So you want to do as much work as you can when you manage it turn it on. Again, bring down the power when we can, but really pull in the time is a critical factor.

And this is an interesting key message that I want you to get. We have all this power available, but you just cannot run it all day on a battery. The device will get too hot and the battery will not last.

So what we really want you to think about is a 10 percent load on the system, total system load, which is not just your software, but anything you could do, how can you make that 1/10 or 1/100 of what you could possibly achieve to shrink it down? That's when you are on screen. When you are in the backgrounds, we want much less.

So here's some bad news.

Across all of our hardware -- and I did some research on this, and people are like oh, it's not exactly right. That's not the point of this talk. The point is to get you to think about this.

Approximately 5 percent of that 10 percent load is just turning on the display.

Now, having the display on is good because it means the user is getting some value from the system, hopefully, it's not just a notification.

And then there's this 10 percent goal, and our average is to be between those. It sounds like you only get 5 percent. And that's true on a long time scale. But on a short time scale, go for it, 100 percent, give us all the work you've got, with priorities, and we will schedule it.

That's that. You've got to get it between 5 and 10 percent. Now, let's talk a little bit about CPU and GPU. These are the biggest energy consumers on OS X. They are the most dynamic. We have very powerful multicore CPUs, massively parallel GPUs, we can do all kinds of work.

However, it does consume the battery and energy in general if you are plugging into the wall.

So you can see here we've got a significant amount of work. We've got the CPU running, we've got the GPU running for a while, and in fact, this is not going to last all day. If this pattern continues -- and patterns are very important in the way you work -- if this pattern continues, we are not going to get all-day battery life. The average power is too high.

So what does it look like if we just wake up the CPU? Is there work to do? Is there work to do? Is there mail? Did the user tap? Anything happen? Hey, server.

Let's not do that. When we wake up the CPU and GPU, we take a significant amount of energy to ramp it up -- zooooop! Is there work to do? I don't hear any work.

Zoooop. But all those triangles as you can see, even the iOS triangles, are taking up a significant portion of that 5 to 10 percent range.

Try not to wake up unnecessarily.

On OS X, if you wake up the CPU all day, you will in fact not achieve all-day battery life, even if you do not work, even if you just check for work. Don't do that. The GPU is a slightly different time scale monster, but this is way more often than you need to wake the GPU, even for really nice graphics. Right? The GPU can do tons of work in like 1 millisecond, then there's 15 milliseconds before the next frame is needed. Now let's talk about performance. You've hopefully are here because you care about energy performance, but time performance where you just do things quicker, which is just good for users and in general, is also key to energy efficiency. Let's talk about why.

Here's a workload. This is a fixed workload. This is not a continuous state of being. I just needed to do this work and then get it done.

Pretty big workload. I could probably optimize my code. I could look in my inner loops and pull stuff out and do less memory accesses and traditional performance work.

So I get a more efficient implementation.

The power did go up. However, the time is now so much shorter that it's a significant energy win. This is good. But we can do better. We can parallelize the work. We can use multiple cores, right? And finally, we can really go crazy and fire up the GPU. Now, the good news is you typically don't need to write this optimized code, but you do need to look for this optimized code. You need to find those optimized numerics libraries.

We have a link at the end for the session and for our energy doc.

You need to find the right data structures, right? You need to look at your app and say why am I churning all the time? What could I be optimizing on the regular old time component? Something important in this graph.

The lowest power solution, which is that naive implementation where the system is like oh come on, you're just waiting for loads and stores all the time, you've got one core running. If we get multiple cores running, then we are really using the system. But just one core? It's low power but has the highest cost because of that time component.

Now let's explore more about why that is. There's a significant fixed cost to running any part of the system, whether it's CPU, GPU, or anything else.

That fixed cost adds up over time. The sooner you can turn off that fixed cost, the better.

Here I added a little extra fixed cost for the GPU because, in fact, there is some more fixed cost for using the GPU, but look at how much less energy is consumed in the green part when we pull the time in.

Key lesson: Fast is also energy efficient.

But don't forget to prioritize.

Now let's see if these fit under the line.

Here is our naive implementation. Anybody that's had some high school geometry is going to know that's not going to fit under our -- we are going to pull it down to the average. This is no longer power times time. It's just average.

It's not going to fit. But what about the other ones? Hey, look, efficient! That's better.

But still not that good.

Parallel are almost under the line, but that CPU/GPU one, that actually fit because the time was so short. Power was very tall, but the time was very short. That's how you should design your apps, but don't do it over and over and over again. Wait for the user before you do it.

Now let's switch gears a little bit. This is all GPU and CPU applies to OS X and iOS, but it's especially important on OS X, and we measure basically our energy impact on OS X both by CPU instructions they consume but also by the number of times you wake the system.

And let's switch over to iOS. iOS devices not only have CPUs and GPUs that are quite powerful, but they also have networking, location, and this ability to run in the background.

The networking has very high costs, big networking hardware, and it turns out that it has some significant time components that you need to think about.

Location is a wonderful feature, it's great to use, but it is designed for, you know -- I'm looking at the map and watching the dot. I am going to walk across the stage and the dot is going to move. I am like wow, that's really impressive that it can tell I am walking across the stage.

Unfortunately, that API is very easy to leave running, even when I am not looking at the map, so we need to -- we improve the API, but we are also needing you to only use location for the shortest period of time that you need.

And finally, any time you are operating in the background, that is causing a -- the device to stay awake, and that adds up. Every time I leave your app, I press the Home screen, you run for the background, maybe a little bit, maybe a long time -- we want to eliminate that as much as possible because we want the device to get nice and sleepy so that we only have to leave the RAM and radios in a very low-power mode. Let's talk about networking.

There's some orange on the slide. That orange is not good. That orange is the overhead.

Here's what happens when you want to send some data over the network, especially on a cellular device.

The system says, oh, look, I have to send this data right now because the app told me to.

Hasn't tagged it as a background work, so I can't delay it. Got to do it right now. We are not connected. We are connected with an inbound connection to the cellular system, but we don't have outbound.

So hold up.

Find a cell tower. Okay. Got the cell tower. That one's not so good. Let me try another. Oh, okay, this cell tower's really good. We got the connection going. Great. I am going to send this data. Okay. I sent the data.

There's no more data to send, but I have this connection. It was expensive. I turned it on.

And the way the cellular network works, I have to leave it running for at least a second or two.

It may only take a few milliseconds to send the data, but it can take up to ten seconds of staying connected to the network. Obviously not as high power mode, but it is still much, much higher than idle waiting for incoming connections.

So that overhead is a significant energy impact. It doesn't matter how much networking you are doing. If the radios are off, we have to fire them up and leave them running for, in some cases, a thousand times longer than you actually needed to send your data. And there's no way that power is significantly over our low power target. You cannot leave the radios on all the time and achieve all-day battery life.

This is bad news for chat apps. The good news is for chat apps is the users don't actually tap on their phones for ten hours straight. They can't.

So as long as you are wise about if there's not live chat going on, let the network go down, then you can get all-day battery life. How do we fix this? How do we make this better? So this is not all-day. It's too tall.

We fix it by coalescing, bringing it together, putting it into a batch of work.

So in this particular case, we are going to bring the future work into the old work. Now, it may be that the future work is actually more important, so you would delay the old work. That may be easier to do. Whichever one is more important. But if you know there's two pieces of work, the goal for your apps -- which you can achieve now because we have these nice new tools that will show you, basically, the new tools are these graphs in Xcode live on your software. It's really good.

You can look and say why am I doing all this unnecessary -- maybe not unnecessary -- why is my networking pattern inefficient? Why is it spread out? How can I pull it together? And then we can actually get to that target: average low power. That means all-day battery life.

So to sum up the networking, you want to do less work in networking.

So you've got to design your system correctly. Even if you do networking once a minute, oh, it's only a few seconds of overhead, that adds up. Please, unless the user is requesting you access the network right now, don't access the network until there's something really important. In terms of design, anything that you can do to offload to the system and let the system decide when, give it some variance of in the next 10 minutes, the next hour, the next 24 hours, that will allow us to batch it together for you, so you offload that networking. We will wake you up and call you back when the work is done.

A lot of times, you can wait on the work. Background update, NSURLSession has this feature. Just wait, defer it. Go ahead and queue it up, that's fine, but don't force it to happen right away.

And these notifications, notifications are great, but they can get out of control sometimes. And on the server side -- remember I mentioned that we are always connected to the server for inbound connections? Jon mentioned this also.

Inbound connections are cheap. They are basically always available. So go ahead and send something out rather than polling up. It's better to send something out. But tag those notifications with PushKit with an appropriate priority so we can batch them together. So when I get an instant message, which is important to do quickly, maybe I will also get that notification that there's new content to download into your news app or something like that. Now let's talk about location.

There's two components of location. Now, the good news is the power is relatively low, although if you leave location running all the time, there's very little space to do anything else, so don't leave precise location running all the time. In fact, don't leave any location running all the time unless your app is basically an app that says I live to run location all the time, and the user really wants that. They are going to see you in the battery menu, and it's going to say location background, 25 percent of battery. That won't be good. Unless that's what your application is about. And that is fine.

So precise location is the most expensive. We have to turn on more hardware, talk to satellites -- hey, satellite, satellite, get all the satellites. Oh, okay, good.

Imprecise location is a lot cheaper. We can just say oh, what Wi-Fi network am I on? What cell tower am I near? And then we can actually -- you can see the green is where the system is running, the display is running. We can actually have a system be almost completely off and still track your location, even precise location. It's not free, don't leave it running all the time. Those leaks. I am sure you fix drips in your house, right, especially California residents.

Location can just drip, drip, drip. So let's optimize that. Use it less. You know, if you are going to call start updating location, don't call it right away. There are some apps when I launch the app, I want my location. I want to know what buses are coming when. Right? That's fine. Food around me dot app, awesome. Launch, get location. Otherwise, wait for the user to do a search or whatever you need to do.

Then as soon as the user is done with that location, you've got whatever precision you want, go ahead and call stop.

For iOS 9, we've introduced a new API that helps you do this. It's called request location.

It does the start and the stop, makes sure you get the appropriate precision, and you don't have to manage the start and stop. Only available on iOS 9, so you're going to need to keep doing the right thing for the older OSes. We have a location talk linked at the end of the slides. We are also changing how background location behaves in the system, so your app may have permission to use background location, but there's going to be a little bit more interaction with the user before that permission is granted, and to be careful in your app so you don't accidentally use it in the background, keep the property allows background location updates, keep that set to false except when you are actively doing it in the background.

Just be conscious of when you turn the location hardware on. You are actually powering up, like turning on the light switch, it's a very easy switch to leave turned on. And then when you are actually using it, bring that power down. So we talked about time component, pull the time in, pull the power down, and I mentioned that we can actually offload, so let's say I am doing a -- I like to bicycle. I can track my bicycle riding, you know, very accurately. But the hardware does it rather than the software. So defer those updates, so every 15 minutes or so it will call you, hey, look, here is all the tracking information, but most of the system and your software is completely asleep, and just the location chip is running.

Finally, our third area -- and these are really the three things that we want you to be doing in terms of debugging your software -- you know, reduce networking, reduce location, and background running. This is just energy that the user typically doesn't see, right? They may appreciate that the app is up-to-date when they launch it, but try to use background app refresh. Try to give good, big leeways. If you send notifications and they get ignored, that's actually lighting up the screen, it's firing up the network, and this just -- this alone is not going to consume -- I mean, if you do it all the time, it will consume your battery pretty quickly. But it is a -- it's basically just shaving off the energy that's available for other things. It's reducing -- it's basically if I lowered the bar and said you've got to get under 9 percent instead of 10 percent. We've got to get rid of -- and that's 20 percent worse because you only have 5 percent to work with on average.

Just make sure you are not running in the background. How do you do that? Any time you call start background task, we are going to keep the device awake for up to a couple of minutes, so you want to call end background task as soon as possible. There's a great App Guide, in addition to the Energy Guide, there's also an App Life Cycle Guide, and basically when you get that message that says hey, you are going into the background, that's fine.

Do your UI state-saving right there. Talk to UI, please save my state. If you've got significant data you need to save, go ahead and fork off a background operation, but make sure that all code paths call end background task. Do not leak background activity. And if you've got networking to do, like maybe that saving to the disk, that's probably going to happen, that's fine. Network activity -- this is a great opportunity to offload that networking to the OS. Hey, I have this networking, it needs to happen but it's not time critical, just do it whenever you have a chance within some time scope. That gives the system the opportunity to optimize.

This is also a good thing at design time, that you can design your app to be more flexible in this regard. This is my ideal app. Jon showed a great slide, sort of a typical app that does a lot of work when you launch it.

My ideal app barely does any work when you launch it. Then it doesn't do any work until the user actually interacts. Then it goes crazy! Lots of work! Let's do it! Here's all the work. Prioritized, please.

And then it's done and it goes back. It's nice and idle.

And that you can topple that Transamerica pyramid down, and it will fit under the line.

So how is your app doing? We really want you to go home, run these new tools. Check out your app, run it through all its paces. Because these tools will only show you what you ask the app to do. Make sure that what the app is doing, in terms of energy impact, corresponds to the user benefit that's being delivered.

So Xcode now has an energy gauge for iOS as well as OS X, and it highlights exactly the things I just talked about, which are CPU, networking, location, background.

Get all that networking coalesced, all that location under control, all that background activity eliminated. So come to our next talk, learn about that.

So as you are designing your next feature, designing your next app, think about these costs. Raw CPU power, CPU patterns and GPU patterns. Am I waking up and going to sleep a lot? Can I make it more constrained? Anything that kind of blinks -- some of you probably remember the blink tag from the early web pages. No blinking, especially at high frequency.

Anything faster than the user's interaction is high frequency.

And try to set expectations for yourself. Because if you are writing a chat app and you are going to be streaming videos of yourself all day long, you are going to mount it on a new hardware device, that user hopefully is not going to expect all-day battery life from that app. They are going to have to buy a separate phone -- in fact three phones -- so that they can have that running all day. That app is not going to sell well, I am sorry. So plan this when you are like in your business model, be like what is the battery life of this app? Am I using a lot of location, am I using a lot of networking, am I doing these things in the background, because they are expensive. Look at your implementation. Check out the Energy Guide, make sure you're passing the best arguments to the various APIs. Look at your own code. Look at our code. If you see our code doing something strange, file a bug. Finally, look at any third-party code you might be using. Say you have an ad framework. Ads are good, they support our platform, they support you.

However, if they do a lot of downloading, like every ad, download display, download display, download display, and then we're keeping the network on for a long time in between -- not good. Got to take an eye on that. Finally, test. Run these tools on a regular basis and make sure your app is behaving the way you expect it to. If you already did all these things, which I suspect you haven't yet, but maybe you have -- in which case, great work -- go ahead and check out your background update intervals. Can you reduce and give you greater leeway to the system? Can you use notifications more sparingly, especially if you have a VoIP app. We changed our API a little bit. Remember, those incoming connections are cheap, they are not free, and they will cause you to call back, but don't pull out. Don't mess with the display brightness. And drawing is probably the next front of excessive -- I talked about blink, but there's a lot of other drawing things you can do. Last year's talk at these topics, linked at the end, is right on topic for drawing. Got some tools for that too. Finally, we now have Energy Guides for OS X and iOS, so all this information I just presented is fully documented, and we'll continue to update that information on developer.Apple.com. So to summarize everything that we talked about, energy is power times time. You want to pull that in. The power part is important, but it's only important in terms of how long you run it. And we want to get you down to nice low power, and that's the low -- our tools. Our tools have a nice low section, as you will learn in the next talk. That will give our users all-day battery life.

Do less work less often. Do it later.

Do it efficiently.

Here are those links I talked about. Documentation, videos, guides, last year's talks. We've got our standard forums. You can interact with each other. You can contact us, the DTS people. They have my phone number. You don't have my phone number. They do. Talk to them. They can probably help you. If they don't, they will call me or one of my excellent teammates.

Paul is here. His email gets to go on the slide. Related sessions. The very next session, please stick around. We've got networking, we've got some performance, check these out. They are going to help you think about how to optimize all the things I just talked about. Please go optimize your apps for energy.

[ Applause ]