Transcript
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
>> 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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
[ Applause ]
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[ Applause ]
>> 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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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 [laughter].
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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 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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
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 ]