[MUSIC PLAYING]
Data serialization is an important aspect of every Android application.
But when it comes to performance there's a right and a wrong way to do it.
My name is Colt McCandless. And your choice of serialization provider
and format can have a huge impact on your app's performance.
At its core, serialization is the process of taking some in-memory object
and converting it to a formatted chunk of data
that can be converted back to an in-memory object sometime later.
And serialization is everywhere, from sending packets
between the server and the Android device, sending data between two processes,
storing user preferences to disk, and even simple stuff,
like passing the current song information to the UI to be displayed.
Typically, most Android developers will default to the easiest method
to serialize their data.
Namely, extending their class with the serializable class.
But in terms of performance you actually couldn't find
a worse solution to the problem.
See, built in classes like serializable and object output stream
will work great from a functionality perspective,
but these approaches haves significant memory and encoding overhead,
making them entirely too slow for the job at hand.
For the sake of performance, you're going to want to avoid
all of that chaos, and instead look at things like the GSON library,
which produces much faster serialization and more memory-efficient results.
Although there's a large problem with GSON in that it uses the JSON format,
which is known to produce bloated files. See, text-based formats like JSON and XML
tend to decode slower and produce more verbose results.
The problem at hand is that these formats are human readable.
That means that there's lots of overly verbose syntax
that's added to the file for the ease of readability and use.
In addition, these formats tend to be extremely flexible,
meaning you can make ordering changes or data changes easily.
But again, that comes at the cost of needing extra data in the file
that you may not actually want to send to the user.
By the way, one quick note, Android resource files,
which are XML formatted, don't have any of these problems.
They are compiled at build time into a more compact format
that is more memory efficient and faster to load.
So you don't need to worry about any of those.
So when it comes to serialization, you're going to want a fast codec
that produces the smallest file possible.
And lucky for you, we've got three great options available.
For starters the Google Protobuffs Library gets a lot of recognition
for being a very compact, flexible format for serialization.
Downside though is that the Java implementation of the library
has significant memory and code size overhead
which isn't ideal for mobile development,
which is why the Nano Proto format was made.
Basically, it's Protobuffs but optimized for Android development,
so less memory allocations, a smaller number of method calls
and just less code overhead in general.
But of course, my personal favorite has to be the Flat Buffers library.
This format was built by one of Google's game development focused teams
and is focused on performance. In fact, when it comes to file size,
you can see that Flat Buffers produce smaller files
than their Protobuff brethren.
And when it comes to encode and decode times,
flat buffers have a huge advantage. Their overhead is basically nonexistent.
But the truth is that sometimes, the most performant solution
is to not use serialization at all!
For example, if you're trying to store user preferences,
you shouldn't be storing that as a serialized file.
Instead, try using the SharedPreferences API.
It's basically a fast key value store and perfect for this type of data.
Same goes for passing data between running processes.
Serialization is still the wrong answer here.
Instead, use the parcelable API,
which gives you a slightly serialized format
but with a huge performance boost. And if you've got a lot of structured data
that you plan on serializing, don't!
The overhead of walking those serialized objects,
not to mention the time it takes to load them,
is horrible compared to creating a local database
with a SQL Lite API.
See, everything in performance is about understanding the caveats
and choosing the best options.
And trust me, caveats are everywhere, which is why you should watch
the rest of our Android Performance Patterns videos
And don't forget to join our Google+ community
to ask questions to other folks as well.
So keep calm, profile your code, and always remember...
Perfmatters!