Shrink you apk size — (5) Reduce size of code
This is the last section of the shrink apk size topic. Usually, the apk size do not comes from the code you write, but the resources you used. However, if you do have some bad habit in writing or you use some library that is not for mobile device, the dex size could be larger than you expect. Let’s get started!
Proguard is a tool that obfuscate and remove unused classes from your code. What it will do is traverse through you code structure and remove isolated code and do some optimize/obfuscate to your code. By setting minifyEnable you can remove unused classes, which would be like the following:
Proguard.cfg contains rules which and what to be left out when remove/obfuscate the code. Note that you may need to modify proguard config according to the 3rd party library you used. You can get default config from:
/tools/proguard/proguard-android.txt. How to setup a proguard.cfg file is not covered in this article.
From official site, A single enum can add about 1.0 to 1.4 KB of size to your app’s
classes.dex file. But after compression the difference should be less than 20kb. Proguard by default remove them and make it constant integer, just that you may need to modify your config to prevent crash.
Proguard do provide a way to remove un-referenced resources if you add
shrinkResources true after the minifyEnable. Just that it do not remove files in value folder. You can have a better solution in previous article.
Redex is an open-source library from facebook that can optimize your dex code. It works as apk-in apk-out tool. To install:
And to apply dex optimization:
Noted that you should not sign directly with the tool from redex, since it use regular compression. You should use Andresguard from last section. And if you apply both of the optimization, Andresguard should be the last that it can do the compression with 7zip.
From my testing, it will reduce 200kb before compression on 8.4mb dex, and total saving will be 80kb on apk size. Well, it’s better than nothing. I did not apply it to released apk hence I am not sure if there will have some complication.
So what’s the magic behind the curtain? From the official blog, the what it do is to remove dead code that can never be reached, inlining function/parameter, and remove some string that can be used only for debugging. It should reduce memory footprint but I didn’t ran benchmark on how much it’s improved.
about the 3rd party libraries
One of the main reason your dex became inflated is that you used library that is not designed for mobile platform. Some even come with resources that never being used. Android platform and it’s library is changing constantly, Sometimes you have library abandoned and still occupied your apk. You should have you 3rd library reviews every few month.
But how? It’s hard to know which to remove without knowing the size it takes. You can add the following script to your gradle:
The config can be different depending on the name of buildTypes and productFlavors. You can get your config by printing all of the configuration you have in gradle:
By running libsize, it will print out the size of each aar and you can either try to remove the library once and for all, or to trim the not used classes.
The trimming we can do no the dex code is quite limited. And the impact on the overall apk size is not much (thanks to the compression). But still, we polish our apk as we can, don’t we? If there’s some other things about trimming the dex we can do here, please leave your comment below.
If you are interest in more about trimming apk size, read more from here: