209.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:00.506 --> 00:00:09.516 A:middle
[ Silence ]

00:00:10.016 --> 00:00:12.000 A:middle
[ Music ]

00:00:12.756 --> 00:00:13.396 A:middle
>> Good morning.

00:00:15.386 --> 00:00:17.946 A:middle
Welcome to "Improving Power
Efficiency with AppNap."

00:00:18.346 --> 00:00:20.366 A:middle
My name is Tony Parker and
I'm a software engineer

00:00:20.366 --> 00:00:21.866 A:middle
on the Cocoa Frameworks
Team at Apple.

00:00:22.036 --> 00:00:25.906 A:middle
So today we're going to
go over three topics.

00:00:26.196 --> 00:00:27.606 A:middle
First, what is AppNap?

00:00:28.296 --> 00:00:29.106 A:middle
Then we're going
to go into a lot

00:00:29.106 --> 00:00:31.036 A:middle
of detail on how AppNap works.

00:00:31.686 --> 00:00:33.896 A:middle
And finally we're going to
cover AppNap and other power

00:00:33.896 --> 00:00:35.996 A:middle
and energy related API.

00:00:36.516 --> 00:00:38.686 A:middle
So first let's talk
about what AppNap is.

00:00:39.386 --> 00:00:42.656 A:middle
So we live in a world
today on OS X

00:00:43.016 --> 00:00:45.266 A:middle
where users expect
both long battery life

00:00:45.266 --> 00:00:47.886 A:middle
and at the same time
high performance

00:00:47.886 --> 00:00:49.286 A:middle
responsive applications.

00:00:49.906 --> 00:00:51.606 A:middle
However, because
it's a multitasking,

00:00:51.606 --> 00:00:54.486 A:middle
multi user operating system,
all apps actually have

00:00:54.556 --> 00:00:59.466 A:middle
about equal access to limited
resources like CPU time, disk IO

00:00:59.466 --> 00:01:01.666 A:middle
and most importantly
for this talk, energy.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:59.466 --> 00:01:01.666 A:middle
and most importantly
for this talk, energy.

00:01:02.246 --> 00:01:06.656 A:middle
So in designing this feature, we
wanted to focus system resources

00:01:06.656 --> 00:01:08.716 A:middle
on the most important user work.

00:01:09.406 --> 00:01:12.026 A:middle
And the benefit of that is going
to be increased battery life

00:01:12.366 --> 00:01:14.116 A:middle
and improved responsiveness.

00:01:14.646 --> 00:01:18.536 A:middle
Now the tricky part of
course is deciding what

00:01:18.536 --> 00:01:22.026 A:middle
that important work is and we do
that with a set of heuristics.

00:01:22.476 --> 00:01:24.756 A:middle
So for example, we look at
whether an application is

00:01:24.756 --> 00:01:26.306 A:middle
in the foreground
- typically the one

00:01:26.306 --> 00:01:28.216 A:middle
with the menu bar -
or the background.

00:01:28.956 --> 00:01:31.066 A:middle
Typically a foreground
application is doing more

00:01:31.066 --> 00:01:32.096 A:middle
important user work.

00:01:32.096 --> 00:01:36.406 A:middle
We also look at the
application type.

00:01:36.776 --> 00:01:38.496 A:middle
So a system daemon

00:01:38.496 --> 00:01:41.156 A:middle
or a background agent is
typically doing less important

00:01:41.156 --> 00:01:43.686 A:middle
work than an application that
the user can actually sort

00:01:43.686 --> 00:01:45.916 A:middle
of see and interact with
on the doc for example.

00:01:46.436 --> 00:01:50.516 A:middle
We can also take into
account the visibility

00:01:50.676 --> 00:01:52.956 A:middle
of your application's
windows on screen.

00:01:53.296 --> 00:01:55.966 A:middle
So an application that has a
window that's completely hidden

00:01:55.966 --> 00:02:00.316 A:middle
by other windows or on another
space that's been moved away is

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:55.966 --> 00:02:00.316 A:middle
by other windows or on another
space that's been moved away is

00:02:00.316 --> 00:02:02.196 A:middle
typically doing less
important work to the user

00:02:02.196 --> 00:02:05.506 A:middle
than the ones it can see
right in front of them.

00:02:05.606 --> 00:02:07.356 A:middle
And also we look at
drawing activity.

00:02:07.446 --> 00:02:09.096 A:middle
So an application
that can update it --

00:02:09.096 --> 00:02:11.376 A:middle
it's updating itself and
displaying new content

00:02:11.376 --> 00:02:12.886 A:middle
to the user, that
might be something

00:02:12.886 --> 00:02:14.886 A:middle
that the user is looking
at and actively watching.

00:02:15.116 --> 00:02:17.546 A:middle
And that would indicate
more important work.

00:02:18.936 --> 00:02:20.796 A:middle
Now even if an application
is completely hidden,

00:02:20.796 --> 00:02:23.896 A:middle
if it's playing audio, that's
obviously also perceptible

00:02:23.896 --> 00:02:25.706 A:middle
to the user so we
count that as well.

00:02:25.706 --> 00:02:28.496 A:middle
And of course, event processing.

00:02:28.496 --> 00:02:31.686 A:middle
User events and events like
hot keys are also considered.

00:02:32.296 --> 00:02:36.406 A:middle
We can also use the existing
I/O Kit Power Searching API.

00:02:36.926 --> 00:02:37.876 A:middle
You might be familiar with this.

00:02:37.876 --> 00:02:39.206 A:middle
It's been on OS X for a while

00:02:39.376 --> 00:02:41.146 A:middle
and it lets you tell
the system you know,

00:02:41.146 --> 00:02:43.426 A:middle
"Don't put the system -- don't
allow the system to idle sleep

00:02:43.586 --> 00:02:45.376 A:middle
because I'm doing something
that I need to finish."

00:02:46.396 --> 00:02:49.066 A:middle
And finally we have a
new set of AppNap APIs

00:02:49.856 --> 00:02:52.726 A:middle
which let you help improve these
heuristics by telling the system

00:02:52.726 --> 00:02:54.386 A:middle
about the kinds of
activities you're doing.

00:02:54.386 --> 00:02:58.396 A:middle
So I want to show you a quick
demo of AppNap in action.

00:02:59.446 --> 00:03:01.276 A:middle
Okay, so here we go.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:59.446 --> 00:03:01.276 A:middle
Okay, so here we go.

00:03:01.276 --> 00:03:03.476 A:middle
If you've ever been to a
presentation like this one

00:03:03.816 --> 00:03:06.196 A:middle
and had trouble following what
a presenter like me is doing,

00:03:06.536 --> 00:03:07.946 A:middle
I've got the App here for you.

00:03:08.076 --> 00:03:10.276 A:middle
And it may also be familiar
to some of you old timers.

00:03:10.906 --> 00:03:12.716 A:middle
As you can see, these apps --

00:03:12.716 --> 00:03:14.196 A:middle
they're 2 copies
of the same app.

00:03:14.516 --> 00:03:16.626 A:middle
It's following my mouse as I
move it around the screen here.

00:03:17.176 --> 00:03:21.226 A:middle
And I also have Activity
Monitor open.

00:03:21.286 --> 00:03:22.896 A:middle
And I want to show you a
couple new things we've added

00:03:22.896 --> 00:03:26.086 A:middle
to Activity Monitor that can
really help users understand

00:03:26.236 --> 00:03:27.566 A:middle
where their energy is going.

00:03:27.566 --> 00:03:28.626 A:middle
So there are 2 columns

00:03:28.626 --> 00:03:30.096 A:middle
in particular I want
to focus on here.

00:03:30.446 --> 00:03:31.736 A:middle
First, the AppNap column.

00:03:32.026 --> 00:03:32.756 A:middle
Now you can see that both

00:03:32.756 --> 00:03:35.786 A:middle
of these applications are
-- say "No" right now.

00:03:36.236 --> 00:03:37.996 A:middle
In fact, one of these
applications is completely

00:03:37.996 --> 00:03:40.466 A:middle
unmodified and the other
one I've explicitly modified

00:03:40.466 --> 00:03:41.566 A:middle
to prevent AppNap.

00:03:42.166 --> 00:03:44.536 A:middle
The other column is
the energy impact.

00:03:44.896 --> 00:03:47.176 A:middle
Now you notice that this
column is unitless and that's

00:03:47.176 --> 00:03:50.086 A:middle
because it's really sort of an
aggregate score of the kinds

00:03:50.086 --> 00:03:53.286 A:middle
of things an application can do
that can cause battery drain.

00:03:53.886 --> 00:03:56.866 A:middle
So I mentioned that visibility
is one of the heuristics

00:03:56.866 --> 00:03:59.366 A:middle
that we use for determining
eligibility for AppNap.

00:03:59.696 --> 00:04:02.096 A:middle
So what I'm going to do is
move my Activity Monitor window

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:03:59.696 --> 00:04:02.096 A:middle
So what I'm going to do is
move my Activity Monitor window

00:04:02.096 --> 00:04:06.136 A:middle
in front of these other
two windows and we'll see

00:04:06.136 --> 00:04:09.306 A:middle
after a few seconds the
system will decide that one

00:04:09.306 --> 00:04:11.436 A:middle
of these apps - the one
that was unmodified -

00:04:11.856 --> 00:04:13.996 A:middle
can go into that AppNap state.

00:04:13.996 --> 00:04:16.146 A:middle
And that's going to
reduce its energy impact

00:04:16.716 --> 00:04:18.685 A:middle
to a much lower level.

00:04:18.685 --> 00:04:20.616 A:middle
In fact here you
see it's at zero.

00:04:21.546 --> 00:04:23.356 A:middle
However, if I just - you
know - move my window

00:04:23.356 --> 00:04:25.676 A:middle
out of the way a little
bit, you see both windows --

00:04:25.676 --> 00:04:28.226 A:middle
or both applications still
appear responsive to the user.

00:04:29.036 --> 00:04:32.146 A:middle
And so the idea here is to
not interrupt user's work

00:04:32.186 --> 00:04:34.926 A:middle
but instead focus in this
case the battery life

00:04:34.926 --> 00:04:37.406 A:middle
on the applications that
are doing important work.

00:04:37.786 --> 00:04:39.716 A:middle
And we'll see what a difference
this makes in a little bit.

00:04:39.716 --> 00:04:42.676 A:middle
Now let's go back to our slides.

00:04:42.676 --> 00:04:45.256 A:middle
So let's go into some
detail on how all

00:04:45.256 --> 00:04:46.686 A:middle
of this AppNap is working.

00:04:47.266 --> 00:04:50.326 A:middle
So first I want to define
a couple terms that we sort

00:04:50.626 --> 00:04:52.176 A:middle
of tend to throw around
a little bit loosely.

00:04:52.536 --> 00:04:56.116 A:middle
Power: so power is actually
a rate and it's the rate

00:04:56.116 --> 00:04:57.356 A:middle
at which energy is consumed.

00:04:57.616 --> 00:04:59.526 A:middle
One way to measure
that would be in watts.

00:04:59.526 --> 00:05:03.836 A:middle
Energy on the other hand is the
stored potential to do work.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:04:59.526 --> 00:05:03.836 A:middle
Energy on the other hand is the
stored potential to do work.

00:05:04.096 --> 00:05:06.576 A:middle
And one way to measure that
might be in watt hours.

00:05:06.946 --> 00:05:09.706 A:middle
So for example let's say I
have a 50 watt hour battery

00:05:10.026 --> 00:05:12.706 A:middle
and I want a 7 hour battery
life from that battery.

00:05:13.056 --> 00:05:16.466 A:middle
Well I can do some simple
division: 50 watt hours divided

00:05:16.466 --> 00:05:20.336 A:middle
by 7 hours and that gives me
a rate of about 7.1 watts.

00:05:20.796 --> 00:05:24.226 A:middle
So what that means is that if
I'm using more than 7.1 watts,

00:05:24.516 --> 00:05:26.746 A:middle
my battery life will
be less than 7 hours.

00:05:27.026 --> 00:05:29.526 A:middle
And if I use less
than 7.1 watts,

00:05:29.736 --> 00:05:32.366 A:middle
I will get a longer battery
life of above 7 hours.

00:05:33.266 --> 00:05:36.706 A:middle
Now this 7.1 watts has to power
the entire system on a laptop.

00:05:36.936 --> 00:05:40.386 A:middle
That includes the screen and
the backlight, the GPU, network,

00:05:40.386 --> 00:05:42.906 A:middle
storage, memory and finally CPU.

00:05:43.786 --> 00:05:45.236 A:middle
Now you may look at
this list and think,

00:05:45.236 --> 00:05:46.796 A:middle
"There's some big
ticket items on there

00:05:47.086 --> 00:05:48.746 A:middle
like the screen and the GPU."

00:05:49.056 --> 00:05:49.906 A:middle
And you'd be right.

