[MUSIC PLAYING]
CHRIS BANES: We're
here today to talk
about the cost of a pixel,
specifically the colors
that you choose in your
apps and how that directly
affects the battery users
of your user devices.
So before we do that,
we need to think
about the actual technology
that goes into user devices,
and specifically the
display technologies.
Now, there are two
prevailing kinds
of technologies that are in
most devices, LCD and OLED.
The majority devices, especially
on Android these days,
tend to be OLED
devices, OLED screens,
especially from
the mid mid-level
to kind of high level.
And even in sort of
like other platforms,
they're slowly moving
to OLED as well.
LCD stands for
Liquid-Crystal Display.
And they work very
differently to an OLED.
They work with what they
call liquid crystals.
So each pixel is made up of
the number of color channels
of liquid crystals.
The important thing
to know here is
that they require a backlight.
So those liquid crystals
don't illuminate themselves.
It requires a
backlight behind it
to shine through the crystals.
And that's how you see color.
Now, most of the power
for an LCD display
goes into that backlight.
The actual crystals
don't require that much.
It's the backlight.
So more brightness
equals more power.
OLED are different.
OLED displays are
Light-Emitting Diodes,
which as you guess actually
emit light themselves.
So there's no need
for a backlight.
Each pixel illuminates itself.
And that's how the
light shines out.
The good thing here is that
they allow sort of a true black.
So with LCD, the way
you achieve black
is by turning all
the crystals off,
and then the backlight
still shines through.
And so you never really get
that really dark true black.
OLED is completely different in
the way the LEDs work is they
just don't turn the pixel on.
And that's how you get black.
So that's where the power is.
And the power is dominated by
actually emitting the light.
So it's the LED shining
that actually is the power.
There's no backlight.
It's the actual LED itself.
Now, there's a number
of kind of arrangements
that displays can be made in.
So if you think
about a pixel, you
tend to have three
channels, R, G, and B.
And that's the
simplest arrangement.
Each pixel on your display
will have three channels.
And that is true for
both LCD and OLED.
They both can have
different arrangements.
So that's the most
straightforward and mentally
simple, like you have 1, 2, 3.
But there's also more complex
ones, things like RGBR,
where you'll have--
all the channels will be
split across two pixels.
And each pixel will
only have two channels.
It's just a way of
kind of expanding
pixel size without trying
to fit as many LEDs.
Now, it's important
to think about,
because in terms of power, more
LEDs equals more power usage.
So we've done a lot of
stats over the past kind
of year or two, because we
know that users care deeply
about their battery life.
And the display tends
to be the biggest power
user of your device.
So here you can see a very
straightforward chart,
which is the fact that
the higher the brightness
on your display, the
more power it uses.
It's kind of simple anyway.
Everyone assumes
this is the case.
But the thing is it's
actually quite linear.
So again, kind of simple.
But then we started kind
of comparing OLED devices,
OLED screens versus LCD screens.
And in this case, it's the
Pixel versus the iPhone 7.
We're displaying a
screenshot of Maps
in both a normal day
mode and a night mode.
The reason we used
a screenshot is
because we didn't want the
differences between, say, iOS
or Android to
conflict with power.
Displaying a screenshot
is just a flat image.
So they should be pretty
similar on both platforms.
But you can see with the numbers
that the iPhone 7, on the LCD
screen, the actual milliamperage
on both night and day
is the same.
It doesn't change.
And that's because
it's an LCD screen.
And it can't make use
of those dark pixels.
Well, the power users anyway.
But on the pixel itself,
because it's an OLED display,
the actual power usage drops
down by 63%, which is huge.
63% of the biggest power
user on your device
just by using a dark theme.
But even go more
into it, when you've
got actual individual pixel
colors-- so we did a test
where we just displayed
one color on the display.
And the actual color itself
makes a big difference
in power.
So blue itself is 25% more--
takes 25% more power
than, say, green or red.
And then another chart,
which is pretty much
a summary of the previous chart,
but it's a nice line format.
But you can see that black
uses the least amount of power.
You kind of assume that anyway.
And it goes up and up
until we get white.
And because white uses these
channels from every one--
it's full red, full
green, full blue--
it requires the most
amount of power.
And guess which color
we've been pushing you
towards over the
past couple of years?
Material came about
three years ago.
And we changed from Hollow,
which was a nice dark theme,
to this white theme instead.
We kind of shot
ourselves in the foot
slightly in terms of power.
So let's look at
some case studies
of Google Apps over the past
couple of-- well, year or so,
actually.
We have started
implementing dark themes,
and the power savings
they've managed to have.
So the first one is YouTube.
Here we have an example,
which you can't see
the video playing, but it is.
And you can see that
at full brightness,
just by switching
to a dark theme,
you save 43% of
your battery usage.
Now, when you're playing
a video, the rest of it
underneath isn't so
important anyway,
so a dark theme really works.
Now, when it's paused,
we save even more.
It's 60%.
My guess here is that because
the kind overlay of the video
actually darkens
the video, we're
using even more dark colors.
So we save more power.
Now, this test itself depends
very much on the video content.
If you have a video
which is fully white,
then you're not going
to save so much.
And with Gboard, so Gboard is
actually a really good example,
because this is something
users can control.
You now, you can
switch to a dark theme.
And you can save
20% of your battery.
Well, not-- 20% of the
display use of the battery
just by switching
to a dark theme.
So it's actually
quite a big thing.
And finally, our Maps.
This is kind of the canonical
example of dark theme
and where it really
is great, because it
has obvious benefits
of the battery, which
is 31% when it's
on full brightness,
but it's also usable.
You don't want Maps being
like a really white theme when
you're driving at night and
glaring you in your eye.
So a dark theme
here really makes
the app more usable in
a nighttime setting.
And now Alan is going
talk for implementation.
ALAN VIVERETTE: All right.
So how can we
embrace the dark side
and implement dark
mode in our apps?
Go into dark theme, which
will not save us any battery
here, but it will
on your devices.
So you may remember night
mode from the developer
preview of Android last year,
or the year before that,
or the year before that,
or the year before that.
But we released DayNight
support in AppCompat,
which was implemented by Chris.
There's a great blog
article about it.
Our recommended way to
implement dark mode in your app,
and basically get it
for free, depending
on how your themes are
architected, is DayNight.
So if you're using
AppCompat, you
can get this almost for free.
The stock widgets will
respond automatically
to changes in the
device's night mode.
You can also manually toggle
between light and dark modes.
So you can add a switch
in your app to do this.
This is the demo from
the AndroidX checkouts.
If you have AndroidX
checked out from AOSP,
it takes five minutes.
You can run the AppCompat
demo and take a look
at how this is implemented.
It's basically one
line of code to switch
between whatever theme you're
using before and AppCompat.
You simply take
whatever your app theme
is and have it inherit from
one of the AppCompat.DayNight
themes.
And again, depending on how
your app is architected,
everything might just work.
You can also apply an overlay
theme dynamically at runtime.
So if you want to have
a pure black OLED theme,
there are some apps that already
do this, or a pink Hello Kitty
theme, or what have you.
You can apply a theme
dynamically at runtime
by just calling
getTheme.applyStyle,
and applying an overlay theme.
If you want to learn more
about overlay themes,
Chris and I talked about those
at I/O a couple of years ago.
So what that looks like is just
overriding Activity.setTheme.
This ensures that any time a
theme is set on your activity,
you will then
immediately overlay it
with the black theme, or a Hello
Kitty theme, or what have you.
And then any views
that get inflated
will be using that
theme correctly.
Either way you're going to
want to structure your app
to rely on theme attributes.
When I said, depending on
how your app is architected,
this is what I'm referring to.
All of the platform
drawables heavily
rely on theme attributes
to obtain their colors.
So things like color
foreground, color control
normal, color accent,
you've probably seen.
The implementation of the
material track switch,
the thumb--
sorry.
The switch that you can
drag left and right,
the thing that sits
directly under that
is colored light gray
when it's enabled
and dark gray when
it's disabled.
The implementation
of that is just
a color selector, a
color state list that
refers to the color foreground
attribute from the theme, which
is white under a light theme,
black under a dark theme,
and a disabled alpha, which
is also defined by the theme.
So we vary that based on
light and dark themes.
You'll notice there are
no colors hardcoded here.
And in general, you don't
want to hard code colors.
We'll talk about this
more later today in a talk
with Nick Butcher about
themes and styles.
So I mentioned night mode showed
up a couple of releases ago.
The night qualifier has been
in the platform since SDK 8.
It has always been there.
It was opened up for general
use in Android N. So the ability
to set the night
qualifier system-wide.
There are some apps now that
accidentally set the night
qualifier system-wide.
If anybody noticed messages
doing that recently,
it's been fixed.
CHRIS BANES: Tell them, Alan.
ALAN VIVERETTE: So
this is what you'll use
for switching your resources.
It's a resource qualifier
similar to portrait
or landscape.
You just create a drawable-night
or a values-night.
And if you have resources that
are difficult to extract theme
colors out of, say you
have a welcome splash image
that is very
complicated, and you
couldn't put it in
a vector drawable
so your designer
just gave you a PNG.
And you can get a dark
version of that that has
significantly different colors.
And it's too complicated to
put in a vector drawable.
You can just drop an
alternate version of it
in drawable-night.
When the device is
in night mode or when
your app is in the AppCompat
implementation of night mode,
you'll pick up that
drawable automatically.
The same thing for
colors if there are
colors that you want to switch.
Say your accent color is
slightly brighter in a dark
mode, you can extract
that out to a color,
a named color resource,
have one version in colors,
one version in
colors-night-- or sorry--
values-night.
So here's what the theme
implementation can look like.
If you want to switch
your parent theme based
on night qualifier, you simply
defined the theme twice,
once in values, once
in values-nights,
and give it a different parent.
When your theme is referenced
under non-night mode,
you'll pick up the light theme.
When it's referenced
under night mode, when
the night qualifier is on, you
will pick up the dark theme.
The same thing goes for colors.
So here we just
have the same color
defined two different ways.
Anytime that you
reference hardcoded_fg,
it will pick up black
under non-night mode.
It would pick up
white in night mode.
So what can you do
to update your app,
maybe do a little
bit of restructuring,
and make it work really
well for night mode?
Well, you can start
really simple.
Just take a screenshot
of your app,
invert it, see how it looks.
Get a sense of whether
there are images
that you'll need to have
an alternate version of.
Here we see a bunch of avatars.
Those, we probably want
to keep the exact same.
Maybe we want to change the
background colors a little bit.
So that may mean extracting
theme attributes.
That may mean creating
some alternate values
if they're vector
drawables, or that
may mean getting
different sets of PNGs
to drop into drawables-night.
Next, you want to take a
survey of the usage of colors
in your layout XML
and in your styles.
So go ahead and set the
parents of your theme, whatever
your app or activity theme
is, to be something dark,
Theme.AppCompat
or Theme.Material,
and see how it works.
You'll want to look for
issues with losing contrast
between foreground
and background,
not seeing dark colors where
you expect to see dark colors.
And in general, what you
see should look a little bit
like that inverted screenshot.
You'll notice here
it looks nothing
like the inverted screenshot,
because all of the background
colors and foreground
colors were
hard-coded to be light theme.
The one thing that
wasn't hard-coded--
you can almost see it here-- is
the label for first name, which
is now invisible, because it's
the only thing that's correctly
pulling in the dark
theme color attributes.
So this is going to
require a lot of work.
The hard part is
doing that work.
So you'll want to refactor your
colors as much as possible.
Take any hard-coded colors
in your layout XMLs,
move those out to
named color resources.
You can split those based
on values, values-night.
If you want to do more
than one type of theme--
maybe you have a Hello Kitty
theme you want to apply
dynamically--
you'll want to extract those
to color attributes that
have some sort of meaning
in your application.
So as I mentioned before, we
have text color primary that's
built into the platform theme.
We have color accent.
We have color primary.
So you should be using
those as much as possible,
and certainly take advantage
of theme attributes
for specifying colors,
propagating those
into your drawables, into color
state lists, into your layouts.
You can convert colored PNGs
to alpha masks and use tinting.
If you look at--
we don't have a slide for that.
So you can wrap those with a
bitmap element and set an alpha
and set a tint
with android:tint.
We'll talk again
a little bit more
about this at the Themes
and Styles talk later today.
Next, you actually move over to
the AppCompat DayNight theme,
and you get automatic
switching when
the device is in night mode.
You can also consider
adding a preference.
So here we have the Twitter app.
I don't use Twitter so much.
The Twitter app, which has
a very obvious affordance
for switching between
day and night.
So if you tap this, it
goes into dark mode.
And it's really
convenient for your users.
You'll also want to keep
in mind that there is
a platform specified dark mode.
So you may end up
with a tri-state that
says inherit from the
platform dark mode
or I can specify always
dark or always light.
You'll also want to test
that your application works
when night mode changes.
So you can toggle
this manually using
ADB from the command line.
So open up your app once you've
implemented the DayNight theme.
Toggle it into NightYes.
Your application should
preserve whatever state you had
and be recreated.
It's going to go through a
full onDestroy and recreation,
and be recreated in dark
theme, preserving user data.
On Pixel 3 devices
running P, night mode
will automatically switch when
the device enters battery saver
mode.
So that's another way
that you can test this.
You can also toggle it directly
from Developer Options,
and push night to mode to
be always on, always off.
Or one of the legacy
things that we support
is switching based
on time of day.
You can also learn more, as
I've mentioned many times,
in the Themes and Styles
talk that I'll be giving
with Nick Butcher later today.
If you want to learn more
about the lower level
things in themes and
styles, Chris and I
gave a great talk a couple of
years ago at Google I/O. So
that covers everything
you want to know,
but have been afraid to ask
about themes and styles.
If there are things
you're not afraid to ask,
we will be outside in
the Android lounge--
that way-- to answer
any of your questions.
So thanks everybody for coming.
Please embrace the dark side.
[MUSIC PLAYING]
