Android app size reduced from 18MB to 12.5MB

Opening words

A while ago, my boss gave me a task, which was to help us reduce the size of the Android installation package of the live broadcast application we developed. It took me about a week to reduce the installation package from 18MB to 12.5MB. It could have been optimized to less than 10MB, but due to other reasons, it is currently only 12.5MB. Here I record the optimization ideas and tools used for my own review in the future, and for reference by friends in need.

Purpose of weight loss

From the perspective of purpose orientation, we will not do something for no reason. So what is the purpose of our application slimming? The answer is: to improve the download conversion rate. What is the download conversion rate? For example: your application size is 18MB, and there are 100 potential users who want to download and try it. As a result, 20 users dislike the installation package is too large and leave directly. 20 users cancel the download while waiting for the download. In the end, only 60 users actually download and install. Then the download conversion rate of the application is 60/100 = 60%.

The simple summary is: the smaller the installation package, the shorter the waiting time for users to download, the better the experience for devices with small mobile storage configurations, and the higher the download conversion rate of the application. I remember hearing a WeChat expert say in Tencent Lecture Hall that the first version of WeChat was only about 400KB, and I was instantly in awe.

Installation package composition

To slim down the installation package, you first need to understand the composition structure of the installation package. Here is a brief summary of the components and their functions:

Among them, the installation package accounts for a large proportion of: dex files, res folders, assets folders, lib folders and resource.arsc files. Therefore, the next slimming optimization is to make these files smaller to achieve the purpose of slimming.

Starting from Android Studio 2.2.3, the function of browsing APK structure has been added. We can directly drag the installation package into the IDE and browse its composition and corresponding size directly, so that we can easily compare and analyze the results of each optimization step.

Resource reduction

After understanding the composition of APK, we can start to optimize it. Because resource files account for the largest proportion in APK, we should start with resource slimming.

Try to save only one image resource

There will be a drawable or mipmap directory under the development directory to adapt to different dpi screens. The following is the dpi range adapted by different named directories

Currently, most of the models on the market are within the adaptation range of xxhdpi, so you can consider only retaining one image resource under the xxhdpi directory. The specific resources under which directory and how many resources to retain should be determined according to the actual model distribution of the application itself.

Use Drawable XML, Color, .9 PNG instead of PNG

• In some cases, we can consider using Drawable XML instead of PNG, such as gradient background images, which can be drawn with a few lines of XML, so why use PNG files of dozens to hundreds of KB?
• Use Color instead of PNG, such as solid color background;
• From the performance point of view, compared with using image resources, which requires first generating a Bitmap and then passing it to the underlying GPU for rendering, using Drawable XML and Color is more efficient. It directly passes the Shape information to the underlying GPU for rendering, which takes up less CPU and memory.
• Use .9 PNG instead of PNG. There are many scenarios, so I won’t give examples.

Use JPG instead of PNG

Use JPG instead of PNG. Since JPG does not have an alpha channel, the file size is smaller and it can be considered for images that do not require transparency.

Be careful when using WebP instead of PNG

Since WebP has good effects and WebP files are much smaller than PNG files under the same effects, many people on the Internet say that WebP should be used instead of PNG. I disagree with this. The reasons are as follows:

• WebP only supports 4.0 on Android. To be compatible with environments below 4.0, you need to introduce additional compatibility libraries, which will increase the size of the installation package.
• Android Studio does not support previewing WebP images, and layout files that reference WebP cannot be previewed;
• After decompressing the apps of BAT and similar competitors, I found that there are basically no apps using WebP in resource files.

Lossy audio files instead of lossless audio files

From the following official document

https://developer.android.com/guide/topics/media/media-formats.html