00:05:50.056 --> 00:05:51.926 A:middle
Those do use a significant
amount of power.

00:05:52.276 --> 00:05:54.956 A:middle
However today we're going
to focus instead on the CPU.

00:05:55.246 --> 00:05:56.176 A:middle
And that's for two reasons.

00:05:56.526 --> 00:05:59.026 A:middle
First, as software engineers,
this is the thing we're going

00:05:59.026 --> 00:06:00.356 A:middle
to have the most impact on.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:59.026 --> 00:06:00.356 A:middle
to have the most impact on.

00:06:00.776 --> 00:06:02.146 A:middle
But second and most importantly,

00:06:02.146 --> 00:06:04.926 A:middle
the CPU actually has the
highest dynamic range

00:06:05.036 --> 00:06:06.316 A:middle
out of all of these components.

00:06:06.786 --> 00:06:08.726 A:middle
So let me show you
what I mean by that.

00:06:09.736 --> 00:06:12.736 A:middle
If we look at the power
usage of a modern Intel chip,

00:06:13.336 --> 00:06:15.536 A:middle
you can see at its most
idle state we can use

00:06:15.536 --> 00:06:17.296 A:middle
as little as 0.4 watts.

00:06:18.316 --> 00:06:20.286 A:middle
However, if we're
executing any code at all

00:06:20.286 --> 00:06:21.756 A:middle
at the nominal frequency
of the chip,

00:06:22.256 --> 00:06:24.476 A:middle
we're going to go all
the way up to 15 watts.

00:06:24.936 --> 00:06:26.686 A:middle
Now this is just for the CPU.

00:06:27.066 --> 00:06:29.946 A:middle
So here you can see, if
we had a budget of 7 watts

00:06:30.076 --> 00:06:32.776 A:middle
and we're running a 15
watt CPU, we're not going

00:06:32.776 --> 00:06:34.836 A:middle
to get the battery life
of 7 hours that we wanted.

00:06:35.336 --> 00:06:37.556 A:middle
And furthermore, if we're
running at turbo frequencies,

00:06:37.836 --> 00:06:40.046 A:middle
then it goes all the
way up to 25 watts.

00:06:40.916 --> 00:06:44.386 A:middle
So there's a gigantic difference
between the low power idle state

00:06:44.656 --> 00:06:47.416 A:middle
and the high power executing
code or turbo states.

00:06:47.896 --> 00:06:49.666 A:middle
And so that leads us
into the three key rules

00:06:49.666 --> 00:06:50.836 A:middle
of extending battery life.

00:06:51.276 --> 00:06:52.606 A:middle
The first is that
we need to stay

00:06:52.606 --> 00:06:56.276 A:middle
at that low power 0.4 watt
idle state as long as possible.

00:06:56.916 --> 00:07:00.366 A:middle
And to do that - Number 2 - we
need to avoid unnecessary work

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:06:56.916 --> 00:07:00.366 A:middle
And to do that - Number 2 - we
need to avoid unnecessary work

00:07:00.726 --> 00:07:02.546 A:middle
like drawing a pair of
eyes in the background

00:07:02.546 --> 00:07:03.506 A:middle
when you can't even see them.

00:07:04.066 --> 00:07:07.436 A:middle
And third, when we do work
which is okay from time to time

00:07:07.436 --> 00:07:09.986 A:middle
if the user's asked us to
do it, we need to return

00:07:09.986 --> 00:07:12.996 A:middle
to that idle state as quickly as
possible so that we can remain

00:07:12.996 --> 00:07:14.606 A:middle
in that 0.4 watt idle state.

00:07:15.146 --> 00:07:18.206 A:middle
Now you might be surprised

00:07:18.206 --> 00:07:20.536 A:middle
at how quickly we can actually
switch between these states.

00:07:20.766 --> 00:07:21.906 A:middle
So here I've got a use case

00:07:21.906 --> 00:07:25.936 A:middle
of visiting the www.Apple.com
website in Safari on Wi-Fi

00:07:25.936 --> 00:07:28.036 A:middle
on my demo machine, and
what I've graphed here

00:07:28.036 --> 00:07:30.666 A:middle
on the vertical axis
is CPU activity.

00:07:30.906 --> 00:07:32.486 A:middle
This is not the same
as CPU time.

00:07:32.716 --> 00:07:36.236 A:middle
For one thing, it's the whole
CPU: not just one process.

00:07:36.236 --> 00:07:38.116 A:middle
And also, it's more
a measurement

00:07:38.116 --> 00:07:40.576 A:middle
of how long we could stay
in that idle state instead

00:07:40.576 --> 00:07:42.436 A:middle
of how much time
we were executing.

00:07:42.876 --> 00:07:44.456 A:middle
So at the bottom
at zero percent,

00:07:44.726 --> 00:07:47.066 A:middle
that's our most idle state
for the entire sample period:

00:07:47.066 --> 00:07:48.116 A:middle
that's the lowest power.

00:07:48.466 --> 00:07:51.346 A:middle
And at the top, 100 percent
would be the least idle,

00:07:51.446 --> 00:07:53.626 A:middle
executing all the time
during the sample interval.

00:07:54.206 --> 00:07:58.216 A:middle
So here's what it looked like.

00:07:59.016 --> 00:08:02.236 A:middle
At the beginning, I was typing
Apple.com into the address bar

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:59.016 --> 00:08:02.236 A:middle
At the beginning, I was typing
Apple.com into the address bar

00:08:02.336 --> 00:08:04.596 A:middle
and so that's not just the key
presses that we need to handle:

00:08:04.596 --> 00:08:07.736 A:middle
that also includes Auto Complete
or looking up bookmarks,

00:08:08.036 --> 00:08:10.656 A:middle
drawing the actual menu
on screen and so forth.

00:08:11.606 --> 00:08:13.866 A:middle
This vertical spike here
is where I've hit Enter

00:08:13.866 --> 00:08:15.636 A:middle
and we began downloading
the webpage

00:08:15.736 --> 00:08:16.896 A:middle
and rendering the content.

00:08:17.366 --> 00:08:19.036 A:middle
Now what's interesting
about this, is if you look

00:08:19.036 --> 00:08:21.706 A:middle
at the number there, we're
still at this time at the peak

00:08:21.706 --> 00:08:23.296 A:middle
of the activity of
this use case.

00:08:23.776 --> 00:08:25.826 A:middle
Over 50 percent of
the time is spent

00:08:25.826 --> 00:08:27.806 A:middle
at our most idle
state in the CPU.

00:08:27.936 --> 00:08:30.396 A:middle
So that indicates just how
quickly we can transition.

00:08:31.326 --> 00:08:32.556 A:middle
And finally near the end here is

00:08:32.556 --> 00:08:35.246 A:middle
when the data has finished
coming in - asynchronously

00:08:35.246 --> 00:08:37.366 A:middle
of course - and the
rendering has been finished.

00:08:37.576 --> 00:08:39.986 A:middle
And we've tried to move as
close to as much as idle

00:08:39.986 --> 00:08:41.645 A:middle
as possible when that's done.

00:08:42.456 --> 00:08:46.256 A:middle
Now let's compare this with
our Eyes Demo Application

00:08:46.846 --> 00:08:47.556 A:middle
that we just saw.

00:08:48.296 --> 00:08:51.416 A:middle
So you can see here, the Eyes
Application only lets the CPU

00:08:51.416 --> 00:08:54.376 A:middle
stay in its most idle state
about 75 percent of the time.

00:08:54.816 --> 00:08:58.106 A:middle
So that application - while
hidden behind another window -

00:08:58.436 --> 00:09:01.976 A:middle
is using significantly
more energy than Safari,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:08:58.436 --> 00:09:01.976 A:middle
is using significantly
more energy than Safari,

00:09:01.976 --> 00:09:03.496 A:middle
rendering an entire webpage.

00:09:04.076 --> 00:09:06.886 A:middle
So even small applications
can have a large impact

00:09:06.986 --> 00:09:08.476 A:middle
on battery life and energy.

00:09:09.016 --> 00:09:13.386 A:middle
And you know, this is what
it was doing: polling.

00:09:14.056 --> 00:09:16.986 A:middle
The whole time, just polling,
checking where the mouse was,

00:09:17.076 --> 00:09:19.546 A:middle
redrawing where the eyes
needed to be and so forth.

00:09:20.036 --> 00:09:22.866 A:middle
And we can actually
do better than this.

00:09:23.076 --> 00:09:26.846 A:middle
So why would we exit the idle
state when there's work to do?

00:09:26.936 --> 00:09:28.976 A:middle
Well so for Safari, when
it was receiving data,

00:09:28.976 --> 00:09:30.026 A:middle
that's network activity.

00:09:30.026 --> 00:09:31.786 A:middle
That's a good reason to
wake up and do something.

00:09:32.276 --> 00:09:35.386 A:middle
Or when I was typing
Apple.com into the address bar,

00:09:35.686 --> 00:09:37.566 A:middle
that's another reason that
we might be doing some work.

00:09:38.136 --> 00:09:41.466 A:middle
We can actually transition
pretty fast between these states

00:09:41.466 --> 00:09:45.406 A:middle
such that disk I/O is a good
opportunity to save some energy.

00:09:46.696 --> 00:09:48.136 A:middle
And finally and most
importantly,

00:09:48.396 --> 00:09:50.316 A:middle
we exit idle because of timers.

00:09:50.396 --> 00:09:52.276 A:middle
And when we were
investigating this feature,

00:09:52.276 --> 00:09:56.306 A:middle
we found out that timers were
by far the Number 1 reason

00:09:56.306 --> 00:09:57.486 A:middle
to exit the idle state.

00:09:58.296 --> 00:10:00.116 A:middle
And that's because
there's so much API

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:09:58.296 --> 00:10:00.116 A:middle
And that's because
there's so much API

00:10:00.116 --> 00:10:01.586 A:middle
that actually involves timers.

00:10:02.046 --> 00:10:03.236 A:middle
That's everything
with a relative

00:10:03.236 --> 00:10:04.396 A:middle
or an absolute deadline.

00:10:05.506 --> 00:10:08.056 A:middle
So for example, NSTimer,
CF run loop timer,

00:10:08.206 --> 00:10:09.616 A:middle
dispatch source type timer.

00:10:09.876 --> 00:10:13.176 A:middle
These timers are both -- can
be both relative or absolute.

00:10:13.686 --> 00:10:18.216 A:middle
An API like sleep: let's
say we sleep for 1 second.

00:10:18.216 --> 00:10:21.426 A:middle
Well that means in 1 second, the
CPU has to exit the idle state,

00:10:21.466 --> 00:10:23.446 A:middle
wake up and continue
executing code.

00:10:24.016 --> 00:10:27.656 A:middle
It also includes
APIs with time outs

00:10:27.746 --> 00:10:30.096 A:middle
like pthread-cond-timedwait
and so forth.

00:10:31.346 --> 00:10:34.396 A:middle
And APIs built on top of
these like Perform Selector

00:10:34.396 --> 00:10:37.656 A:middle
with object after delay or
NS Run Loop run until date.

00:10:37.916 --> 00:10:38.876 A:middle
That last one?

00:10:39.076 --> 00:10:40.456 A:middle
Sometimes you see a
pattern of putting

00:10:40.456 --> 00:10:42.436 A:middle
that with a short timeout
inside of a wild loop.

00:10:42.776 --> 00:10:44.296 A:middle
So that would indicate
a lot of timers.

00:10:46.186 --> 00:10:47.306 A:middle
And many more.

00:10:49.506 --> 00:10:52.456 A:middle
So when developing AppNap,
we realized that in order

00:10:52.456 --> 00:10:55.166 A:middle
to effectively extend the
battery life of our laptops,

00:10:55.546 --> 00:10:57.466 A:middle
we needed to reduce
the impact of timers.

00:10:57.736 --> 00:10:59.276 A:middle
And we've done that
with two approaches.

00:10:59.566 --> 00:11:01.206 A:middle
The first is timer coalescing

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:59.566 --> 00:11:01.206 A:middle
The first is timer coalescing

00:11:01.276 --> 00:11:03.356 A:middle
and the second is
timer rate limiting.

00:11:03.826 --> 00:11:05.346 A:middle
Let's talk about
coalescing first.

00:11:05.346 --> 00:11:07.086 A:middle
So here I have another
graph for you.

00:11:07.426 --> 00:11:09.456 A:middle
On the vertical axis,
I'm graphing power.

00:11:09.456 --> 00:11:11.416 A:middle
So the idle state of the CPU.

00:11:11.656 --> 00:11:14.516 A:middle
And then on the horizontal
axis, we've got time.

00:11:14.516 --> 00:11:16.476 A:middle
And here you see the time
scale's pretty short:

00:11:16.796 --> 00:11:18.456 A:middle
about 150 milliseconds.

