Android APK Analyzer The APK Analyzer is a tool, built-in to Android Studio, that allows you to inspect an APK and see what makes up the contents of an APK file. To use it, you can either drag an APK file into Android Studio and the Analysis will start, or you can just head to the “Build” menu and select “Analyze APK” from the menu. Once you have opened the APK file, you will see detailed information about the APK. The tool contains information such as how big the certain folders are and the percentage of the Download size that the folder takes up.

There are a few common scenarios that seem to have plagued some of the top Android APKs. Let’s discuss three things you should look into implementing in order to reduce the size of your APK file. 3 Most Common Issues in Large APKs: Images The most common issue I have seen whilst analyzing different APK files, the images not optimized. In the one example above 18MB/42MB of the APK is just images. 😱 The average amount of space that images use in these top apps is over 44% of the download size. One app that I examined, had a 3.7MB image that is used for the Splash Screen. Now not only is that image huge, but this image is placed inside all the different drawable folders (of varying sizes), which means the total size of including this one image is 14.9MB. This image is displayed for a few seconds on the launch of the app. This was not the only app with this issue.

Another app that I examined, had included possibly every single image of their different products that they sold inside their app. This took up 80% of the size of their application. 😱 Here are some tips for reducing your image sizes/usages: Don’t package images that aren’t important to every single user of the application. For instance, this app in question above had about 20 different images that related to different products that I’m 100% sure most of the users won’t ever see. Store images on a server — compress them, and download and cache them when they are required. (Also — only download the size that you need. Take a look at something like Cloudinary for image resizing and hosting.)

of the application. For instance, this app in question above had about 20 different images that related to different products that I’m 100% sure most of the users won’t see. Store images on a server — compress them, and download and cache them when they are required. (Also — only download the size that you need. Take a look at something like Cloudinary for image resizing and hosting.) Compress all your images! Please , for the sake of my sanity (and your user’s data), compress that 8MB background image. For instance, use a JPG instead of a PNG, use WEBP instead of JPG if possible. Compress it, a lot!

, for the sake of my sanity (and your user’s data), For instance, use a JPG instead of a PNG, use WEBP instead of JPG if possible. Compress it, a lot! Don’t repeat the image in different folders if it is a large image — look at using either the highest dpi folder or look into -nodpi or -anydpi and place the image only once in that folder (then load the image using an Image Loader like Glide to make sure it can handle the size in the view). Read more about -nodpi and -anydpi here.

Use VectorDrawables (SVGs) instead of PNGs where possible (for all icons etc). VectorDrawables are supported from Android API level 7+. Native Libraries Developers love using libraries — hey so do I! But let us have a quick chat about using libraries. Before deciding to bring a library into your project, you should look into how big the library is and what it needs to include in order to run. A few apps that I looked into have their libs folder, filled with libraries for different flavour devices — for example, they are including all the different device architecture flavours of librealm-jni.so. That’s 5MB of data I’ll never get back.

If you really need to include a native library — then please, please, please make sure you are using APK splits or use NDK filters. This allows you to release multiple different versions of your app to users that have different architecture device (ie x86 or armv7) so that users don’t have to download a whole bunch of libraries they will never need. You can also do APK splits on the different density devices, but maintaining different versions of your app can get quite tricky. (Side note — have you heard of Room from the Android Architecture Components?) Use APK Splits or NDK filters when packaging native libraries with your Android apps Fonts Another common trend I observed is that a lot of developers are including fonts in their assets folder. Did you know that in Android API 26 (Oreo) and Support Library 26, Downloadable Fonts were introduced? This means you no longer need to package a font with your application, and a user will only have to download a font once, and it’ll be reused in different applications. Read more about Downloadable Fonts here. Use Downloadable Fonts instead of packaging fonts inside your APK file Other Notes Test Data — A few apps have files in them that look like test data. Remove those from your final APK file, your users don’t need them. ProGuard — A lot of APKs don’t use ProGuard. Now you might think that you don’t need it because you don’t mind if people read your code, but ProGuard is more than just an obfuscation tool, it also minifies your code and can remove unused classes and files. Go enable it! (*just double and triple check everything works afterwards 😬) Xamarin — How can you tell when an app is written in Xamarin? A lot of .dll files and the libmonosgen-2.0.so files. Did you know, a basic Hello World Xamarin app is 8.2MB? If you are using Xamarin for mobile development, I strongly suggest you think about the effect on the size of your overall app.