Next up, we’ll talk about Android app slimming.

1. Apk structure

The figure above is the screenshot I showed when I opened an APK file with Android Studio. From the figure above, we can see that an APK consists of res, lib, dex, assets and other files, among which RES and lib occupy about 70% of the entire APK space.

Lib: Contains compiled code specific to the processor software layer. This directory contains subdirectories for each platform, such as Armeabi, Armeabi-v7A, ARM64-V8A, x86, X86_64, and MIPS. Most of the time we can use just one armeabI-V7A, but most of the major application markets need to support 64-bit, so arm64-V8A will be added as well.

Assets: Contains the application resources that the application can retrieve using the AssetManager object.

Res: contains the uncompiled resource resources.arsc, which mainly contains image resource files.

Meta-inf: contains cert. SF and cert. RSA signature files as well as the manifest.mf MANIFEST file.

Resources.arsc: contains compiled resources. This file contains the XML content in all configurations of the RES /values/ folder. The packaging tool extracts this XML content, compiles it into binary format, and archives the content. This content includes language strings and styles, as well as content paths, such as layout files and images, that are directly contained in the resources.arsc file.

Classes.dex: contains classes compiled in a dex file format that the Dalvik/ART virtual machine understands.

Androidmanifest.xml: Contains the core Android manifest file. This file lists the application name, version, access rights, and referenced library files. This file uses Android’s binary XML format.

As you can see from the structure diagram above, the optimized objects we need to focus on are res, lib, asset, classes.dex, etc.

2. Lib slim down

Lib file thin, we can set up according to the scene suitable support so architecture

Such as:

In the early days, armeabI-V7A was all we needed to support. However, as more and more 64-bit devices become available in recent years, more and more application markets require support for the 64-bit architecture known as ARM64-V8A in terms of performance and experience. Therefore, armeABI-V7A and ARM64-V8A are generally configured.

How do we adapt to our own products?

Mobile architecture APP adaptation armeabi armeabi-v7a arm64-v8a
armeabi can can can
armeabi-v7a Can not be can can
arm64-v8a Can not be Can not be can
  • Armeabi-only apps will run on Armeabi, Armeabi-V7A, and ARM64-V8
  • Only armeabi-V7A can run on Armeabi-V7A and ARM64-V8A
  • Arm64-v8a only can run on arm64-V8A

3. Classes.dex optimization

Our classes.dex file is a compiled bytecode file, so reducing its size is mostly done by reducing the code.

  1. Reduce reliance on tripartite libraries; The tripartite library is quite complete, but we only need to use one of the small function points, at this time we can learn from the tripartite library to achieve our function.

  2. It is not necessary to use three libraries for the same function, such as Glide, Fresco and Picasso. You can combine one library and use it.

  3. Without the andorid support library, of course, everyone is using androidx now.