00:11:18.976 --> 00:11:22.026 A:middle
Now I've set up 4
timers and T1 through T4.

00:11:22.026 --> 00:11:25.076 A:middle
The width of that line
represents the time I spent

00:11:25.286 --> 00:11:25.926 A:middle
doing work.

00:11:26.106 --> 00:11:28.816 A:middle
Because of that timer fired,
we needed to do something.

00:11:29.416 --> 00:11:31.076 A:middle
Now I said earlier that
we could transition

00:11:31.076 --> 00:11:33.026 A:middle
between that 0.4 watt idle state

00:11:33.286 --> 00:11:35.976 A:middle
and the high power executing
code state very rapidly.

00:11:36.246 --> 00:11:38.976 A:middle
And that's true but
it's not instantaneous.

00:11:39.286 --> 00:11:41.556 A:middle
There's actually a ramp
up and a ramp down time

00:11:41.956 --> 00:11:44.336 A:middle
between the idle state
and the high power state.

00:11:45.406 --> 00:11:47.746 A:middle
And while we're doing
that ramp up or ramp down,

00:11:47.746 --> 00:11:50.426 A:middle
we're doing absolutely zero
useful work for the user.

00:11:50.796 --> 00:11:52.176 A:middle
So that's overhead.

00:11:52.256 --> 00:11:55.446 A:middle
And in fact, because there's a
time, you can see from the slope

00:11:55.446 --> 00:11:58.776 A:middle
of the line between T1 and
T2, there's not enough time

00:11:58.776 --> 00:12:02.816 A:middle
between that deadline to go
to our lowest power state.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:11:58.776 --> 00:12:02.816 A:middle
between that deadline to go
to our lowest power state.

00:12:02.996 --> 00:12:05.516 A:middle
So instead, we choose
something a little bit less.

00:12:05.766 --> 00:12:09.646 A:middle
And the same thing
happens between T2 and T3.

00:12:10.026 --> 00:12:12.976 A:middle
However, if we look at
the T3 and T4 timers,

00:12:13.226 --> 00:12:14.676 A:middle
you can see they're right
up next to each other.

00:12:14.676 --> 00:12:16.846 A:middle
And that's something that
we can take advantage of.

00:12:17.296 --> 00:12:20.036 A:middle
So what we've done with timer
coalescing is apply a small

00:12:20.036 --> 00:12:23.336 A:middle
delay to timers to sort
of push them together.

00:12:23.336 --> 00:12:27.146 A:middle
And the result is that we can
ramp up once and ramp down once.

00:12:27.436 --> 00:12:30.186 A:middle
And according to our rules
of extending battery life,

00:12:30.476 --> 00:12:32.856 A:middle
we can stay in the
idle state much longer.

00:12:33.216 --> 00:12:35.216 A:middle
And if we compare it to
our previous graph here,

00:12:35.616 --> 00:12:38.076 A:middle
you can see that these areas
represent saved energy.

00:12:38.366 --> 00:12:40.806 A:middle
That was work that we just
didn't have to do transitioning

00:12:40.806 --> 00:12:42.276 A:middle
between states because
again remember,

00:12:42.276 --> 00:12:43.826 A:middle
we're not doing any
useful work there.

00:12:43.826 --> 00:12:47.446 A:middle
Now I said that the width

00:12:47.446 --> 00:12:50.506 A:middle
of that line represented
the work that the timer did.

00:12:50.766 --> 00:12:52.376 A:middle
And we call that a
Second Order Effect.

00:12:52.376 --> 00:12:54.226 A:middle
So what happens after
the timer fires?

00:12:54.536 --> 00:12:56.796 A:middle
So that you might do -
this one seems obvious -

00:12:56.796 --> 00:13:00.496 A:middle
you might use the CPU but you
could also turn on the screen

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:56.796 --> 00:13:00.496 A:middle
you might use the CPU but you
could also turn on the screen

00:13:00.956 --> 00:13:03.296 A:middle
or do some drawing
like the Eyes App does.

00:13:03.296 --> 00:13:05.006 A:middle
That involves the GPU
which means we have

00:13:05.006 --> 00:13:06.246 A:middle
to power that up as well.

00:13:07.666 --> 00:13:10.906 A:middle
Sending data over Wi-Fi means we
have to power up Wi-Fi radios.

00:13:11.316 --> 00:13:13.136 A:middle
Writing to disk or
writing to memory,

00:13:13.396 --> 00:13:15.076 A:middle
all of these have energy costs.

00:13:15.616 --> 00:13:17.916 A:middle
So in addition to
the coalescing,

00:13:17.916 --> 00:13:21.026 A:middle
we wanted to reduce the impact
of second order effects as well.

00:13:21.526 --> 00:13:23.946 A:middle
And to do that, we're
doing timer rate limiting.

00:13:24.936 --> 00:13:27.536 A:middle
So here is a similar graphic
except that I've zoomed way out.

00:13:27.536 --> 00:13:29.976 A:middle
So you see here that the
horizontal scale is on the order

00:13:29.976 --> 00:13:31.306 A:middle
of seconds at this time.

00:13:31.626 --> 00:13:33.886 A:middle
And what I have here is a
1 second repeating timer

00:13:34.116 --> 00:13:37.086 A:middle
and the width of each of these
bumps represents the second

00:13:37.086 --> 00:13:39.306 A:middle
order effect of the work
that's being done every time

00:13:39.306 --> 00:13:40.206 A:middle
that timer fires.

00:13:40.636 --> 00:13:42.256 A:middle
This is a very similar
pattern to what we see

00:13:42.256 --> 00:13:44.536 A:middle
in the Eyes Demo app except
there it's actually much

00:13:44.536 --> 00:13:45.176 A:middle
more frequent.

00:13:45.546 --> 00:13:48.066 A:middle
So timer rate limiting
pushes out the frequency --

00:13:48.066 --> 00:13:51.586 A:middle
excuse me -- reduces the
frequency of this timer firing.

00:13:52.186 --> 00:13:56.626 A:middle
And what that does is -- I mean
the timer's still going to fire,

00:13:56.626 --> 00:13:58.076 A:middle
but we're just going
to fire it less often.

00:13:58.216 --> 00:14:02.786 A:middle
And what that does is you
see here reduce the impact

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:58.216 --> 00:14:02.786 A:middle
And what that does is you
see here reduce the impact

00:14:02.786 --> 00:14:03.856 A:middle
of the second order effect.

00:14:03.856 --> 00:14:06.176 A:middle
So all that area is
also saved energy.

00:14:06.536 --> 00:14:08.526 A:middle
And this can have a really
big impact over time.

00:14:09.186 --> 00:14:12.026 A:middle
A couple more details.

00:14:12.026 --> 00:14:14.286 A:middle
The coalescing delay
again is on the order

00:14:14.286 --> 00:14:15.526 A:middle
of about a hundred milliseconds.

00:14:15.766 --> 00:14:17.736 A:middle
And this is actually about
the same as delay due

00:14:17.736 --> 00:14:18.826 A:middle
to normal system load.

00:14:19.046 --> 00:14:21.576 A:middle
So in all previous
releases of OS X,

00:14:21.576 --> 00:14:23.196 A:middle
even if you thought
your timer fired exactly

00:14:23.196 --> 00:14:26.156 A:middle
when you asked it to, in fact if
there was a high priority thread

00:14:26.436 --> 00:14:27.946 A:middle
or some other work
on the run loop,

00:14:28.096 --> 00:14:30.266 A:middle
it could have been the case
that you actually fired later

00:14:30.266 --> 00:14:31.956 A:middle
than you did -- you
thought you did anyway.

00:14:32.426 --> 00:14:34.396 A:middle
Now we've designed this
based on heuristics

00:14:34.396 --> 00:14:35.886 A:middle
to be undetectable to the user.

00:14:36.216 --> 00:14:38.966 A:middle
The rate limiting delay
on the other hand is

00:14:38.966 --> 00:14:40.126 A:middle
on the order of seconds.

00:14:40.896 --> 00:14:41.836 A:middle
Now in both cases though,

00:14:41.836 --> 00:14:44.436 A:middle
we do not fire timers
early: we only delay them.

00:14:45.286 --> 00:14:47.826 A:middle
And the exact delays are going
to depend on the heuristics

00:14:47.826 --> 00:14:50.846 A:middle
so that we can provide a
consistent user experience.

00:14:51.346 --> 00:14:54.206 A:middle
And finally, some of these
behaviors are configurable.

00:14:54.406 --> 00:14:56.616 A:middle
And I'll show you how to
do that a little bit later.

00:14:57.616 --> 00:15:00.886 A:middle
But first I want to talk
about why: what's the result?

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:57.616 --> 00:15:00.886 A:middle
But first I want to talk
about why: what's the result?

00:15:00.886 --> 00:15:04.846 A:middle
The end game in doing all of
this changing around timers?

00:15:05.286 --> 00:15:07.966 A:middle
So let's look again at this
graph for our Eyes Demo.

00:15:07.966 --> 00:15:09.436 A:middle
Again, this is CPU activity.

00:15:09.936 --> 00:15:13.706 A:middle
So here at about 25 percent
again is the Eyes app hidden

00:15:13.706 --> 00:15:17.126 A:middle
behind my activity monitor, but
with AppNap explicitly disabled.

00:15:17.816 --> 00:15:19.436 A:middle
And here is the same app,

00:15:19.656 --> 00:15:22.256 A:middle
hidden behind Activity
Monitor, with AppNap enabled.

00:15:23.146 --> 00:15:24.976 A:middle
And you can see that
these vertical bumps here

00:15:24.976 --> 00:15:27.336 A:middle
in the bottom line represent
the timer rate limiting.

00:15:27.336 --> 00:15:30.236 A:middle
That's where we allow the app
to continue to do some work.

00:15:30.896 --> 00:15:32.346 A:middle
Now looking at this
graph you might think

00:15:32.666 --> 00:15:35.306 A:middle
that that doesn't seem like
much of a difference, right?

00:15:35.306 --> 00:15:37.126 A:middle
We're both -- that's
only 25 percent.

00:15:37.126 --> 00:15:38.106 A:middle
That's not a huge number.

00:15:38.616 --> 00:15:42.136 A:middle
But if I were a user using on
my demo machine here the iZap

00:15:42.136 --> 00:15:43.246 A:middle
in the way I just described,

00:15:43.976 --> 00:15:45.866 A:middle
running it behind another
window is actually going

00:15:45.866 --> 00:15:47.956 A:middle
to cost me 1 hour
of battery life.

00:15:48.446 --> 00:15:52.706 A:middle
So the timer rate limiting
and timer coalescing

00:15:52.706 --> 00:15:56.296 A:middle
and other activities that AppNap
does can make a really big

00:15:56.296 --> 00:15:57.976 A:middle
difference for even the
smallest kinds of applications.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:16:03.336 --> 00:16:05.416 A:middle
So one way to actually
improve this even further is

00:16:05.416 --> 00:16:07.376 A:middle
if in your applications
you think about switching

00:16:07.376 --> 00:16:10.846 A:middle
from timer based APIs
to event based APIs.

00:16:11.406 --> 00:16:13.866 A:middle
So instead of polling
key presses

00:16:13.866 --> 00:16:16.236 A:middle
or mouse locations, use events.

00:16:17.086 --> 00:16:19.466 A:middle
And instead of repeatedly
checking file content,

00:16:19.736 --> 00:16:21.496 A:middle
sometimes we see this as a form

00:16:21.496 --> 00:16:24.666 A:middle
of making sure an application
is updated or a form

00:16:24.666 --> 00:16:26.326 A:middle
of communicating
between applications.

00:16:26.736 --> 00:16:29.836 A:middle
So instead of doing that, you
use FS Events dispatch sources

00:16:29.836 --> 00:16:33.746 A:middle
which can tell you about files
changing or real IPC mechanisms

00:16:33.746 --> 00:16:35.106 A:middle
like NSXPC Connection.

00:16:35.516 --> 00:16:37.256 A:middle
Or if you're a - you
know - Cocoa level app,

00:16:37.256 --> 00:16:38.826 A:middle
you can use File
Coordination as well.

00:16:39.376 --> 00:16:43.136 A:middle
And finally, instead of
timer based synchronization,

00:16:43.206 --> 00:16:44.716 A:middle
use Semaphores or other locks.

00:16:45.066 --> 00:16:47.066 A:middle
So another pattern that
we've seen is an application

00:16:47.066 --> 00:16:47.816 A:middle
with 2 threads.

00:16:48.146 --> 00:16:50.986 A:middle
One thread does some work and
then sets a global Boolean flag

00:16:50.986 --> 00:16:53.246 A:middle
and the second thread
does a sweep

00:16:53.296 --> 00:16:54.626 A:middle
and checks the flag repeatedly.

00:16:54.976 --> 00:16:56.496 A:middle
And that's energy inefficient.

