Comprehensive Package Slimming and Governance Practices for JD Android App

Background: In 2019 JD.com performed a major Android app slimming, but rapid business iteration, new frameworks, and insufficient controls caused the APK size to rebound. This article shares the data‑driven analysis, practical slimming actions, and governance mechanisms that reduced the package size by more than 30%.

Package Component Analysis – Using Android Studio’s APK Analyzer and the zipinfo -l --t --h xxxx.apk > xxxx.txt command, the team identified the dominant contributors: native libraries (lib), resources (r), assets, dex files, and resources.arsc. To enable module‑level accountability, a fine‑grained analysis was built that separates total APK data, plugin data, and library data.

Project Structure – JD’s app follows a plugin‑based architecture with many independent modules (plugins and AAR libraries). This modularity allows per‑module size tracking and responsibility assignment.

Dependency Size Impact – By generating a Gradle dependency tree ( ./gradlew :app:dependencies --configuration xxxReleaseRuntimeClasspath > dep.txt ), parsing it into an N‑ary tree, flattening, de‑duplicating, and downloading each AAR/JAR, the team linked each file type (so, images, xml, assets) to its size contribution. Code size was approximated by proportional scaling after removing non‑code assets.

Owner Mapping – Direct dependencies were linked to owners via git blame on build.gradle files; indirect dependencies inherited ownership from their nearest direct parent, enabling a complete responsibility matrix.

Slimming Measures – The following actions were applied: Convert plugins and React Native bundles to on‑demand downloads via JD’s mPaaS platform, achieving >98% download success. Compress images with TinyPNG and convert eligible PNGs to WebP. Replace numerous small icons with an iconfont. Inline R‑file resources using a custom Gradle plugin and ASM bytecode manipulation, saving >5 MB. Enable R8 compilation, reducing APK size by 1.6 MB and build time by 30%. Re‑compress the final APK with 7‑zip, shaving ~2 MB.

Advanced Optimizations – Because built‑in image resources still dominated plugin sizes, a remote‑image strategy was introduced: images are uploaded to CDN, described in a CMS, and loaded at runtime with a three‑layer fallback (zip cache → CDN → placeholder). The CMS also renames images using an MD5 of the CDN path to deduplicate assets.

Governance Framework – To prevent size regression, JD established a component‑level control process. A configuration table records component versions; any size increase beyond defined thresholds (e.g., ≤100 KB per version for small components, ≤x% annual growth for large ones) requires approval from an App Architecture Committee. The workflow integrates with the internal mPaaS publishing platform and Bamboo build system, providing early size‑change alerts via email and supporting exception handling for special cases.

Conclusion – By combining data‑driven analysis, targeted slimming techniques, and a robust governance model, JD’s Android app achieved a sustained reduction in package size while maintaining functionality and user experience, and the approach can be iteratively extended as new technologies emerge.