Best practice to reduce APK size announced in Google I/O 2017 Part 1
As you know Google I/O is an annual developer conference. Google I/O 2017 held in last week and it had a lots of interesting topics. One of these topics announced in second day is “Best practice to slim down your app size”. I personally read some articles about this topic but Google I/O session had more interesting contents.
Dimensions of APK size
We all know why the application size is very important. APK size can be looked at two dimension. First is the download size. It is size of the application in the Play Store and it gets delivered to the device. This size is highly compressed. Second dimension is installed size. So installed size is when you download the app and unpack it. Install size is two to three times bigger than the download size.
Both app size is really important. The large applications waste the user’s time to download and also the user’s device storage.
How to reduce application size
Assume that there is an application with the following chart.
In order that to get this chart you should first build APK and after that press Analyze APK under the build tab in Android Studio to crack it open and see what it’s made of. So after analyze APK you see following page.
Notice that there are two columns with size information. Raw file size and download size.
The Raw file size is how much every particular item contribute to the size of APK as a file on disk. The second is download size which represent how much bytes the user will actually have to download from Play Store on order to install the app for the first time. As you can see for resources these numbers aren’t very far apart because resources are dominated bye large PNG we have for drawables and can’t be further compressed. Whereas for some other items the gains from compression are higher. There is an important point that optimizing your own app size begins with sort of finding out what’s in it and tailoring to that.
Use ProGuard
ProGuard is enabled by default for release builds and it’s a whole program Java optimizer.
The ProGuard does three things. The first thing it does is it optimizes your code in ways that don’t change the functionality but do changes representation to make it more compact. For example it might inline certain methods to their call sites. Another thing it does is it obfuscates names of types and methods and files, so that large names replace with the short strings like “a” and “b”. And the last thing it does is to eliminated dead code and this is the most important role of ProGuard.
Android apps have well known entry point at activities and etc. If this classes are in app manifest the ProGuard marks them as live because this code can execute at runtime. ProGuard then propagates liveness across the program via references and whatever code remains is presumed dead and will be deleted from your app unless you specify ProGuard rules for that.
After using ProGuard you will see that most of the code is now completely gone and the app size is considerably smaller than it was before. You can use compare with button in APK analyzer and see the difference in “classes.dex” size and also you will see the code is obfuscated.
What ever done for code, we can do for resources as well. Resource shrinking extend the concept of ProGuard dead code elimination to resources. To enable resource shrinking add this line to release build types
You can see the application is almost 4x smaller.
Now let’s move to the Part 2 of this article. For Part 2 please follow this link.
Thanks for reading. To help others please click ❤ to recommend this article if you found it helpful.