00:16:56.496 --> 00:17:00.146 A:middle
So we actually have an
entire talk about these kinds

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:16:56.496 --> 00:17:00.146 A:middle
So we actually have an
entire talk about these kinds

00:17:00.146 --> 00:17:02.056 A:middle
of patterns and ways
that you can do better.

00:17:02.346 --> 00:17:06.776 A:middle
That is tomorrow at 10:15 in
Marina, "Energy Best Practices."

00:17:07.296 --> 00:17:09.746 A:middle
But first, I want to show you
an example of the first thing.

00:17:09.746 --> 00:17:12.796 A:middle
So instead of polling mouse
locations using events.

00:17:12.796 --> 00:17:13.776 A:middle
So we're going to go ahead

00:17:13.776 --> 00:17:15.665 A:middle
and prove the Eyes
application to do this.

00:17:16.675 --> 00:17:18.766 A:middle
Alright, so here I
have the source code

00:17:18.766 --> 00:17:20.776 A:middle
that you've all been waiting
for, for the Eyes application.

00:17:21.076 --> 00:17:22.726 A:middle
Today though, we're
going to focus

00:17:22.726 --> 00:17:23.836 A:middle
on the application Delegate.

00:17:24.346 --> 00:17:25.326 A:middle
And let's start here

00:17:25.326 --> 00:17:27.236 A:middle
in the application did
finish launching method.

00:17:28.445 --> 00:17:32.726 A:middle
Now what you can see here is
that we are setting up a timer

00:17:33.276 --> 00:17:35.316 A:middle
with a timer interval
of 60 hertz.

00:17:35.956 --> 00:17:38.676 A:middle
And when that timer
fires, we are going

00:17:38.676 --> 00:17:40.336 A:middle
to call the Timer Fired Method

00:17:40.626 --> 00:17:42.046 A:middle
and of course it's
a repeating timer.

00:17:42.456 --> 00:17:43.936 A:middle
Now maybe I picked 60 hertz

00:17:43.936 --> 00:17:46.616 A:middle
because I wanted a smooth 60
frames per second animation

00:17:46.996 --> 00:17:48.876 A:middle
but anyway, that's a
pretty frequent timer.

00:17:49.766 --> 00:17:50.786 A:middle
And of course I add this timer

00:17:50.786 --> 00:17:53.826 A:middle
to my main run loop
so that it fires.

00:17:54.466 --> 00:17:56.856 A:middle
Now when it fires we call
this method Timer Fired

00:17:57.196 --> 00:17:58.926 A:middle
and you can see it
calls another method

00:17:58.926 --> 00:18:00.526 A:middle
which is Update Mouse Locations.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:58.926 --> 00:18:00.526 A:middle
which is Update Mouse Locations.

00:18:00.956 --> 00:18:05.106 A:middle
And here what we do is you
grab the current mouse location

00:18:05.106 --> 00:18:07.966 A:middle
from NS Event and
we set up that --

00:18:07.966 --> 00:18:11.256 A:middle
we pass that information
along to our 2 views that are

00:18:11.256 --> 00:18:12.826 A:middle
in the application:
one for each eye.

00:18:13.466 --> 00:18:19.756 A:middle
So I'm going to go ahead and run
this again and we can see Eyes

00:18:19.756 --> 00:18:20.606 A:middle
over here in the corner.

00:18:20.706 --> 00:18:23.316 A:middle
We'll leave it there so we
can watch it watching us

00:18:23.546 --> 00:18:24.096 A:middle
through the demo.

00:18:24.096 --> 00:18:27.886 A:middle
And I want to show you a new
feature in Xcode as well.

00:18:27.886 --> 00:18:30.006 A:middle
So here is our new energy gauge.

00:18:30.306 --> 00:18:32.536 A:middle
And this is going to be
a really critical tool

00:18:32.536 --> 00:18:35.096 A:middle
for understanding the energy
impact of your application.

00:18:35.776 --> 00:18:38.316 A:middle
So you can see up
here in the CPU area,

00:18:38.676 --> 00:18:41.336 A:middle
we're in the single digit
percentage for CPU usage,

00:18:41.516 --> 00:18:44.646 A:middle
but the energy impact of this
application is actually very

00:18:44.646 --> 00:18:45.566 A:middle
high or high.

00:18:46.876 --> 00:18:47.976 A:middle
So this number up here

00:18:47.976 --> 00:18:49.946 A:middle
in the upper right corner
represents the number

00:18:49.946 --> 00:18:51.256 A:middle
of wakes in the last second.

00:18:51.656 --> 00:18:54.296 A:middle
So that means that's the number
of times the CPU had to move

00:18:54.296 --> 00:18:55.766 A:middle
from that lower power idle state

00:18:56.076 --> 00:18:59.806 A:middle
to the high power executing
code state just for this app.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:01.696 --> 00:19:04.696 A:middle
In the middle we see a graph
representing energy impact.

00:19:05.716 --> 00:19:07.946 A:middle
The blue area is what I
was referring to earlier

00:19:07.946 --> 00:19:09.136 A:middle
as a second order effect.

00:19:09.136 --> 00:19:11.676 A:middle
So that's the work that
Eyes was actually doing

00:19:12.486 --> 00:19:13.496 A:middle
when the timer fired.

00:19:13.826 --> 00:19:15.886 A:middle
In this case, this app is
actually pretty inefficient

00:19:16.166 --> 00:19:19.136 A:middle
so that second order effect
is dwarfing everything else.

00:19:19.466 --> 00:19:21.836 A:middle
But that little red
area at the top

00:19:21.836 --> 00:19:24.686 A:middle
that you might see is what we
call the CPU Wake Overhead.

00:19:24.906 --> 00:19:28.536 A:middle
And that represents the overhead
of just having a timer at all.

00:19:29.066 --> 00:19:31.076 A:middle
So let's see how we can
improve the Eyes application

00:19:31.356 --> 00:19:34.596 A:middle
to reduce some of this impact
because as you can see here,

00:19:34.596 --> 00:19:36.096 A:middle
I'm not moving my mouse at all,

00:19:36.096 --> 00:19:37.886 A:middle
and yet we're still
using plenty of energy.

00:19:42.056 --> 00:19:43.926 A:middle
So I have a branch
ready to show you that.

00:19:53.166 --> 00:19:54.306 A:middle
So let's scroll down again

00:19:54.306 --> 00:19:56.166 A:middle
to our Application Did
Finish Launching method

00:19:56.406 --> 00:19:58.286 A:middle
and now you notice it's
much shorter and that's

00:19:58.286 --> 00:19:59.286 A:middle
because I deleted the timer.

00:19:59.286 --> 00:20:01.906 A:middle
In its place, I'm
using Event Monitor.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:59.286 --> 00:20:01.906 A:middle
In its place, I'm
using Event Monitor.

00:20:02.256 --> 00:20:05.156 A:middle
Now this is an API that
was added all the way back

00:20:05.206 --> 00:20:08.526 A:middle
when we used cats for code
names and - Snow Leopard

00:20:08.526 --> 00:20:12.316 A:middle
in particular - and it's
called A Global Event Monitor

00:20:12.316 --> 00:20:13.346 A:middle
and A Local Event Monitor.

00:20:13.516 --> 00:20:14.576 A:middle
So we have one of each.

00:20:14.576 --> 00:20:17.106 A:middle
The Global Event
Monitor tells us

00:20:17.456 --> 00:20:20.956 A:middle
when an event happens
anywhere on the system

00:20:21.246 --> 00:20:22.976 A:middle
and the local one is
for events in our app.

00:20:23.366 --> 00:20:25.406 A:middle
So for this particular
app, I wanted to use both.

00:20:25.466 --> 00:20:27.846 A:middle
And you can see, I've
registered for notifications

00:20:27.846 --> 00:20:29.956 A:middle
about pretty much every kind
of mouse event there is.

00:20:30.376 --> 00:20:33.676 A:middle
But in any case, I
do the same thing

00:20:33.676 --> 00:20:35.976 A:middle
which is called the same
Update Mouse Locations Method

00:20:35.976 --> 00:20:36.856 A:middle
that we saw earlier.

00:20:37.456 --> 00:20:38.626 A:middle
And that's the only
change I've made.

00:20:38.626 --> 00:20:40.166 A:middle
Let's go ahead and
run this again.

00:20:40.796 --> 00:20:44.346 A:middle
And I'll bring up
my energy gauge.

00:20:45.256 --> 00:20:47.756 A:middle
And you'll see if I move
my mouse around some more -

00:20:47.806 --> 00:20:51.886 A:middle
and Eyes is following it here -
we still see our energy impact.

00:20:52.156 --> 00:20:53.896 A:middle
But look at the difference
up here in the right corner

00:20:53.896 --> 00:20:55.256 A:middle
with the wakes in
the last second.

00:20:55.746 --> 00:20:58.136 A:middle
So if the CPU is already awake
processing the mouse moved

00:20:58.136 --> 00:21:02.046 A:middle
event, that means a lot less
overhead transition time

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:58.136 --> 00:21:02.046 A:middle
event, that means a lot less
overhead transition time

00:21:02.046 --> 00:21:04.506 A:middle
because now we're just doing
the work along with that.

00:21:05.566 --> 00:21:07.526 A:middle
And better still,
if I stop moving,

00:21:08.916 --> 00:21:11.396 A:middle
in general this app is going
to go to a steady state

00:21:11.396 --> 00:21:13.446 A:middle
of about zero wakes
in the last second.

00:21:13.776 --> 00:21:16.796 A:middle
You might see a few bumps or
blips in this graph and that's

00:21:16.796 --> 00:21:19.176 A:middle
because libraries or system
frameworks may be doing things

00:21:19.176 --> 00:21:22.366 A:middle
on your behalf that aren't
specifically in the application.

00:21:22.366 --> 00:21:23.136 A:middle
So those are normal.

00:21:23.596 --> 00:21:26.386 A:middle
But ultimately what we
want to see is zero wakes

00:21:26.386 --> 00:21:28.656 A:middle
in the last second,
zero CPU usage.

00:21:28.976 --> 00:21:31.196 A:middle
A steady state of zero is
the best state for energy.

00:21:31.726 --> 00:21:35.246 A:middle
But if I keep moving
my mouse again here,

00:21:35.736 --> 00:21:38.086 A:middle
you see that Eyes became
responsive right away.

00:21:38.986 --> 00:21:40.686 A:middle
So we didn't lose any
functionality in this app

00:21:40.686 --> 00:21:42.906 A:middle
but it's significantly
better for energy.

00:21:43.206 --> 00:21:44.476 A:middle
I want to show you
one more thing though.

00:21:44.476 --> 00:21:47.266 A:middle
I'm just going to go ahead
and drag my [inaudible] window

00:21:47.266 --> 00:21:49.536 A:middle
over here to hide the
Eyes app and I'm going

00:21:49.536 --> 00:21:50.556 A:middle
to move my mouse around.

00:21:51.596 --> 00:21:52.806 A:middle
Now what you can see here is

00:21:52.806 --> 00:21:54.586 A:middle
that we still actually
have an energy impact.

00:21:55.016 --> 00:21:57.276 A:middle
And that's because Eyes is
still receiving those events

00:21:57.276 --> 00:21:59.536 A:middle
in the background, even
though we can't see it.

00:21:59.726 --> 00:22:01.986 A:middle
So this is something that we
can actually improve with some

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:59.726 --> 00:22:01.986 A:middle
So this is something that we
can actually improve with some

00:22:01.986 --> 00:22:03.316 A:middle
of the new API that we've added.

00:22:03.316 --> 00:22:04.886 A:middle
So let's go back to our slides

00:22:04.886 --> 00:22:07.126 A:middle
and we'll talk about
how to do that.

00:22:09.796 --> 00:22:11.006 A:middle
So before I move on though,

00:22:11.006 --> 00:22:12.796 A:middle
I want to say a few words
about responsiveness.

00:22:13.106 --> 00:22:16.546 A:middle
I promised earlier at the talk
that AppNap is about both energy

00:22:16.656 --> 00:22:18.276 A:middle
or battery life and
responsiveness.

00:22:18.726 --> 00:22:19.966 A:middle
The idea behind this is

00:22:19.966 --> 00:22:22.466 A:middle
that important work should
have higher priority.

00:22:22.806 --> 00:22:24.746 A:middle
And we can use some of the same
heuristics that we've talked

00:22:24.746 --> 00:22:28.546 A:middle
about to decide which
work that is.

00:22:29.106 --> 00:22:34.356 A:middle
So what we can do is allow apps
or excuse me, put apps that are

00:22:34.356 --> 00:22:38.096 A:middle
in AppNap into a lower
priority for both I/O and NCPU.

00:22:38.436 --> 00:22:40.566 A:middle
So for example, let's say that
I'm editing my presentation

00:22:40.566 --> 00:22:42.656 A:middle
in keynote and an
AutoSave begins.

