Smaller VectorDrawable files

As we’ve seen, VectorDrawables are pretty awesome at reducing the size of your APKs. The ability to use a single file to generate multiple resolutions has a large impact in getting rid of things you just don’t plain need. But that being said, there’s still not as small as they could be.

And while there’s a whole group of topics we can cover here, two of them stand out.

Simplify your paths

The current VD workflow involves creating an SVG in some 3rd party application, and importing it through VectorAssetStudio to convert to the proper format. Truth is, this translation between SVG and VD is where things can get tricky, and if you’re not careful, can end up bloating your resulting VDs significantly.

It all comes down to one thing : PATHS

Path objects tend to be the least common denominator when it comes to supported primitives between SVGs and VDs. And why not? They are super flexible, can represent a ton of shapes, and generally make it easy to more closely represent your intended visual.

But there’s two big issues here.

Firstly, Path data gets really big, really fast. When you’re representing a very complex shape, the only solution you have is to represent it with a large path primitive. Even small fluctuations in a shape can result in lots of new path points being added.

Secondly, as we’ve noted before, Paths on Android are more expensive to rasterize than simple shapes; By default, these are generally always software-rasterized (via SKIA) to a bitmap, and then uploaded to a texture on the GPU. The more complicated the shape, the longer it takes to do this.

As such, simplifying your paths not only reduces the size of your VD files, but also has the side-effect of some small improvement on performance

Actually simplifying your paths though, is an exercise in patience. As awesome as VectorAssetStudio is, there’s not a concept of path optimization that occurs when it’s processing files it’s given. Path data gets passed right from the SVG to the resulting VD. As such, simplification work needs to occur at the authoring stage, inside whatever tool you’re using to create your SVG (good example here) or finding a way to optimize it after export.

Doing that will ensure that the resulting path information gets into your VD in the smallest form possible.

Exploring ShapeDrawables

Probably a more extreme version of this optimization comes from getting rid of paths all together. If you can represent a shape/visual using simple primitive objects, then this can go a long way to reduce your performance burden, and file size. This can be done with ShapeDrawables, which define small shape types that can be used to define objects, rather than defaulting to a path representation.

In some scenarios, this can produce a huge amount of savings to your file… with the downside that you have to do it by hand. Sadly, there’s not a nice tool (that I’ve seen) that allows you WYSIWYG editing for these type of shapes. You end up defaulting to creating them by hand in XML, and seeing how they show up in the preview window of Android Studio.

But if you’re willing to go through that process, ShapeDrawables can give you some nice savings.

HEY!

There’s other stuff to talk about, like how VectorDrawables work. Or how JPG files work, and how to make them smaller. Same thing for how PNG files work, or how to make them smaller. We could also talk about becoming a data compression expert (if you’re in to that), but I’m sure wha you really want is to write faster, smoother Android Applications?