Transcript
>> Battery life is very
important to your users.
And apps are directly tied to
battery life.
So as developers, it's very
important that we're careful
about how we write our code.
And the reason for this is if
I'm a user and I'm having bad
battery life, the first thing
I'm going to do is I'm going to
go to the Battery Usage screen.
I'm going to take a look at what
apps are using a lot of my
energy.
If I notice that your app is
near the top and I don't expect
it to be there, I'm not going to
be very happy about that and I
may even delete your app.
And so today, I'm going to talk
about some battery life
concepts.
Then, we're going to move on and
we're going to talk about energy
efficient coding practices.
From there, my colleague will
come up and talk to you about
energy debugging tools that are
available to you as well as give
you a demo.
And then we'll wrap it up with
some final thoughts.
So let's get started.
What is energy?
Well, energy is the product of
power and time.
And I'd like to illustrate this
with an example.
As you can see here, when the
device is idle, the power is
very low.
Yet when the device is active,
the power is very high.
And you also notice that the
power can be even higher and
that depends on how much work
you're doing or the type of work
that you're doing.
You'll also notice that there's
overhead and that's the amount
of power that's needed to bring
the hardware up to be able to do
your work as well as put it back
to sleep.
And so as I said before, energy
is the product of power and time
and that's the area under the
curve.
And I'd like to take this one
step further.
The energy that you have is
split into two regions: fixed
costs and dynamic costs.
The dynamic costs are the work
that you're doing and the fixed
costs are that overhead that we
talked about earlier, the amount
of energy needed to bring the
hardware up to do your work in
the first place.
So even if you're doing a small
amount of work, you're still
going to have to pay those
overhead costs.
And we'll talk more about this
later.
So our devices are very powerful
and so it's important that as
developers we're very careful
about when we use that power.
We need to really think about,
do we need to use this power to
deliver a great experience to
our users.
And if we do, we should go ahead
and use that power.
But maybe there're other times
where we can conserve it.
So now you might be thinking,
what consumes energy.
Well, actually nearly everything
in our devices consume energy
but today I really want to focus
on four main things.
And these are processing,
networking, location, and
finally graphics.
These are the four main things I
really want you to think about
when you're writing your apps.
So how can I reduce my energy
consumption?
First, I want to identify the
work that I need to do, really
think about will this work, help
your user.
And if it won't, don't do it at
all or maybe defer it to a later
time.
Next, you'll want to optimize
your work.
Once you've identified the work
that you do need to do, try to
do it as quickly and efficiently
as possible.
Next, you'll want to coalesce,
try to batch up your
transactions.
Don't do them spaced apart.
And finally, reduce the
frequency of your work.
So let's see how we can apply
these principles to your apps.
And first I want to start with
networking.
So if you're developing an app
that uses networking or you have
an app that does networking,
you'll really want to pay
attention here.
And so I'd like to start with an
example.
I've been working on a social
networking app and this app has
three parts: a main feed, it has
the ability to post a photo, and
finally the ability to send some
analytics data.
And so let's start with the main
feed.
In my current implementation,
I'm just reloading on a fixed
timer over and over again.
And let's take a look at the
energy impact in doing so.
Here you can see that at first
glance doesn't look to be that
energy intensive; however, as we
talked about earlier, they're
actually those overhead costs
and that's the cost to bring up
the radio and put it back to
sleep in this case.
And so even though you're just
doing a small amount of work,
you're paying those overhead
costs and this is really
resulting in a big energy
impact.
So how can we optimize this?
First, we'll want to reload only
on user interaction or maybe a
notification such as an urgent
news alert.
Next, you'll want to use NSURL
Session Default Session and
there's a new property called
Waits for Connectivity.
This will allow you the ability
to know when you can connect to
the server of your choice.
Additionally, you'll want to use
NSURL Session Cache as well.
This will allow you to not
re-download the same pieces of
your main feed over and over
again and incur those extra
costs.
So, let's take a look at the
energy impact with these
optimizations.
As you can see here, we've
removed that recurring spike.
Now you're only reloading on
user interaction and
notification.
And you also removed that
overhead cost as well.
This is great for battery life.
So let's see how we can set this
up.
First, we'll want to go ahead
and create a default session
configuration.
Then, we'll move on and we'll
set the waits connectivity
property to true.
And finally, we'll configure our
cache.
So that was the main feed.
Now let's move on and talk about
how we can post a photo.
So in my current implementation,
right now I'm just going to send
this photo immediately and I'm
going to retry on every failure.
That's because I really want to
get this photo to my server.
And let's take a look at the
energy impact in doing so.
As you can see here, the energy
impact is very high.
We're spending a lot of time to
send up our photo.
And finally it times-out, maybe
because the networking
conditions are poor.
And again, we retry because we
really want to get this photo to
our server.
And again, we spend a lot of
energy while we're not providing
much utility for our user
because this photo is still not
getting to our server.
And this may repeat over and
over again.
So how can we optimize this?
First, we'll want to make sure
we really minimize our retries.
Only retry maybe two or three
times.
Next, set reasonable timeouts,
maybe 30 seconds or a minute.
Don't spend too much time trying
in case you're in those bad
networking conditions.
Finally, you'll want to batch
your transactions, so if you
have other photos to post at the
same time, go ahead and post
those as well.
Finally, if your retry limit is
hit, and you're not sure what to
do, maybe create a background
session.
This will allow you to hand off
your photo upload to the system
and it can find a good time to
do your work.
So let's take a look at the
energy impact with these
optimizations.
As we can see here, now we've
really reduced the amount of
energy that we're spending both
in the cost to send our photo as
well as that overhead cost.
Additionally, you might see that
we're still timing out, maybe
because those bad networking
conditions are still there, but
yet the second time we retry, we
just go ahead and create a
background session and now we're
going to let the system handle
uploading our photo.
So that was how we can post a
photo efficiently.
Now let's talk a little bit
about how we can send up
analytics data.
And as developers, we all really
care about how users are using
our apps.
So we want to make sure that the
data that we're sending does not
have an energy impact and we can
do that by using Background
Session.
This provides the ability to
hand off your upload or download
to the system to do it at a good
time.
Additionally, it provides
automatic retries so you don't
have to worry about handling
that retry policy yourself.
Next, it also provides
throughput monitoring which
means that if your throughput is
very low, for instance you're in
those poor network conditions,
your task will be stopped and
retried at a later time when it
thinks it will succeed.
Finally, there's some new
properties called start time and
workload size.
This will help you indicate to
the system the best time to do
your work.
And finally, you'll also want to
set the discretionary property
whenever you're doing work
that's not immediately relevant
to your user.
This will allow the system to
find the most energy efficient
time to do your work as well.
So let's take a look at an
example.
Here, we can see that right now
I'm not using Background
Session.
I'm just going ahead and sending
my data as soon as I have it
ready to send to my server.
Additionally, there's some other
networking that's occurring in
the future.
And right now we're paying two
overhead costs.
So let's say that we use
Background Session.
Now we can see that Background
Session has allowed these events
to coalesce together and saved
us that extra overhead by
combining it with the other
networking that was already
going to happen at a future
time.
This will really help battery
life for your users.
So let's take a look at how we
can set this up.
First, we'll want to go ahead
and create our Background
Session configuration.
Then, we'll move on and we'll
set the discretionary property
to true.
Next, we'll go ahead and we'll
set some properties like start
time and the expected workload
size.
And finally, we'll resume our
task.
So that was how we can send up
our analytics data in an
efficient way.
Now I want to talk to you a
little bit about watchOS.
So, networking on the watch can
be very expensive and so it's
important that you use
background session for any work
that you want to occur when the
screen is off.
You want to also use this for
complication updates or
background app refresh as well
and that's because you'll be
able to get runtime when the
task completes so it can go off
and doing your networking and
let you know when it's done.
So, to recap.
First, you want to identify the
work that you're doing.
This will help you ensure that
you're not repeating
transactions again and again.
Next, you want to optimize your
work by using Background Session
wherever appropriate.
Next, you want to coalesce your
work.
Really batch those transactions
up to save that overhead.
And finally, reduce your work my
minimizing retries and setting
reasonable timeouts.
So that was networking.
Now I want to talk to you a
little bit about location.
And so as a developer, you have
many APIs to choose from when it
comes to location.
But today I really want to focus
on the energy impact of these
APIs.
So to start off, let's talk
about if I wanted to add the
ability to add navigation to my
app.
To do this, I'll want to use
continuous location updates and
the reason for that is I'll need
to know if the user deviates
from my course.
That way I can provide them new
instructions for how to get to
their destination.
But one thing you want to be
cautioned of is that this does
prevent the device from
sleeping, so it will have a high
energy impact on your users.
So really, as soon as your user
gets to their destination,
you'll want to make sure you
stop these location updates and
make sure the device can sleep
again.
So let's take a look at how we
can do this.
First, we'll create a location
manager.
Then, we'll move on and we'll
set some properties.
And the property I really want
to focus on today is desired
accuracy.
Really think about the accuracy
that you need and the reason for
that is higher accuracy is
higher power.
So really make sure that you do
need that high accuracy if you
go ahead and set it.
And then next, you'll want to go
ahead and start updating
location.
Once you're done, for instance
as soon as the user gets to
their destination, stop updating
location, again so that you can
let the device go back to sleep.
So that was continuous location.
Now let's move on and talk about
some other APIs that will allow
your device to sleep more often.
The first one is request
Location and this allows the
ability to get the user's
current location, maybe if you
want to update content based on
their current location without
having to worry about calling
start location and stop location
and managing calling both of
those.
Next, there is region
monitoring.
Region monitoring provides you
the ability to know, let's say,
if you want to update content
when the user arrives home.
You don't have to track their
location all the time.
You can just create a region and
when they cross that region,
you'll be able to get some
runtime to do your work.
Similarly is visit monitoring.
Visit monitoring allows you to
know when users go to frequently
visited locations.
You'll also get some runtime at
that time as well without having
to continuously track their
location.
You can set that up as follows.
And finally there's significant
location change.
So significant location change
can be used if you want to know
when the user is moving a
significant distance but you
don't want to use continuous
location because continuous
location prevents the device
from sleeping.
Significant location change
doesn't prevent the device from
sleeping.
It can still sleep between those
updates.
And so you can really make a
good optimization if you're able
to move from continuous location
to significant location change.
One example is maybe you have a
weather app.
You need to know when the user
moves significantly and update
the weather at those times.
And here is how you can set that
up.
So to summarize, first you want
to identify the accuracy level
that you need.
Really think about do I need
that high accuracy.
And if you don't, use something
lower.
Next, you'll want to optimize
your work by using alternatives
to continuous location wherever
you can and wherever it makes
sense.
Next, you'll want to reduce your
work by stopping location
updates as soon as you're done
with them.
Again, if you let those location
updates keep coming, you might
prevent the device from
sleeping.
And finally, you'll want to
coalesce your work by deferring
location updates.
Maybe in the future you'll need
that location, you'll really
need it and maybe you don't need
it right now.
So that was location.
Now I want to talk to you about
graphics.
And graphics can be very energy
intensive.
So here are some good guidelines
to follow.
First, you'll want to minimize
your screen updates, really
ensure that these are providing
needed changes for your user.
Next, you'll want to review your
blur usage.
If you're placing blurs on top
of updating elements, this is
very expensive for battery life.
So be very cautious of that.
So those are some general
guidelines.
Now let's talk specifically
about the Mac.
So if you're developing on the
Mac, you'll want to be aware
that some MacBooks have a
discrete GPU and this discrete
GPU is great at delivering
awesome graphics and awesome
performance for your users but
it also has a high power cost
over the integrated GPU.
And so you'll really want to
make sure that you're only using
the discrete GPU when your
animation performance really
suffers over the integrated GPU,
or if the functionality isn't
provided there.
Additionally, if you're
developing on the Mac, you might
be using Metal or OpenGL.
And if you're using Metal,
you'll really want to be aware
that by just calling Create
System Default Device, you're
going to trigger the Discrete
GPU automatically.
And so if you don't need the
discrete GPU, instead you'll
want to call Copy All Devices
and pick that device with the
low power attribute set.
This will ensure that you can
use the integrated GPU whenever
possible.
For those of you that are
developing using OpenGL, you'll
want to make sure that your app
is mux-aware by setting the
Automatic Graphics Switching
property either in your
Info.plist or using the sample
below.
And the reason for this is if
you don't need the discrete GPU,
you don't want to be the one to
keep it up and automatically you
will keep it up unless you set
this property.
So to summarize, first you'll
want to identify the work that
you need to do by looking at
your burry usage.
Make sure you're not placing
those blurs over updating
elements.
Next, you'll want to optimize
your work.
If you're developing on the Mac,
really ensure that you're only
using the discrete GPU whenever
you really need it to deliver
that great performance.
And finally, reduce your work by
minimizing screen updates
whenever possible.
So that was graphics.
Now let's talk a little bit
about processing.
And again, processing can be
very energy intensive as well.
So here are some guidelines to
follow.
First, you'll want to identify
the tasks that you need to do.
Next, you'll want to do that
work very quickly and
efficiently once you've
identified those tasks.
You'll also want to avoid timers
whenever possible.
Try to do your work based on
user interaction rather than a
fixed timer over and over again.
But if you really do need to use
those timers, try to set a
pretty long leeway.
That will let the system
coalesce your timers with other
work.
So that was some general
guidelines for processing.
Today I really want to focus on
background processing.
And background processing can be
very expensive for your users
and so it's important to think
about what you're doing in the
background.
The main reason for this is the
user is not looking at your app.
In the foreground, they're
looking at your app.
So if you're using some energy
there, they might not be as
worried.
But if you're using a lot of
energy in the background, your
users might not be happy about
this.
And so here are some general
guidelines.
First, we'll want to finish our
work as quickly as possible.
First think, do I really need to
do this work in the background.
And if so, find the most
efficient way to do it.
Next, if you want to update your
content, try to use the
background app refresh API.
This will really help you find
the best time to update your
content.
And finally, you'll want to make
sure that you call the
completion handler for whatever
API that you're using.
This will make sure that you
allow the device to sleep as
quickly as possible and you
don't end up paying any fixed
cost.
So new in iOS 11, there's a
completion handler in the
PushKit API.
This will allow the device to go
back to sleep very quickly after
you handle your incoming push if
you call this.
And so you'll really want to
make sure that you adopt this if
you're using PushKit.
And let's take a look at an
example.
Here, we can see I'm not calling
the completion handler in this
case when I receive my incoming
push.
I'm just doing some processing
and then I'm letting the device
just go to sleep after a fixed
period of time.
But now let's take a look at the
energy impact with the
optimization.
By calling the completion
handler, we are allowing the
device to sleep more quickly and
not only have we saved that
energy that we're using in the
background but also that
overhead cost as well.
That will really help the
battery life of your users if
you're using PushKit.
So let's talk a little bit about
background processing on the
Watch.
So new is the background
navigation mode.
This also has CPU limits like
other background modes on the
watch.
Additionally, you'll want to
really make sure that you
minimize any networking that
you're doing when in this
background mode.
Really think about, do I need to
do this or will my user care
about this networking update
that I'm doing.
Maybe do it for things like
traffic reroute or important
traffic information.
And finally, use background app
refresh and complication updates
to update your data.
And when you're using these
APIs, make sure that you use
Background Session, as we talked
about earlier, to get that data
so you don't have to wait around
for the data to come through.
So to summarize, first you'll
want to identify the work that
you're doing in the background.
Really make sure it's providing
useful content for your user.
Next, you'll want to optimize
your work by using Background
App Refresh whenever you can.
Next, reduce your work by
limiting the transactions that
you're doing in the background.
And finally, using background
Session whenever possible.
So now my colleague is going to
come up and talk to you about
the energy tools available to
you as well as give you a demo.
[ Applause ]
>> Thanks, Daniel.
Good morning, everyone.
I am Prajakta Karandikar.
I'm an engineer in the power
team.
So you heard about all the best
practices for writing energy
efficient code.
Now I'm going to talk about the
various energy debugging tools
that we have developed.
We will see how you can use
these tools to measure the
energy efficiency or energy
impact of your applications.
These tools will help you find
the high-level problems within
your application pertaining to
energy or the major problem
areas and will help you fix
these problems.
Finally, we will move on to a
demo where I'll take some sample
applications and debug them for
energy issues using our new
tools so that it establishes a
debugging workflow for you to
debug your own applications.
But first, let us see why it is
important to measure your app's
efficiency.
Say you develop this awesome
application with some great
functionality but did not
measure its energy impact.
Turns out the energy impact of
the application is pretty high
even with usage for a very small
period of time.
Naturally, battery usage UI is
going to flag this application
as one of the top energy
drainers and any customer who is
using your application is going
to experience a significant
battery drain even with
small-usage periods.
It could be possible that the
customer deletes your
application and that is
definitely not something that
you desired.
So as an app developer, it is
really important that you
measure your app's efficiency
pertaining to energy or its
energy impact.
And to help you with this
measurement, we have the new and
improved Energy Gauges.
These are included as a part of
Xcode, which you all are
familiar with.
Energy Gauges are designed to
give you a high-level overview
of the problems within your
application pertaining to
energy.
They will tell you what are the
energy-heavy areas within your
app.
They will also guide you to the
right set of instruments to
drill down deeper within these
problem areas and fix these
problems.
So where can you access Energy
Gauges within Xcode?
When you launch your application
with Xcode, click on the Debug
navigator.
A series of performance gauges
open to the left-hand side of
the screen.
These are for the basic metrics
in the system like CPU, memory,
network, and disk.
In iOS and macOS, one of these
gauges is for energy impact.
When you click on this energy
impact gauge, the energy report
opens to the right-hand side of
the screen.
Let me walk you through the
various parts of this report.
At the top left corner of the
report, you will see a value
which indicates the overall
energy rating or the overall
energy score for your
application.
Alongside it lies a meter which
is three regions: the green,
yellow, and the red region
corresponding to low, high, and
very high energy impact.
So the bad news for this
particular report is that this
application which is being
debugged has a high average
energy impact.
The good news, however, is that
as you make improvements or
optimization to your
application, this meter will
help you know whether you're
moving in the right direction,
that is towards the green or the
low energy impact zone, or are
you moving to the wrong
direction, which is the red or
the very high energy impact
zone.
So if you see that your
application lies anywhere within
the yellow or the high regions,
you definitely want to take a
look at the pie chart which is
at the top right corner of the
report.
So this pie chart tells you what
does the average component
utilization for the primary
components which consume energy
on iOS as were described to you
by Daniel.
Ask yourself, do you expect your
application to be using this
much CPU, GPU, networking,
location.
You can start by eliminating
whatever you did not expect your
application to be using.
Those could be some leaks within
your application which have left
some hardware running
indefinitely and which are
resulting in a greater energy
impact.
For example, say you have
developed a gaming application
which uses only the CPU and GPU
and it requires very little
location that is to access the
location of the user when the
user starts playing a game.
But if you see from the energy
report that the pie chart tells
you that your location
utilization is very high, that
could be a possible leak within
your application where you're
continuously accessing location
and that could be something
which is resulting in excessive
energy drain.
So once you have eliminated
whatever you did not expect your
application to be using, next
you should try to optimize
whatever stands out or is the
biggest portion within the pie
chart.
So for this particular example,
we see that the red region,
which stands for overhead, is
the biggest piece in the pie
chart.
We know that overhead is the
energy that is required to bring
up the radios and all the other
system hardware which is
required for your application to
perform work.
And this seems about right
considering that your
application is also utilizing
the networking component.
Networking is going to bring up
the radios which will require
power for prolonged periods.
So in this case you can try to
optimize your networking
utilization.
Try to batch up all your
networking activity within your
application whenever possible so
that it reduces the impact on
the networking as well as the
corresponding overhead which has
resulted from it.
Once you know which is the
primary component that you want
to try to optimize or improve
first within your application,
you should look into the
segmented bar chart or the
instantaneous section of the
report.
This gets refreshed every
second.
This is great to find whether
what your application is doing
over time makes sense.
So when you execute certain
actions or scenarios while
you're trying to debug your
application using energy gauges,
you can see here what is the
exact point of time when you
consumed energy, which are the
various components on which you
generated a workload.
This region also tells you
whether that workload was
generated while the application
was running in the foreground,
background, or suspended states.
So here you can verify whether
you're adhering to the good
principles of doing as little
work as possible or no work if
possible in the background state
and moving immediately into the
suspected state whenever your
app is backgrounded.
If you do an extended click on
any one of these bar charts, it
will give you a breakdown of the
component utilization for that
instant.
So this section is great to find
what are the opportunities
within your application to
reduce or to coalesce work.
In this particular example, you
see that you're repeatedly doing
networking activity and that's
why time and time again you have
the networking impact as well as
the overhead impact which is
generating from it.
So this is a great example that
you can batch all your
networking work and that is
going to lower the energy impact
for your application.
At the bottom of the report, you
have information regarding the
various components which consume
energy on iOS and some useful
tips regarding how you can
reduce your application's impact
on each one of these components.
To the right of these tips,
there are buttons to click into
instruments.
So say from the energy gauge's
report, you saw the CPU
utilization for your application
is maximum and that is something
that you want to try to
optimize.
So you can click on the Time
Profiler instrument and this
will move your debugging session
into instruments time profiler.
So Time Profiler basically
watches all the running threads
of your process and it generates
samples at regular intervals.
You have a complete back-trace
available for each of these
samples and that can be seen on
the right-hand side in the
Extended View section.
So this helps you find what are
the exact lines of code within
your application which are
extremely time intensive, where
was most time spent within your
application, which functions
within your application were
extremely CPU intensive, and you
can try to optimize that part of
your code and rerun it for
debugging using Energy Gauges.
Similarly, if Energy Gauges
report told you that your
location utilization is
extremely high and that is
something that you want to go
and optimize, you can click on
the Location Profiler.
This tells you what are the
points in code where you have
made access to core location
manager.
You can also see what was the
accuracy that is demanded for
each of these calls and what is
the resulting energy impact from
these calls.
So in this particular case, we
see that the location manager is
being accessed time and time
again with the best accuracy
possible and, hence, there is a
high energy impact that is
resulting from each of these
location calls.
This is also a great place to
find out whether you have left
any leaks in the system.
That is whether all calls to
locations manager have been
successfully released.
You can also try to incorporate
the good practice of using lower
accuracy whenever possible
within your application so that
it lowers the energy impact
resulting from it.
Now that we have familiarized
our self with the various tools
that are available for energy
debugging, let us look at some
of the scenarios that you should
execute on your applications
while debugging them for energy
issues.
So there are some scenarios that
could apply to every
application.
For example, there is the launch
and idle scenario, whether the
user launches your application
but does not interact with it.
Secondly, there is a
backgrounding scenario.
So you should try to run these
scenarios using Energy Gauges
and see what is the resulting
energy impact that is generated
from performing these actions on
your application.
Next, depending on the type of
application that you are
developing, there will be
certain application-specific
scenarios.
For example, if you're
developing a navigation app,
some scenarios that would be
specific to your application
would be looking for a
particular location or address
and then getting the directions
for that address and actually
navigating to that particular
location.
So you should try running these
scenarios on energy gauges for
your applications, see what is
the corresponding energy impact,
then try to make improvements or
optimization when you find the
major problems pertaining to
energy and then rerun these
scenarios to ensure that Energy
Gauges tells you that you're
moving towards the lower energy
impact or the green zone.
So with that, let me move on to
a demo where we'll try to run
these scenarios on some sample
applications so that it
establishes a debugging workflow
for you to debug your own set of
applications.
So the first application that
I'm going to try to debug is
DemoBots.
So let me launch DemoBots on my
device using Xcode.
So this is a simple game that we
have developed.
We expect the game to be
utilizing only the CPU and GPU.
Let me click on the Debug
Navigator and click on the
Energy Impact gauge.
This is the first scenario that
we're executing, which is the
launch and idle scenario.
You want to see what is the
corresponding energy impact from
executing this action on the
application.
So here, we see that the overall
score for our application is
high.
That is it has high average
energy impact.
So next, we want to see what are
the components that we are
trying to utilize.
As expected, we are only
utilizing the CPU and GPU.
There are no unexpected
components being utilized, which
is great.
So next, let us look at which is
the largest part of this pie
chart and what it is that we can
optimize first.
So we see that our GPU component
is being extensively used at
about 88%.
So if you try to bring about any
optimization or improvement
within the GPU in your usage in
your application, that is going
to give you maximum benefits.
Some of the good principles that
you could adhere to here are
reducing the number of screen
updates or reviewing your usage
of blurs or using less opacity
whenever possible.
And this could bring down your
GPU utilization and the
corresponding energy impact
generating from it.
Now let us perform another
scenario which is backgrounding.
Let me try to background this
application.
So we want to see whether it
moves into the backgrounding
state or immediately moves to
the suspended state.
So in this particular case, the
application is immediately moved
to the suspended state, which is
great, because that lets the
device actually sleep.
And you're not incurring any
energy cost on your device.
Let us shift gears and move to
another application.
The second application that we
are going to try to debug here
is EnergyBuddy.
Let me launch EnergyBuddy on my
device using Xcode.
So this is a simple application
which we have developed which
lets you take pictures of energy
meters.
It gets the reading from that
picture for the meter.
It then accesses your core
location and uses your location
to get the weather for that
particular location.
All of this information is later
stored in the database, which
you can retrieve.
So let me click on the Debug
Navigator and go to the Memory
Impact gauge, sorry, the Energy
Impact gauge.
So here, this is our first
scenario that we're executing,
which is the launch and idle.
So our -- From here, we see that
right now our energy impact is
zero, which is great.
The only component that we are
utilizing is CPU that was
required for the launch.
Now let us perform one
application-specific scenario.
Let me try to import a photo and
see what is the corresponding
impact from this particular
action being executed on my
application.
So when I import a photo, I'm
going to accept one of the
photos and allow EnergyBuddy to
access location.
So this generates a graph from
the meter reading that it has
got.
So as we see in the
instantaneous section here, on
executing this particular
action, my application is
utilizing CPU for processing and
it is also utilizing the
location component.
So this was expected because we
wanted as soon as we import this
particular photo, it takes the
location and then uses that
location to get the weather
information.
However, here we can see that it
is continuously accessing core
location and that could be a
leak within my code where I have
left accessing core location
continuously.
So that is something that you
can fix within your application
and then try to rerun this
particular scenario of importing
a photo to ensure that your
energy impact has gone down.
So now let us try backgrounding
this application.
So when I background this
application, we want it to move
into the suspended state as soon
as possible.
However, here we see that the
application has moved to the
background state and it
continues to access location
while in the background state.
So this is not providing any
utility to the user and this can
definitely be optimized within
the application.
We are accessing core location
and that call is not getting
ended and that's why core
location is continuously being
utilized resulting in the very
high utilization for location as
you can see in the pie chart.
You also see a gray portion on
the backgrounding section which
is the static costs associated
with keeping your device awake.
So as long as your devices
continues to be in the
background state because of this
application, there is going to
be certain cost that is going to
be built to your particular
application.
So these are some of the
scenarios that we want you to
run on your applications when
you're trying to debug it for
energy issues, identify what are
the scenarios which are
meaningful to your particular
application, run those scenarios
using Energy Gauges, and see
what does the report tell you
about the energy impact from
executing each one of them.
Make the necessary improvements
or optimization within your
application.
Use instruments to drill down
deeper.
And solve the problems
pertaining to energy.
Rerun these scenarios in your
application after you have
improved your code and verify
that Energy Gauges tells you
that now you have moved towards
the lower energy impact or the
green zone.
With that, I would like to hand
it over to Daniel for the final
thoughts and wrap-up of this
presentation.
[ Applause ]
>> As you guys saw, you'll
definitely want to check out
Energy Gauges.
It'll help you find great energy
improvements to your apps.
So let's wrap it up with some
final thoughts.
First, you'll want to use NSURL
Session Background Session
whenever applicable.
It'll really help the system
find the best time to do your
work.
Next, make sure you minimize
your use of continuous location.
Remember that this will cause
your device to stay awake.
Next, avoid timers.
If you need timers, set leeway
to ensure that they're
coalesced.
And finally, use Energy Gauges.
It'll definitely help you find
great optimizations.
Here're some related sessions.
You'll definitely want to watch
the videos for these.
Thank you very much.
[ Applause ]