00:22:43.056 --> 00:22:44.356 A:middle
Well that's the foreground app:

00:22:44.506 --> 00:22:46.056 A:middle
the one I'm currently
interacting with.

00:22:46.506 --> 00:22:48.396 A:middle
I think we'd all agree that --

00:22:48.516 --> 00:22:51.756 A:middle
AutoSave's I/O should happen
first before any other kind

00:22:51.756 --> 00:22:54.686 A:middle
of like background work
like Logging to Disk

00:22:54.686 --> 00:22:57.086 A:middle
or some other kind of thing that
I can't even tell is going on.

00:22:57.156 --> 00:22:59.396 A:middle
So that's the idea
behind I/O prioritization.

00:22:59.886 --> 00:23:02.216 A:middle
For CPU, we're going to
lower the priority of apps

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:22:59.886 --> 00:23:02.216 A:middle
For CPU, we're going to
lower the priority of apps

00:23:02.216 --> 00:23:05.696 A:middle
in AppNap lower than other
apps but still higher

00:23:05.696 --> 00:23:07.276 A:middle
than system daemons or agents.

00:23:10.166 --> 00:23:12.196 A:middle
Really though, responsiveness is

00:23:12.196 --> 00:23:14.676 A:middle
about improving the general
performance of your application.

00:23:14.966 --> 00:23:17.236 A:middle
And that includes
reducing memory usage,

00:23:17.356 --> 00:23:20.506 A:middle
choosing better algorithms
and improving CPU efficiency.

00:23:20.896 --> 00:23:23.916 A:middle
And that's techniques that we've
been talking about for a while.

00:23:23.916 --> 00:23:26.766 A:middle
So we actually have an
entire talk about that.

00:23:26.766 --> 00:23:29.216 A:middle
It's called, "Building
Efficient OS X Apps."

00:23:29.466 --> 00:23:31.066 A:middle
It was yesterday so
if you missed it,

00:23:31.066 --> 00:23:32.416 A:middle
definitely catch
that one on video.

00:23:32.826 --> 00:23:34.406 A:middle
And remember that
improving performance

00:23:34.406 --> 00:23:37.466 A:middle
in that way also has a big
impact on energy efficiency.

00:23:38.026 --> 00:23:43.286 A:middle
So let's move on and talk
about some AppNap API.

00:23:44.316 --> 00:23:47.166 A:middle
So we have three new
categories of API.

00:23:47.676 --> 00:23:48.896 A:middle
The first is as I mentioned,

00:23:48.896 --> 00:23:50.996 A:middle
we can find out when you
application is visible

00:23:50.996 --> 00:23:51.636 A:middle
or a window.

00:23:52.536 --> 00:23:55.026 A:middle
We allow you now to add an
additional tolerance to timers.

00:23:55.116 --> 00:23:57.326 A:middle
That helps with the coalescing
that we've been talking about.

00:23:57.916 --> 00:23:59.786 A:middle
And finally, we also
let you tell the system

00:23:59.786 --> 00:24:01.556 A:middle
about what you're
doing as an application

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:59.786 --> 00:24:01.556 A:middle
about what you're
doing as an application

00:24:01.556 --> 00:24:02.726 A:middle
on behalf of the user.

00:24:03.016 --> 00:24:05.456 A:middle
And that will help us
improve our AppNap heuristics.

00:24:05.456 --> 00:24:10.216 A:middle
So first let's talk
about visibility.

00:24:10.676 --> 00:24:13.326 A:middle
This new API lets you find out
when either an individual window

00:24:13.566 --> 00:24:15.546 A:middle
or your entire application
is occluded.

00:24:15.706 --> 00:24:18.416 A:middle
So by occluded I mean
not visible to the user.

00:24:18.946 --> 00:24:21.996 A:middle
An example of when a window may
be occluded would be if it's

00:24:21.996 --> 00:24:24.316 A:middle
on another space and that
space is not visible,

00:24:24.316 --> 00:24:27.406 A:middle
if another application has a
window in front of your window

00:24:27.476 --> 00:24:30.116 A:middle
and your window is a hundred
percent occluded behind it,

00:24:30.646 --> 00:24:32.846 A:middle
or if some higher level
window just covers everybody

00:24:32.846 --> 00:24:35.986 A:middle
like the screensaver or if
you fast user switched away

00:24:35.986 --> 00:24:37.666 A:middle
from the user session.

00:24:38.306 --> 00:24:42.026 A:middle
So one example of when you
might want to use this is

00:24:42.026 --> 00:24:44.266 A:middle
to halt expensive
work when occluded.

00:24:44.586 --> 00:24:47.356 A:middle
So for example, the Eyes
application, it does not need

00:24:47.356 --> 00:24:49.866 A:middle
to listen for mouse events
if you can't see the eyes.

00:24:50.046 --> 00:24:52.376 A:middle
So that would be a big
improvement to make for that.

00:24:52.506 --> 00:24:56.136 A:middle
You can also use it to refresh
content when becoming visible.

00:24:56.376 --> 00:24:59.036 A:middle
So let's imagine we have a
stock ticker application.

00:24:59.336 --> 00:25:03.396 A:middle
Now stock data is pretty rapidly
out of date so it's a real waste

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:24:59.336 --> 00:25:03.396 A:middle
Now stock data is pretty rapidly
out of date so it's a real waste

00:25:03.396 --> 00:25:07.006 A:middle
if the user can't even see the
window if we not only redraw it

00:25:07.006 --> 00:25:11.026 A:middle
on the screen but also
spend power using the Wi-Fi

00:25:11.146 --> 00:25:15.176 A:middle
to retrieve that data, the
user's bandwidth especially

00:25:15.176 --> 00:25:17.436 A:middle
if they're mobile, and
your server bandwidth

00:25:17.436 --> 00:25:19.046 A:middle
to retrieve the data
in the first place.

00:25:19.136 --> 00:25:22.966 A:middle
So using this API can be a
big win for the entire stack.

00:25:24.266 --> 00:25:25.356 A:middle
So here's how that works.

00:25:25.596 --> 00:25:27.146 A:middle
Let's say I have my Eyes window.

00:25:27.146 --> 00:25:30.326 A:middle
Here it's visible right in
front of another window.

00:25:30.916 --> 00:25:33.526 A:middle
So partial visibility
like you see here,

00:25:33.786 --> 00:25:35.396 A:middle
we still count that
as visibility.

00:25:35.666 --> 00:25:36.926 A:middle
And in fact, it doesn't
matter how much

00:25:36.926 --> 00:25:37.956 A:middle
of your window is showing.

00:25:37.956 --> 00:25:38.896 A:middle
So maybe you would say,

00:25:38.896 --> 00:25:40.876 A:middle
"But I just have a
sliver of my app showing."

00:25:40.976 --> 00:25:43.026 A:middle
Well, we still consider
that to be visible.

00:25:43.316 --> 00:25:46.446 A:middle
And we also don't care which
part of the window is showing.

00:25:46.446 --> 00:25:47.746 A:middle
So maybe it's just a title bar.

00:25:48.166 --> 00:25:49.316 A:middle
That's still visible.

00:25:49.616 --> 00:25:51.906 A:middle
But if I finally move that
guy behind another window,

00:25:52.156 --> 00:25:54.186 A:middle
then we consider that
window to be occluded.

00:25:54.336 --> 00:25:58.676 A:middle
As far as minimized windows
go, if you minimize the window

00:25:58.676 --> 00:26:01.086 A:middle
to the dock, we consider
that to be occluded.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:58.676 --> 00:26:01.086 A:middle
to the dock, we consider
that to be occluded.

00:26:01.086 --> 00:26:04.876 A:middle
And for application
occlusion, it's the union

00:26:04.876 --> 00:26:06.136 A:middle
of all application windows.

00:26:06.196 --> 00:26:08.736 A:middle
So what I mean by that
is if even a little bit

00:26:08.736 --> 00:26:10.006 A:middle
of any window is showing,

00:26:10.406 --> 00:26:13.066 A:middle
then your application
is considered visible.

00:26:13.446 --> 00:26:15.006 A:middle
So all windows have
to be occluded

00:26:15.006 --> 00:26:16.476 A:middle
for your application
to be occluded.

00:26:16.746 --> 00:26:19.016 A:middle
The exception is
the menu bar except

00:26:19.016 --> 00:26:20.966 A:middle
if you have a status
item like this.

00:26:21.466 --> 00:26:24.296 A:middle
I don't know why Eyes would
have status item but if it did,

00:26:24.296 --> 00:26:25.976 A:middle
it would certainly
be that MOG icon.

00:26:26.846 --> 00:26:29.806 A:middle
So if that status item is
showing, then that counts

00:26:29.806 --> 00:26:31.156 A:middle
as a window for your
application.

00:26:31.686 --> 00:26:32.856 A:middle
So if the menu bar hides,

00:26:32.856 --> 00:26:33.976 A:middle
then that window would
also be occluded.

00:26:37.476 --> 00:26:38.546 A:middle
Here's what the API looks like.

00:26:38.546 --> 00:26:39.756 A:middle
We have two forms.

00:26:39.886 --> 00:26:43.326 A:middle
On NS Application Delegate
there's application did change

00:26:43.326 --> 00:26:46.556 A:middle
occlusion state and there's also
an NS notification if you prefer

00:26:46.556 --> 00:26:47.466 A:middle
to listen to it that way.

00:26:47.806 --> 00:26:49.706 A:middle
But either way, when you
receive that delegate message

00:26:49.706 --> 00:26:52.856 A:middle
or that notification, you can
query the current application

00:26:52.856 --> 00:26:56.276 A:middle
occlusion state by using the
NS Application Method Occlusion

00:26:56.276 --> 00:26:58.906 A:middle
State and it returns
a bit field.

00:26:59.216 --> 00:27:02.716 A:middle
So we only have 1 bit set right
-- or 1 bit defined right now.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:59.216 --> 00:27:02.716 A:middle
So we only have 1 bit set right
-- or 1 bit defined right now.

00:27:03.126 --> 00:27:05.586 A:middle
That's NS Application
Occlusion Stayed Visible.

00:27:06.266 --> 00:27:09.086 A:middle
So if your application is
visible, that bit is set.

00:27:09.166 --> 00:27:12.066 A:middle
If your application is
occluded or not visible

00:27:12.066 --> 00:27:14.196 A:middle
to the user, that
bit is not set.

00:27:15.096 --> 00:27:17.586 A:middle
The window API is almost
exactly the same except it's

00:27:17.586 --> 00:27:18.346 A:middle
on NS Window.

00:27:18.466 --> 00:27:20.276 A:middle
So Window Did Change
Occlusion State

00:27:20.626 --> 00:27:23.206 A:middle
and NS Window Occlusion
State Visible.

00:27:23.886 --> 00:27:26.016 A:middle
So for example, in
the Eyes Application,

00:27:26.386 --> 00:27:27.566 A:middle
we can set up this method

00:27:27.696 --> 00:27:29.816 A:middle
to check the current
occlusion state.

00:27:29.816 --> 00:27:31.416 A:middle
And you notice I've
used a bit wise

00:27:31.636 --> 00:27:33.526 A:middle
and operator here not equality.

00:27:33.646 --> 00:27:34.716 A:middle
That's because it's a bit field.

00:27:35.206 --> 00:27:37.766 A:middle
So anyway, if the
application is visible,

00:27:38.096 --> 00:27:39.596 A:middle
then I can install
my event monitors.

00:27:39.936 --> 00:27:41.876 A:middle
And if it's occluded,
then I can remove them.

00:27:45.236 --> 00:27:46.976 A:middle
So let's move on to
talking about timers.

00:27:47.726 --> 00:27:49.426 A:middle
So we found when
developing this feature

00:27:49.426 --> 00:27:52.366 A:middle
that most timers actually do
not need to be hyper accurate.

00:27:52.666 --> 00:27:54.896 A:middle
And by that I mean
you know 1 millisecond

00:27:54.896 --> 00:27:56.196 A:middle
or less kind of accuracy.

00:27:56.576 --> 00:27:57.556 A:middle
So again, what we've done

00:27:57.556 --> 00:28:00.546 A:middle
with timer coalescing is apply
basically a default tolerance

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:57.556 --> 00:28:00.546 A:middle
with timer coalescing is apply
basically a default tolerance

00:28:00.546 --> 00:28:01.386 A:middle
to all timers.

00:28:01.886 --> 00:28:06.446 A:middle
This new API allows you to
increase that default tolerance

00:28:06.666 --> 00:28:09.936 A:middle
and that allows the system to
fire your timer at the best time

00:28:09.986 --> 00:28:11.476 A:middle
in the window that you specify.

00:28:12.126 --> 00:28:15.076 A:middle
So for example, here
I have a timer.

00:28:15.076 --> 00:28:19.046 A:middle
It's set to have a start
date of 5 seconds from now,

