How We Cut a 117 MB Android App to 74 MB: Proven APK Shrink Strategies

Background

During 2019‑2022 the JD Finance Android app grew to over 117 MB. Large package size harms download conversion, installation time, and device storage. Google Play data shows that reducing APK size by 10 MB can increase conversion by about 1.5%.

Figure 1: JD Finance Android size changes (red area = optimizations that later rebounded).

Figure 2: Google Play conversion increase per 10 MB reduction.

In September 2022 a dedicated slimming effort reduced the app from 117 MB to 74 MB without removing business code, revealing many pitfalls and valuable lessons.

APK Analysis

APK is a ZIP archive. Its main components are:

classes.dex : compiled Java/Kotlin bytecode.

resources.arsc : resource index generated by aapt.

res/ : resource files (except values) referenced in resources.arsc.

lib/ : native .so libraries for each ABI.

assets/ : raw assets accessed via AssetManager, not indexed in resources.arsc.

META-INF/ : signing files (CERT.SF, CERT.RSA, MANIFEST.MF).

AndroidManifest.xml : app metadata, components, permissions, etc.

SDK Size Analysis

Using the internal Pandora energy‑efficiency platform, the SDK size distribution was visualized (Figures 4‑5). Large SDKs were identified for potential modularization or dynamic loading.

Figure 4: SDK size ranking.

Figure 5: SO libraries included in SDKs.

ZIP Structure Analysis

Running

zipinfo -l --t --h test.apk > test.txt

lists each file’s original and compressed sizes (Figure 6). Parsing this log provides a full overview of file counts, total sizes, and per‑type statistics.

Figure 6: APK file size details.

Slimming Practices

1. Regular Technical Solutions

Gradle plugin (non‑intrusive, automated) to shrink the app at compile time.

Pluginization or dynamic SO download for modular business lines, yielding higher savings.

Business‑level optimization: rank features by UV, retire low‑usage modules, or refactor them using approach (2).

Figure 7: Overall implementation path.

1.1 Image Processing

Images dominate size. The pipeline automatically optimizes all images during build (Figure 8).

Figure 8: Image optimization flow.

Techniques:

Multi‑DPI optimization: keep only the most common density (e.g., xxhdpi) for domestic markets; use App Bundle for dynamic DPI delivery overseas.

Convert to WebP (lossy or lossless) for better compression.

PNG compression with

pngquant

for additional loss‑y reduction.

1.2 R‑File Inlining

R class IDs are inlined into bytecode, allowing the R file to be removed. Example before/after:

<code>setContentView(2131427356);</code>

<code>setContentView(R.layout.activity_main);</code>

After inlining, the R file can be deleted safely (Figure 9).

Figure 9: R file generation.

Full inlining workflow (Figure 10):

Figure 10: R file optimization process.

1.3 Resource Obfuscation (AndResGuard)

AndResGuard shortens resource names in

resources.arsc

and the corresponding file paths, reducing size (Figure 11).

Figure 11: resources.arsc mapping.

1.4 7‑zip Compression

Steps:

Extract unsigned APK:

7za x ${apk} -o${outDir}

Compress whole directory:

7za a -tzip -mx9 ${target}.zip ${outDir}

Identify files that must stay stored (no compression) via

aapt l -v ${apk}

.

Re‑add stored files with

-mx0

to keep them uncompressed.

1.5 CPU Architecture Configuration

<code>ndk {</code><code>    abiFilters "arm64-v8a"</code><code>}</code>

1.6 resources.arsc Compression

Compressing

resources.arsc

saves space but harms startup speed and memory usage; from targetSdkVersion ≥ 30 it must remain uncompressed, so this technique is omitted.

1.7 Internationalization

<code>defaultConfig {</code><code>    resConfigs "zh","en"</code><code>}</code>

1.8 shrinkResources & minifyEnabled

<code>buildTypes {</code><code>   release {</code><code>      minifyEnabled true</code><code>      shrinkResources true</code><code>      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'</code><code>   }</code><code>}</code>

2. Advanced Technical Solutions

2.1 Dynamic SO Loading

Two approaches:

Download SO files to a designated directory and load them.

Add the directory to the library search path via environment variables (example code shown).

<code>System.load("{secure_path}/libxxx.so")</code><code>System.load("xxx")</code>

Manipulating the class loader’s native library list (Figure 14) enables runtime replacement or removal of SO libraries.

Figure 14: SO library removal and loading flow.

2.2 Pluginization

Split the monolithic APK into independent sub‑APKs (plugins) that can be loaded dynamically, enabling hot‑fixes and updates. Suitable for business modules that are isolated, have low refactor cost, and occupy large space (e.g., video hall, Figure 15).

Figure 15: Video hall pluginization effect.

3. Business Optimization

Low‑UV features are evaluated for retirement or refactoring (Figure 16).

Figure 16: Business optimization workflow.

Control

A governance process (Figure 17) monitors package changes, compares against historical baselines, and triggers optimization when thresholds are exceeded.

Figure 17: Control workflow.

Results and Future Plans

After two quarters and five releases, the app size was reduced from 117 MB to 74 MB (Figure 18) and remains stable. Ongoing plans include regular size audits, automated monitoring in CI/CD pipelines, and an online governance platform to keep the APK slim.

Figure 18: APK slimming results.

References: Google Play APK size study, ProGuard, R8, AndResGuard, AGP, Pandora.