Android .so Compression and Remote Loading Optimization Practices

Soul App continuously optimizes core metrics, with APK size being a key focus; reducing the size of native libraries (.so) can improve download experience and app promotion. This article shares practical experience on Android .so management, including compression and remote loading.

so Compression – The process is divided into compile‑time and runtime phases.

Compile‑time flow : Select target .so files that are relatively large and have low load‑time constraints, add them to a whitelist, and run a custom Gradle task after mergeJniLib . The task reads compression configuration, iterates over built .so artifacts, checks the whitelist, compresses selected files with 7z, deletes the original files, and records MD5 information. A custom transform plugin (using ASM or Javassist) replaces System.loadLibrary calls with a custom loader while preserving a blacklist for internal calls.

Runtime flow : When the app starts, it reads the generated .so metadata. The custom loader checks whether a .so is whitelisted; if not, it falls back to the standard System.loadLibrary and logs the event. If whitelisted, it verifies whether the library has been decompressed before and whether its MD5 matches. If the MD5 matches, it loads the library via System.loadPath ; otherwise it re‑decompresses to the system directory, loads it, and records the status.

The compression yields a 25‑30% size reduction, enables remote loading, provides performance statistics, and allows fine‑grained control over load timing. The main drawbacks are an extra decompression step that can affect startup performance and a minor impact on build time.

Remote .so Loading : The approach detaches .so files from the APK, uploads them to a server, and downloads them at an appropriate moment during app execution. Gradle packagingOptions can exclude the native libraries from the APK:

packagingOptions {
    // 64‑bit so
    exclude 'lib/arm64-v8a/xxx.so'
    // 32‑bit so
    exclude 'lib/armeabi-v7a/xxx.so'
}

Loading failures were observed when only the compressed file’s MD5 was verified; the decompressed file lacked verification, leading to occasional runtime crashes. Adding MD5 checks for the final .so resolves this issue.

Remote loading increases CDN bandwidth because the app must fetch .so files at runtime. To balance bandwidth and user experience, a flow‑control scheme pre‑downloads libraries during off‑peak hours (e.g., evening) and limits the proportion of users who download during cold‑start in peak periods. The configuration is expressed as JSON:

[
    {"time": 20, "rate": 50},
    {"time": 21, "rate": 50},
    {"time": 22, "rate": 50},
    {"time": 23, "rate": 50}
]

Monitoring shows that this throttling smooths CDN bandwidth spikes, reducing costs while keeping user experience acceptable.

Conclusion : .so optimization quickly reduces APK size (about 25‑30% savings). Although remote loading introduces additional CDN traffic, proper flow‑control and bandwidth‑peak‑shaving strategies keep the impact within acceptable limits. Numerous other .so optimization techniques exist, and further experiences will be shared.