00:28:20.226 --> 00:28:24.526 A:middle
a repeat interval of 7 seconds
and a tolerance of 3 seconds.

00:28:24.896 --> 00:28:27.686 A:middle
So what that means is this
timer can fire anytime between 5

00:28:27.686 --> 00:28:30.636 A:middle
and 8 seconds, 12 and 15
seconds, and so forth.

00:28:31.196 --> 00:28:34.636 A:middle
The system will decide
what the best time is.

00:28:35.046 --> 00:28:36.756 A:middle
So it maybe in the
middle of the window.

00:28:36.756 --> 00:28:38.556 A:middle
It could be right at the
beginning of the window

00:28:38.826 --> 00:28:40.546 A:middle
or it could be all the way
at the end of the window.

00:28:41.096 --> 00:28:43.756 A:middle
Now don't be surprised
if you see a lot

00:28:43.756 --> 00:28:46.336 A:middle
of timers firing near the
beginning of their windows

00:28:46.336 --> 00:28:48.836 A:middle
for now and that's
because we need more timers

00:28:48.836 --> 00:28:51.306 A:middle
on a system including your
applications to adopt this API.

00:28:51.976 --> 00:28:53.376 A:middle
And the more timers we have,

00:28:53.736 --> 00:28:55.876 A:middle
the better flexibility the
system has -- excuse me.

00:28:55.876 --> 00:28:57.226 A:middle
The more timers we
have with tolerance,

00:28:57.496 --> 00:29:00.296 A:middle
the better flexibility the
system has in aligning them

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:57.496 --> 00:29:00.296 A:middle
the better flexibility the
system has in aligning them

00:29:00.296 --> 00:29:01.466 A:middle
to save the most energy.

00:29:01.956 --> 00:29:03.766 A:middle
Here's the API.

00:29:03.766 --> 00:29:06.096 A:middle
It's on NS Timer and
hopefully it should --

00:29:06.176 --> 00:29:07.016 A:middle
it's not surprising.

00:29:07.016 --> 00:29:08.186 A:middle
It's called Set Tolerance.

00:29:08.416 --> 00:29:09.636 A:middle
And there's a getter as well.

00:29:09.966 --> 00:29:12.876 A:middle
And we also have similar API
on CF Run Loop Timer as well.

00:29:12.876 --> 00:29:17.646 A:middle
So what I'll do here
is create my timer.

00:29:17.726 --> 00:29:19.876 A:middle
Again, it has a time
interval of 7 seconds

00:29:20.396 --> 00:29:23.506 A:middle
and it fires my Timer Fired
Method and it's set to repeat.

00:29:23.846 --> 00:29:25.956 A:middle
The fire date is
5 seconds from now

00:29:26.026 --> 00:29:28.156 A:middle
and it has a tolerance
of 3 seconds.

00:29:28.586 --> 00:29:30.206 A:middle
And then finally I
add it to my run loop.

00:29:30.756 --> 00:29:33.186 A:middle
We also have a similar
API on Dispatch Timers.

00:29:33.186 --> 00:29:34.926 A:middle
So if you haven't used
Dispatch Timers before,

00:29:34.926 --> 00:29:36.406 A:middle
they're a kind of
dispatch source.

00:29:36.406 --> 00:29:38.906 A:middle
This one is a dispatch
source type timer.

00:29:39.296 --> 00:29:40.856 A:middle
The queue there is
the queue upon

00:29:40.856 --> 00:29:43.646 A:middle
which my event handler will be
invoked when the timer fires.

00:29:44.076 --> 00:29:47.176 A:middle
And then I use the Dispatch
Source Set Timer API

00:29:47.826 --> 00:29:51.356 A:middle
to specify the start time, the
interval and the tolerance.

00:29:51.696 --> 00:29:53.386 A:middle
And finally, don't forget
to resume your timer

00:29:53.386 --> 00:29:55.736 A:middle
if you actually want it to fire.

00:29:55.736 --> 00:29:58.316 A:middle
This API has actually been
around since we introduced it.

00:29:58.486 --> 00:30:00.266 A:middle
The last parameter
before though was ignored.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:58.486 --> 00:30:00.266 A:middle
The last parameter
before though was ignored.

00:30:00.466 --> 00:30:03.046 A:middle
So now starting in
Mavericks, we are going

00:30:03.046 --> 00:30:05.016 A:middle
to start obeying that value.

00:30:05.016 --> 00:30:06.326 A:middle
And that will contribute

00:30:06.326 --> 00:30:07.966 A:middle
to the overall efficiency
of the system.

00:30:11.346 --> 00:30:14.556 A:middle
I said earlier that the timer
rate limiting can be configured

00:30:14.846 --> 00:30:15.956 A:middle
and this is how.

00:30:16.256 --> 00:30:19.006 A:middle
So if you have 1 timer
that needs to be exempt

00:30:19.006 --> 00:30:21.986 A:middle
from rate limiting, then
you can set this flag:

00:30:22.096 --> 00:30:23.536 A:middle
Dispatch Timer Strict.

00:30:24.636 --> 00:30:27.656 A:middle
Now, I really recommend
caution when using this.

00:30:27.986 --> 00:30:29.496 A:middle
As we saw from the Eyes Demo,

00:30:29.676 --> 00:30:31.206 A:middle
the rate limiting
had a huge effect

00:30:31.206 --> 00:30:32.846 A:middle
on energy efficiency
of the system.

00:30:33.356 --> 00:30:35.826 A:middle
So we imagine that this is
only for the kinds of cases

00:30:35.826 --> 00:30:39.006 A:middle
where you have very strict
requirements like interaction

00:30:39.006 --> 00:30:42.886 A:middle
with hardware or perhaps some
kind of networking restriction.

00:30:42.886 --> 00:30:45.306 A:middle
So please be very
careful when using this.

00:30:45.706 --> 00:30:47.576 A:middle
In any case, if you use this,

00:30:47.836 --> 00:30:49.886 A:middle
you still always should
specify tolerance.

00:30:50.016 --> 00:30:52.266 A:middle
Here I've specified a
value of 700 milliseconds

00:30:52.266 --> 00:30:55.026 A:middle
or about 10 percent and that's
because even a small amount

00:30:55.026 --> 00:30:56.346 A:middle
of tolerance will
allow the system

00:30:56.346 --> 00:30:58.456 A:middle
to get much better
energy efficiency.

00:30:58.456 --> 00:31:00.906 A:middle
So please never pass zero
in for that argument.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:58.456 --> 00:31:00.906 A:middle
So please never pass zero
in for that argument.

00:31:01.406 --> 00:31:06.636 A:middle
So again we suggest
about 10 percent

00:31:06.776 --> 00:31:08.286 A:middle
of your interval as a tolerance.

00:31:08.696 --> 00:31:11.316 A:middle
Exact value is the -- going
to be application specific.

00:31:11.636 --> 00:31:13.286 A:middle
Maybe it's more or
it could be less.

00:31:13.286 --> 00:31:16.476 A:middle
And so we leave it up to you.

00:31:16.476 --> 00:31:18.076 A:middle
So this is an important note.

00:31:18.386 --> 00:31:20.466 A:middle
This tolerance is used
regardless of AppNap.

00:31:20.466 --> 00:31:23.486 A:middle
So that allows us to make timers
more efficient even in apps

00:31:23.486 --> 00:31:25.706 A:middle
that are foreground or
are actively drawing.

00:31:25.706 --> 00:31:28.626 A:middle
So we can get even
better energy efficiency

00:31:28.626 --> 00:31:29.796 A:middle
by adopting tolerance.

00:31:30.626 --> 00:31:32.806 A:middle
Again, the strict
timer should be rare.

00:31:33.216 --> 00:31:34.676 A:middle
It disables the timer
rate limiting.

00:31:34.956 --> 00:31:36.066 A:middle
But even if you do that,

00:31:36.066 --> 00:31:37.746 A:middle
you should still
specify a tolerance.

00:31:38.296 --> 00:31:40.386 A:middle
And finally as I mentioned,

00:31:40.656 --> 00:31:42.956 A:middle
we'd really like all
timers to have tolerances.

00:31:43.056 --> 00:31:44.376 A:middle
And that's because
the more timers

00:31:44.376 --> 00:31:46.666 A:middle
that have a window
associated with them,

00:31:47.016 --> 00:31:48.716 A:middle
the better we can align
them across the system.

00:31:52.456 --> 00:31:54.406 A:middle
Next let's talk about
user activities.

00:31:54.946 --> 00:31:55.866 A:middle
So this is our new API

00:31:55.946 --> 00:31:58.546 A:middle
to improve the accuracy
of AppNap heuristics.

00:31:59.186 --> 00:32:01.556 A:middle
It's used for long running
or asynchronous work

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:31:59.186 --> 00:32:01.556 A:middle
It's used for long running
or asynchronous work

00:32:02.976 --> 00:32:05.966 A:middle
and it's a Cocoa -- it's
a new Cocoa level API

00:32:06.036 --> 00:32:07.396 A:middle
to prevent idle system sleep.

00:32:07.396 --> 00:32:10.606 A:middle
So if you've used the I/O Kit
Power Searching API in the past,

00:32:10.956 --> 00:32:12.966 A:middle
now we have a Cocoa API
for you to use as well.

00:32:13.586 --> 00:32:17.366 A:middle
And it also has a new
interface to automatic

00:32:17.366 --> 00:32:18.406 A:middle
and sudden termination.

00:32:18.956 --> 00:32:20.466 A:middle
So here's he API.

00:32:20.536 --> 00:32:21.556 A:middle
It comes in two forms.

00:32:21.856 --> 00:32:23.716 A:middle
The first is called
Perform Activity

00:32:23.716 --> 00:32:25.146 A:middle
with Options Reason Block.

00:32:25.716 --> 00:32:27.796 A:middle
The first argument
describes the kind of activity

00:32:27.796 --> 00:32:28.796 A:middle
that you're going to do.

00:32:28.796 --> 00:32:30.136 A:middle
And we'll see what
those are in a minute.

00:32:30.596 --> 00:32:32.496 A:middle
The second argument
is a reason string.

00:32:32.576 --> 00:32:34.006 A:middle
And I strongly encourage you

00:32:34.006 --> 00:32:37.896 A:middle
to always specify a
useful reason string here.

00:32:37.896 --> 00:32:39.346 A:middle
And that's because it
will show up in some

00:32:39.346 --> 00:32:40.356 A:middle
of our debugging tools.

00:32:40.636 --> 00:32:42.186 A:middle
And I'll show you that
in a minute as well.

00:32:42.186 --> 00:32:43.856 A:middle
For this form of the API,

00:32:44.346 --> 00:32:45.856 A:middle
the block is performed
synchronously.

00:32:45.936 --> 00:32:46.876 A:middle
So that means you
don't have to worry

00:32:46.876 --> 00:32:49.426 A:middle
about ending the activity
when you're finished.

00:32:49.656 --> 00:32:51.336 A:middle
You can just do it
all in one chunk.

00:32:51.336 --> 00:32:52.986 A:middle
And the system takes
care of the rest.

00:32:53.426 --> 00:32:55.756 A:middle
If however you want to do it
asynchronously, that's fine.

00:32:55.756 --> 00:32:57.016 A:middle
That's the second
form of the API.

00:32:57.556 --> 00:32:59.996 A:middle
It's called The End
Activity with Options Reason.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:33:00.296 --> 00:33:02.616 A:middle
Those two parameters
are the same as before

00:33:02.616 --> 00:33:04.206 A:middle
but this one returns an object.

00:33:04.366 --> 00:33:07.646 A:middle
And you can either store that
object in an IVAR or put it

00:33:07.646 --> 00:33:09.096 A:middle
in a collection or
whatever you want.

00:33:09.406 --> 00:33:11.446 A:middle
The important part is to
remember that when you're done,

00:33:11.796 --> 00:33:14.596 A:middle
call end activity and
passing that object again.

00:33:14.596 --> 00:33:20.436 A:middle
So here are the kind of
activities that you can specify:

00:33:21.106 --> 00:33:23.686 A:middle
if you're doing something
that's explicitly user initiated

00:33:23.686 --> 00:33:28.326 A:middle
like exporting a file or
recording or processing.

00:33:28.516 --> 00:33:31.806 A:middle
For example, anything the user
might choose from the menu item

00:33:31.806 --> 00:33:34.746 A:middle
and then you know actually pick
or click on a button and do.

00:33:35.356 --> 00:33:38.196 A:middle
You use the NS Activity
User Initiated Constant.

00:33:39.286 --> 00:33:40.476 A:middle
Now when developing
this feature,

00:33:40.476 --> 00:33:43.466 A:middle
we found that many
applications hadn't

00:33:43.466 --> 00:33:47.746 A:middle
yet considered what the behavior
of their application should be

00:33:48.116 --> 00:33:50.476 A:middle
with respect to the system
falling into idle sleep.

