[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]