PNG files represent the bulk of Android image content,
especially if you've got a lot of UI elements
in your application, rather than photo data.
But PNG files also represent a huge problem
in terms of file size.
They're easy to bloat, and too often, we
don't give them enough attention to make them smaller.
My name is Colt McAnlis, and ensuring
that your app is easy to distribute,
and that images are quick to grab from your server
has everything to do with taking a really hard look at how
you're using PNG files.
Let's take a look at how bad this problem is, in reality.
Take this simple, 16 by 16 pixel red square.
The default exported image from Photoshop
creates a 2.7 k image, where the one that's
been processed with some attention to the file size
only ends up being 121 bytes.
The point here is straightforward--
if you're serving a load of PNG files
to your app that haven't been optimized to this degree,
you're going to be wasting a lot of your users' bandwidth.
See, at its core, PNGs are simple file formats
that apply a lossless compression
algorithm to the pixel data.
The end result is that your image maintains
100% of its original quality, but as a trade off,
means that the image can be bloated in terms of file size.
Other formats, like JPEG, achieve
better compression [? radios ?] than PNG
by applying a lossy compression algorithm to the pixels, which
reduces the number of unique pixels in the image,
before handing it off to the lossless stages.
This first step of reducing image quality helps
make the pixel data more compressible to the lossless
encoder, and also allows you, the content creator,
to make a decision-- do you want better image quality,
or do you want smaller file sizes?
Sadly, PNG's simple file format doesn't
come equipped with the ability to apply a lossy preprocess
to the pixel data.
But this doesn't give you an excuse
to use these bloated PNGs in your apps.
With a little bit of gusto and elbow grease,
you too can easily incorporate a lossy preprocessor
to your PNG pipeline, helping reduce
the bloat in these files.
See, the problem that we're solving here really
isn't a new one.
I mean, cleaning up PNG files to be less bloated
and applying a lossy preprocess is an issue that's
been around awhile.
A simple Google search proves that.
I mean, when you do, you get a plethora
of tools that are already available to help accomplish
these same tasks on your behalf.
Now, most of these tools are command line
driven, so that they fit into your existing build systems,
or they've been ported to languages
that are easy to adapt to your content servers.
In fact, Script PNG will allow you
to run a bunch of different compression codecs
on your image file, and see which
one gives the best compression ratio
for the right visual quality.
Basically, it'll do all the work of finding
the sweet spot between compression and quality
for you.
And in reality, there's lots of situations where you shouldn't
be using PNG files at all.
I mean, if you don't need transparency,
a JPEG file with carefully tuned compression settings
would be much more valuable to you.
Or if you do need transparency, consider
storing the transparent channel in a separate JPEG file, which
you then combine back into the alpha channel of your image
at a load time point in the future.
This will help reduce the overall footprint
of the alpha channel, since it can usually
be compressed much better than the RBG data
by the JPEG algorithm.
Of course, if you want transparency, animation,
and great compression, you could just use the WebP format.
WebP is an open source image format from Google
that supports alpha transparency, lossless,
and lossy compression, as well as animation.
The entire purpose of this image format
is to be a one stop image format shop
for developers of all sizes.
And the good news is that WebP is natively supported
in Android, as of 4.2.1.
Well, technically, a bit earlier than that, but all the good
bells and whistles landed in 4.2.1, which is basically
SDK 17 and higher, accounting for 67%
of the total global market presence of Android,
as of the filming of the episode.
Of course, that'll change in like 10 minutes.
And that's actually a large portion of the market,
so don't be afraid to experiment with WebP
where it makes sense to.
But in truth, WebP and lossy preprocessing steps
will only help you with the size of your image
during distribution.
Once the image is loaded into memory,
they're decompressed into their regular format,
so that they can be used for rendering, meaning
that all the file compression only
helps you with data transfer, not CPU memory residency.
That's a whole separate topic.
But distribution sizes are the smallest
of your worries, which is why you should check out
the rest of the Android Performance Patterns content.
And don't forget to join the G+ community for other great tips
from developers just like you.
So keep calm, profile your code, and always remember--
perf matters.