00:33:50.866 --> 00:33:53.446 A:middle
So maybe my export
takes 30 minutes

00:33:53.716 --> 00:33:56.276 A:middle
but the user has asked the
system to idle sleep after 15.

00:33:56.776 --> 00:33:58.706 A:middle
So is that something
that the user expected

00:33:58.706 --> 00:34:01.676 A:middle
to finish beforehand and then
let the system sleep or not?

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:33:58.706 --> 00:34:01.676 A:middle
to finish beforehand and then
let the system sleep or not?

00:34:02.086 --> 00:34:04.716 A:middle
And that's sort of really up
to you in your application

00:34:04.716 --> 00:34:06.026 A:middle
and your specific use case.

00:34:06.436 --> 00:34:08.676 A:middle
So when you're using this
API, we really want you to sit

00:34:08.676 --> 00:34:10.496 A:middle
down and think about it.

00:34:10.496 --> 00:34:11.985 A:middle
Which of those behaviors
should it be?

00:34:12.456 --> 00:34:15.436 A:middle
So the NS Activity User
Initiated Constant actually

00:34:15.436 --> 00:34:17.606 A:middle
includes a no idle
system sleep assertion.

00:34:17.735 --> 00:34:19.496 A:middle
So that means while
your activity

00:34:19.496 --> 00:34:21.255 A:middle
with this option is active,

00:34:21.556 --> 00:34:23.696 A:middle
the system will not be
allowed to idle system sleep.

00:34:24.846 --> 00:34:26.726 A:middle
And we think that's the
right choice for activities

00:34:26.726 --> 00:34:28.315 A:middle
that are explicitly
done by the user.

00:34:28.916 --> 00:34:30.616 A:middle
If however you think
that it should be allowed

00:34:30.616 --> 00:34:33.396 A:middle
to idle system sleep, then
the next constant is the one

00:34:33.396 --> 00:34:33.746 A:middle
for you.

00:34:34.396 --> 00:34:37.235 A:middle
If you're doing some
kind of maintenance

00:34:37.235 --> 00:34:38.246 A:middle
or other background work,

00:34:38.246 --> 00:34:40.606 A:middle
you can use the NS
Activity Background Option.

00:34:42.045 --> 00:34:43.786 A:middle
And finally, if you're doing
something that's latency

00:34:43.786 --> 00:34:46.996 A:middle
sensitive like strict timers,
we think this is pretty rare,

00:34:47.436 --> 00:34:50.996 A:middle
you can bit wise or NS Activity
Latency Critical with any

00:34:50.996 --> 00:34:52.726 A:middle
of the previous flags to get --

00:34:53.056 --> 00:34:54.826 A:middle
to indicate that
kind of requirement.

00:34:55.366 --> 00:35:00.436 A:middle
So I said earlier, this
is a new API to interface

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:55.366 --> 00:35:00.436 A:middle
So I said earlier, this
is a new API to interface

00:35:00.436 --> 00:35:03.336 A:middle
with I/O K Power Assertions and
this is how you would do it.

00:35:03.636 --> 00:35:05.496 A:middle
You can begin an
activity with the option

00:35:05.496 --> 00:35:07.866 A:middle
of NS Activity Idle
System Sleep Disable.

00:35:08.206 --> 00:35:10.026 A:middle
And while that activity
is active,

00:35:10.406 --> 00:35:12.756 A:middle
again the system will not be
allowed to idle system sleep.

00:35:12.756 --> 00:35:15.096 A:middle
And we have a constant for
displaced sleep as well.

00:35:15.956 --> 00:35:18.316 A:middle
And finally, you can also use
this for sudden termination

00:35:18.316 --> 00:35:19.366 A:middle
and automatic termination.

00:35:19.366 --> 00:35:21.166 A:middle
So this is a little
bit different

00:35:21.166 --> 00:35:24.806 A:middle
than the existing count API on
NS Process Info and Foundation.

00:35:25.156 --> 00:35:26.836 A:middle
So you can use either
one that you like.

00:35:27.156 --> 00:35:28.176 A:middle
The idea behind this one is

00:35:28.176 --> 00:35:30.066 A:middle
that with the synchronous method
you don't have to remember

00:35:30.066 --> 00:35:32.016 A:middle
to decrement your
counter afterwards

00:35:32.016 --> 00:35:33.066 A:middle
so call in the End Method.

00:35:33.536 --> 00:35:36.546 A:middle
And with the object based API,
it might be a little bit easier

00:35:36.546 --> 00:35:38.646 A:middle
to track the assertion
that you're holding

00:35:38.646 --> 00:35:42.066 A:middle
so you can keep it in IVAR
like I said or if you lose it,

00:35:42.066 --> 00:35:44.176 A:middle
you can track it with
leaks and instruments.

00:35:44.656 --> 00:35:48.546 A:middle
Here's an example of
how you might use this.

00:35:49.066 --> 00:35:52.006 A:middle
I'm going to have an
NS Operation Queue

00:35:52.006 --> 00:35:54.136 A:middle
that has long running
asynchronous user work

00:35:54.576 --> 00:35:57.896 A:middle
and I will begin when the user
has chosen my you know Record

00:35:57.896 --> 00:35:59.136 A:middle
Option from the File menu.

00:35:59.556 --> 00:36:02.056 A:middle
Then I'm going to begin -- or
excuse me, Batch Process Option.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:59.556 --> 00:36:02.056 A:middle
Then I'm going to begin -- or
excuse me, Batch Process Option.

00:36:02.396 --> 00:36:04.206 A:middle
Then I'm going to begin
activity with options.

00:36:04.546 --> 00:36:06.436 A:middle
Here it seems like something
that should keep the system

00:36:06.436 --> 00:36:08.016 A:middle
from falling into
idle system sleep

00:36:08.376 --> 00:36:10.816 A:middle
so I chose NS Activity
User Initiated.

00:36:10.996 --> 00:36:13.456 A:middle
And the reason is because
I'm batch processing files.

00:36:14.636 --> 00:36:16.406 A:middle
Then I add my work to the queue.

00:36:16.576 --> 00:36:20.046 A:middle
And when that work is done, then
I remember to call End Activity

00:36:20.286 --> 00:36:22.866 A:middle
with the token that I got back
from the previous API call.

00:36:22.996 --> 00:36:27.936 A:middle
So you can actually have many

00:36:27.936 --> 00:36:29.316 A:middle
of these activities
at the same time.

00:36:29.626 --> 00:36:31.416 A:middle
The system will do the right
thing with all of them.

00:36:31.646 --> 00:36:33.076 A:middle
So for example, let's
say that you have a piece

00:36:33.076 --> 00:36:35.656 A:middle
of your application that's doing
some kind of background work.

00:36:35.946 --> 00:36:38.266 A:middle
It can use the NS Activity
Background Constant.

00:36:38.646 --> 00:36:42.516 A:middle
But then simultaneously the
user chooses a menu item

00:36:42.516 --> 00:36:43.366 A:middle
from the File menu.

00:36:43.716 --> 00:36:47.466 A:middle
Then that could be an NS
Activity User Initiated activity

00:36:47.906 --> 00:36:50.756 A:middle
and will do the right thing.

00:36:50.976 --> 00:36:52.436 A:middle
You should avoid
rapidly starting

00:36:52.436 --> 00:36:53.706 A:middle
and ending these activities.

00:36:53.776 --> 00:36:56.406 A:middle
Again, they're for long running
work or asynchronous work.

00:36:56.806 --> 00:36:59.826 A:middle
We automatically handle this
for you for event call outs

00:36:59.826 --> 00:37:01.166 A:middle
on the main thread for example.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:36:59.826 --> 00:37:01.166 A:middle
on the main thread for example.

00:37:01.736 --> 00:37:06.486 A:middle
And finally, please remember
the idle system sleep assertions

00:37:06.486 --> 00:37:07.866 A:middle
should really be used with care.

00:37:08.196 --> 00:37:10.156 A:middle
Don't prevent idle
system sleep forever.

00:37:10.676 --> 00:37:12.406 A:middle
So we've been talking
about efficiencies gained

00:37:12.406 --> 00:37:16.446 A:middle
by moving timers by a little bit
but nothing's worse for the user

00:37:16.446 --> 00:37:19.246 A:middle
than leaving their laptop
doing some work at night

00:37:19.546 --> 00:37:20.966 A:middle
and they come back in
the morning and it's

00:37:20.966 --> 00:37:24.416 A:middle
at zero percent battery because
some application just kept the

00:37:24.416 --> 00:37:25.886 A:middle
system from sleeping
appropriately.

00:37:26.276 --> 00:37:28.226 A:middle
So please verify
in your application

00:37:28.226 --> 00:37:29.606 A:middle
that the power assertions
are dropped

00:37:29.966 --> 00:37:31.186 A:middle
when you're doing that work.

00:37:32.426 --> 00:37:33.556 A:middle
Here's how you can do it.

00:37:33.736 --> 00:37:35.446 A:middle
Use the PM set, Command
Line tool.

00:37:36.466 --> 00:37:38.566 A:middle
[Inaudible] -g assertions and
it gives you a great output

00:37:38.566 --> 00:37:40.226 A:middle
that tells you which
applications

00:37:40.226 --> 00:37:42.306 A:middle
on the system have taken
which kinds of assertions.

00:37:42.646 --> 00:37:47.046 A:middle
So here I've modified Eyes
inappropriately of course

00:37:47.046 --> 00:37:48.816 A:middle
to keep the user's
computer awake.

00:37:49.226 --> 00:37:50.436 A:middle
So we can see there,
it's been doing it

00:37:50.436 --> 00:37:51.966 A:middle
for 3 minutes and 36 seconds.

00:37:52.306 --> 00:37:54.506 A:middle
And the reason string is the one

00:37:54.506 --> 00:37:55.956 A:middle
that we passed into
our API earlier.

00:37:56.036 --> 00:37:57.006 A:middle
So this is a great example

00:37:57.006 --> 00:37:59.946 A:middle
of why passing a real
reason string can be useful

00:37:59.946 --> 00:38:00.726 A:middle
to help you debug.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:59.946 --> 00:38:00.726 A:middle
to help you debug.

00:38:01.116 --> 00:38:03.556 A:middle
So use this tool to verify
that you have an assertion

00:38:03.556 --> 00:38:05.296 A:middle
when you expect and
that when you're done,

00:38:05.386 --> 00:38:06.806 A:middle
it's actually not
listed here at all.

00:38:07.426 --> 00:38:11.266 A:middle
So let's go back to our
demo and show you --

00:38:11.266 --> 00:38:13.566 A:middle
I want to show you how we can
improve the Eyes application

00:38:13.566 --> 00:38:15.886 A:middle
with some of the API
that we talked about.

00:38:16.536 --> 00:38:18.566 A:middle
So when we left off,
I was running the Eyes

00:38:18.566 --> 00:38:20.086 A:middle
and I hid it behind X Code

00:38:20.326 --> 00:38:23.046 A:middle
but it was still using
energy even though it was

00:38:23.046 --> 00:38:23.866 A:middle
completely occluded.

00:38:24.226 --> 00:38:28.176 A:middle
So we can use the new
occlusion API to improve that.

00:38:28.226 --> 00:38:29.976 A:middle
So I have a branch
ready for that as well.

00:38:30.516 --> 00:38:38.166 A:middle
[ Pause ]

00:38:38.666 --> 00:38:42.176 A:middle
And what I did is added our
Application Did Change Occlusion

00:38:42.176 --> 00:38:42.726 A:middle
State Method.

00:38:43.096 --> 00:38:45.536 A:middle
And you can see here, that
when that's called I query the

00:38:45.536 --> 00:38:47.596 A:middle
occlusion state again
using the bit wise and,

00:38:47.986 --> 00:38:51.686 A:middle
and if we're visible I install
the event monitors and if not,

00:38:51.686 --> 00:38:53.286 A:middle
I remove the event monitors.

00:38:53.446 --> 00:38:54.406 A:middle
It's pretty straightforward.

00:38:54.646 --> 00:38:57.976 A:middle
So I added this Remove Event
Monitors Method as well

00:38:58.206 --> 00:39:01.086 A:middle
and this uses the NS Event API
that we talked about earlier

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:58.206 --> 00:39:01.086 A:middle
and this uses the NS Event API
that we talked about earlier

00:39:01.346 --> 00:39:03.636 A:middle
to remove the event monitors
that we had installed.

00:39:04.066 --> 00:39:06.586 A:middle
So let's go ahead and run
our application again.

00:39:07.276 --> 00:39:12.666 A:middle
And we'll hide it and
bring up our energy gauge.

00:39:13.246 --> 00:39:15.716 A:middle
And again, there might be
some activity that you see

00:39:15.716 --> 00:39:18.046 A:middle
on the graph here
as system frameworks