You can see the audio and video formats supported by the Android platform. The following are commonly used lossy and lossless formats (don't think that lossy encoding means poor sound quality):

• Lossless formats: WAV, PCM, ALS, ALAC, TAK, FLAC, APE, WavPack (WV)
• Lossy formats: MP3, AAC, WMA, Ogg Vorbis

In actual development, if you need to use audio files, try to use lossy formats such as MP3 and Ogg, and try not to use lossless audio such as WAV and PCM.

Remove unused resources

The removal of useless resource files here is mainly divided into two parts: not packaging unused resources and deleting unused resources.

• To not package unused resources, configure shrinkResources true in the project's build.gradle.

• Delete unused resources. Right click on the project in Android Studio => Analyze => Run Inspection by Name => Enter Unused Resuroces

You can see all unused resource files. It is recommended to clean up these useless files regularly. On the one hand, it can reduce the size of the project. On the other hand, too many resource files will cause the resources.arsc file to become larger and larger after packaging. The company has a project whose resources.arsc file has reached 2-3 MB, which is a bit surprising.

Combining the above points, we can effectively reduce the size of the res folder, assets folder, and resource.arsc file in our installation package, thereby achieving the purpose of weight loss.

tool

The previous chapter mentioned the optimization ideas. This chapter organizes the tools used in the optimization process.

• TinyPNG: https://tinypng.com/, supports compression of PNG/JPEG files with good results.
• pngquant: https://pngquant.org/, supports PNG compression. Sometimes images processed by TinyPNG will have more noise, so you can consider using pngquant to process them.
• ImageOptim: https://imageoptim.com/mac, supports compression of PNG/JPEG/GIF, and the effect is remarkable. You can check it out here https://www.diycode.cc/topics/496. Unfortunately, it only supports Mac, so Windows users are very sad.
• mozjpeg: https://imageoptim.com/mozjpeg, used for PNG to JPEG conversion and JPEG compression, with good results.
• Adobe Audition CC: http://www.adobe.com/cn/products/audition.html, produced by Adobe, supports changing the audio sampling rate, resolution and number of channels to achieve the purpose of cropping the audio (sampling rate, resolution and number of channels are key parameters of the audio file format and determine the size of the audio file).

The above are the tools I used in the optimization process that I think are good. If you have better recommendations, please feel free to add them.

In addition, when compressing images, do not compress all the images in the resource directory at once just for the sake of convenience. Many times, the person who worked on this project before may have compressed some resource files, which can easily lead to secondary compression and cause some image distortion. Here I suggest that you go to the resource directory of the application and sort the resource files from large to small, set a standard, such as if you want to compress images over 20KB, then copy these qualified images for compression, and replace the corresponding image resources before optimization after processing to ensure that there is no distortion. The same applies to audio files.

Native library slimming

Native library slimming mainly reduces the support for CPU architecture. The configuration is very simple. Use abiFilters in build.gradle to configure the required CPU architecture and remove the unnecessary compatible so files from the project.

According to the distribution of our users' models, we only retain support for armeabi-v7a. Note that this needs to be decided based on the actual situation of our own products. Since I was not very familiar with the CPU architecture distribution before, I would like to thank Zhang Shaowen from WeChat, Xu Yisheng from Hujiang, and Zheng Xiaobin from Huya for some popular science.

In summary, we can effectively reduce the size of the lib folder in our installation package, thereby achieving the purpose of weight loss. Another approach is to generate a separate installation package for each CPU architecture by configuring include in build.gradle. Although it looks good, many domestic application markets do not support this approach of configuring a package for each CPU when listing. Therefore, this approach is relatively useless and is not recommended. If the application is only on Google Play, it is indeed much better than configuring abiFilters.

Code Slimming

There are many things you can do here, mainly as follows:

• Remove the code of obsolete functions. Since we have VCS, we can always recover the deleted code;
• Remove duplicate code, such as: there is already a functional code, but the team members don’t know that they have written another set, and can only rely on code review to solve it;
• Remove frameworks with overlapping functions. For example, if there are several network access frameworks in the project, such as Volley, AsyncHttpClient, and Retrofit, the same can only be solved by code review.
• Remove useless dependencies or jar packages;
• Reduce the dependency on the Support-compatible package. The Support-V4 package is very large. The introduction of the project will undoubtedly increase the size of the dex file. Google has realized this problem, so Support-V7 was split from the beginning, and Support-V4 was split. Although the results are not obvious yet, it is still worth looking forward to, especially when you find that after you lose the Support-V4 package, you may change from 2 dex to 1 dex;
• Pluginization is a manifestation of lazy loading. It allows users to install the host package first, and then make some functional modules plug-in-based, and then download and install them at a specific time.

To sum up, we can effectively reduce the size of the dex file in our installation package, thereby achieving the purpose of weight loss.

Conclusion

During the whole optimization process, I optimized the project from 18 MB to 12.5 MB. Some of the above optimization points are affected by other reasons and can only be temporarily abandoned. You can consider including them in the next optimization schedule. These are the routines. When practicing, please make decisions based on your own projects and give priority to optimizing the parts with higher cost performance (cost performance = size that can be optimized/time required).