00:39:18.046 --> 00:39:20.336 A:middle
and libraries do a little
bit of work on your behalf.

00:39:20.756 --> 00:39:22.836 A:middle
But in general, when
I move my mouse,

00:39:22.926 --> 00:39:26.246 A:middle
we stay at about zero
wakes and zero impact.

00:39:26.246 --> 00:39:29.966 A:middle
So this is going to
be a much better story

00:39:29.966 --> 00:39:31.976 A:middle
for energy efficiency than
even the last version of Eyes.

00:39:32.516 --> 00:39:35.616 A:middle
[ Pause ]

00:39:36.116 --> 00:39:36.426 A:middle
Here we go.

00:39:36.746 --> 00:39:38.816 A:middle
Zero wakes and zero activity.

00:39:39.306 --> 00:39:43.696 A:middle
Alright, I want to show
you one more thing.

00:39:44.536 --> 00:39:47.286 A:middle
I've added a new feature to Eyes

00:39:47.286 --> 00:39:48.246 A:middle
which I think you'll
really like.

00:39:55.476 --> 00:39:56.536 A:middle
Let's go ahead and run it.

00:39:57.016 --> 00:39:59.486 A:middle
Now if I go up to the File
menu and choose Record,

00:39:59.486 --> 00:40:02.636 A:middle
you can see here in the
corner that Eyes is telling us

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:39:59.486 --> 00:40:02.636 A:middle
you can see here in the
corner that Eyes is telling us

00:40:02.676 --> 00:40:05.496 A:middle
that it's currently
recording our mouse movements.

00:40:05.496 --> 00:40:08.066 A:middle
And if I move my mouse
around here for a while,

00:40:10.226 --> 00:40:12.826 A:middle
and I stop recording, it
tells me I travelled 7

00:40:12.946 --> 00:40:13.976 A:middle
thousand points.

00:40:15.156 --> 00:40:16.486 A:middle
That's a pretty good score

00:40:16.486 --> 00:40:19.886 A:middle
but I've actually done
better in the past.

00:40:20.686 --> 00:40:22.466 A:middle
So anyway, let's go back
to our source code here

00:40:22.466 --> 00:40:23.456 A:middle
and see how that works.

00:40:23.806 --> 00:40:26.516 A:middle
I added a new method
called Toggle Recording.

00:40:27.576 --> 00:40:31.036 A:middle
And recording since I choose
it from the File menu seems

00:40:31.036 --> 00:40:32.476 A:middle
like a user initiated action.

00:40:32.936 --> 00:40:35.376 A:middle
So what I do is if I'm
not already recording,

00:40:36.136 --> 00:40:39.516 A:middle
I tell the system that by saying
Begin Activity with Options,

00:40:39.826 --> 00:40:42.886 A:middle
NS Activity User Initiated
Allowing Idle System Sleep.

00:40:43.076 --> 00:40:44.326 A:middle
And I give it a reason as well.

00:40:45.576 --> 00:40:47.306 A:middle
Now I said earlier that
when you use this API,

00:40:47.306 --> 00:40:49.676 A:middle
I want you to think
about what kind

00:40:49.676 --> 00:40:50.986 A:middle
of options you should choose.

00:40:51.366 --> 00:40:52.746 A:middle
So in this case I said, "Well,

00:40:53.066 --> 00:40:54.516 A:middle
if the user's not
moving their mouse,

00:40:54.516 --> 00:40:57.126 A:middle
well then there's really
nothing for Eyes to do.

00:40:57.286 --> 00:41:00.156 A:middle
So there's no reason for Eyes
to keep the system from falling

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:57.286 --> 00:41:00.156 A:middle
So there's no reason for Eyes
to keep the system from falling

00:41:00.156 --> 00:41:01.206 A:middle
into idle system sleep."

00:41:01.676 --> 00:41:04.526 A:middle
And so that's why I chose the
Allowing Idle System Sleep

00:41:04.526 --> 00:41:07.826 A:middle
version of the options here.

00:41:08.126 --> 00:41:10.296 A:middle
And I want you again to think
about that when you look

00:41:10.296 --> 00:41:11.266 A:middle
through your use cases.

00:41:12.656 --> 00:41:15.946 A:middle
Finally I set up some
iBars and the UI and then

00:41:15.946 --> 00:41:20.716 A:middle
when the user chooses that menu
item again, we end the activity

00:41:20.716 --> 00:41:22.456 A:middle
by calling NS Processing.

00:41:22.456 --> 00:41:25.066 A:middle
So it's End Activity with
the User Activity Token.

00:41:25.416 --> 00:41:28.476 A:middle
So we make sure that we
balance our begin with an end.

00:41:31.176 --> 00:41:33.876 A:middle
The only other change I really
made here was you know a set

00:41:33.876 --> 00:41:36.766 A:middle
up method, I need to look
at both the occlusion state

00:41:36.966 --> 00:41:39.506 A:middle
and our recording state so
I know when it's appropriate

00:41:39.506 --> 00:41:40.926 A:middle
to have the event that
monitors installed.

00:41:41.606 --> 00:41:46.646 A:middle
So the result is that if I bring
up Activity Monitor again here

00:41:47.466 --> 00:41:53.886 A:middle
and begin recording with
Eyes, and we'll go ahead

00:41:53.886 --> 00:41:55.256 A:middle
and occlude it, we'll notice

00:41:55.256 --> 00:41:58.246 A:middle
that this time the AppNap column
- I'll zoom in for you here -

00:41:58.866 --> 00:42:00.386 A:middle
the AppNap column remains at No.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:41:58.866 --> 00:42:00.386 A:middle
the AppNap column remains at No.

00:42:00.836 --> 00:42:04.496 A:middle
And that's because using the
NS Activity Options API we've

00:42:04.496 --> 00:42:07.646 A:middle
helped tell the system what
the user is actually interested

00:42:07.646 --> 00:42:08.066 A:middle
in doing.

00:42:08.156 --> 00:42:10.416 A:middle
In this case it was
recording the mouse location.

00:42:10.946 --> 00:42:13.656 A:middle
And so we can factor
that into our heuristics

00:42:13.656 --> 00:42:14.746 A:middle
about whether it's appropriate

00:42:14.746 --> 00:42:17.186 A:middle
to put the app into
AppNap or not.

00:42:18.016 --> 00:42:22.636 A:middle
Now if I go back to Eyes
here and stop recording

00:42:23.246 --> 00:42:26.066 A:middle
and occlude it once more,

00:42:26.486 --> 00:42:28.366 A:middle
we'll see that because we told
the system that we're done

00:42:28.366 --> 00:42:31.596 A:middle
with that activity, that
allows it to incorporate

00:42:31.596 --> 00:42:34.626 A:middle
that into our heuristics and
we'll that it now is allowed

00:42:34.626 --> 00:42:36.036 A:middle
to go back into AppNap.

00:42:36.036 --> 00:42:37.976 A:middle
Let's go back to our slides.

00:42:38.516 --> 00:42:42.016 A:middle
[ Pause ]

00:42:42.516 --> 00:42:43.736 A:middle
So let's do a quick summary.

00:42:43.926 --> 00:42:48.046 A:middle
I want you to remember
what an impact software has

00:42:48.046 --> 00:42:49.046 A:middle
on energy efficiency.

00:42:49.166 --> 00:42:51.636 A:middle
It's easy to think that
it's just a responsibility

00:42:51.636 --> 00:42:54.136 A:middle
of you know this backlight
or the screen or the GPU,

00:42:54.636 --> 00:42:57.196 A:middle
but the CPU is where
we do our work

00:42:57.346 --> 00:42:59.436 A:middle
and that is what drives
the rest of the system.

00:42:59.436 --> 00:43:01.956 A:middle
And the CPU has that
high dynamic range.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:59.436 --> 00:43:01.956 A:middle
And the CPU has that
high dynamic range.

00:43:01.996 --> 00:43:03.976 A:middle
So what we're doing
in our applications

00:43:03.976 --> 00:43:06.106 A:middle
and in our system can
make a real big difference

00:43:06.106 --> 00:43:07.296 A:middle
on the user's battery life.

00:43:08.666 --> 00:43:11.016 A:middle
Remember the three key rules
of extending battery life.

00:43:11.296 --> 00:43:13.516 A:middle
First, we need to stay
at idle, that low power,

00:43:13.516 --> 00:43:16.006 A:middle
0.4 watt idle state
as long as possible.

00:43:16.556 --> 00:43:18.886 A:middle
Second, we need to
avoid unnecessary work

00:43:19.266 --> 00:43:21.506 A:middle
like redrawing a pair
of eyes behind a window

00:43:21.506 --> 00:43:22.506 A:middle
when you can't even see them.

00:43:22.986 --> 00:43:24.766 A:middle
And third, when we're
doing work,

00:43:24.766 --> 00:43:26.136 A:middle
we need to race back to idle.

00:43:26.136 --> 00:43:28.966 A:middle
That is return to that idle
state as quickly as possible

00:43:29.136 --> 00:43:31.726 A:middle
because the longer we spend
in our 0.4 watt idle state,

00:43:32.086 --> 00:43:33.996 A:middle
the longer the battery
life is going to be.

00:43:36.336 --> 00:43:37.416 A:middle
And also please remember

00:43:37.416 --> 00:43:40.406 A:middle
that avoiding timers
allows for longer idle time.

00:43:41.286 --> 00:43:46.236 A:middle
If you can, instead use event
based API like the Event Monitor

00:43:46.236 --> 00:43:48.086 A:middle
that we used for the
Eyes application.

00:43:49.216 --> 00:43:53.156 A:middle
And finally, if you must use
timers, please add tolerance.

00:43:53.486 --> 00:43:56.806 A:middle
And actually also,
use the Activity API

00:43:57.296 --> 00:43:59.806 A:middle
to inform the system
of important user work

00:43:59.806 --> 00:44:02.656 A:middle
like recording, batch
processing, and so forth.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:59.806 --> 00:44:02.656 A:middle
like recording, batch
processing, and so forth.

00:44:03.006 --> 00:44:04.566 A:middle
And please remember
to take into account

00:44:04.766 --> 00:44:06.876 A:middle
that idle system sleep
assertion and verify

00:44:06.876 --> 00:44:09.066 A:middle
that you are taking them
and dropping them correctly.

00:44:09.066 --> 00:44:13.526 A:middle
We've had a bunch of
related sessions this week.

00:44:13.526 --> 00:44:15.656 A:middle
Most of them have already
happened so if you missed them,

00:44:15.656 --> 00:44:17.496 A:middle
these are great sessions
to catch on video:

00:44:17.796 --> 00:44:21.796 A:middle
especially the first one where
we had a great talk about -

00:44:21.796 --> 00:44:24.316 A:middle
in depth - the new features
of some of our new --

00:44:24.316 --> 00:44:26.056 A:middle
the new Intel processors and how

00:44:26.056 --> 00:44:27.716 A:middle
that has an impact
on battery life.

00:44:28.276 --> 00:44:31.436 A:middle
Building efficient OS
X apps: talked a lot

00:44:31.436 --> 00:44:32.896 A:middle
about improving the
responsiveness

00:44:32.896 --> 00:44:33.796 A:middle
of your application.

00:44:34.446 --> 00:44:36.836 A:middle
The next session which
was just this morning --

00:44:37.506 --> 00:44:38.916 A:middle
so a lot of the features
we've been talking

00:44:38.916 --> 00:44:42.086 A:middle
about today also apply
to web pages via Safari.

00:44:42.366 --> 00:44:45.776 A:middle
So if you're a web developer,
then please check out that video

00:44:46.016 --> 00:44:48.216 A:middle
to understand how
it impacts you.

00:44:48.796 --> 00:44:50.516 A:middle
And finally tomorrow
we have another session

00:44:50.516 --> 00:44:52.856 A:middle
on Energy Best Practices.

00:44:52.856 --> 00:44:55.476 A:middle
So that's going to talk a lot
about moving away from timers

00:44:55.816 --> 00:44:59.296 A:middle
and towards more event based API
for maximum energy efficiency.

00:44:59.326 --> 00:45:01.996 A:middle
If you're not here at the
conference, then please get

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:59.326 --> 00:45:01.996 A:middle
If you're not here at the
conference, then please get

00:45:01.996 --> 00:45:05.056 A:middle
in contact with our
Evangelism Team or talk to us

00:45:05.056 --> 00:45:05.986 A:middle
on the Developer Forums.

00:45:05.986 --> 00:45:08.816 A:middle
I browse that and try to
answer questions if I can along

00:45:08.816 --> 00:45:10.516 A:middle
with many other members
of the Cocoa team.

00:45:11.966 --> 00:45:13.356 A:middle
So with that, I want
to thank you for coming

00:45:13.356 --> 00:45:14.356 A:middle
and learning about AppNap.

00:45:15.516 --> 00:45:20.810 A:middle
[ Applause ]