How Alipay Cut App Size by 47M and Pre‑install Package by 127M with Componentization

Alipay tackled exploding bundle sizes, code‑reuse pain, and architectural complexity by redesigning its engineering stack into a standardized, plug‑in component system that reduced the main app by 47 MB, the pre‑install package by 127 MB, and cut baseline‑sync modifications from dozens to single‑digit numbers.

Alipay Experience Technology
Alipay Experience Technology
Alipay Experience Technology
How Alipay Cut App Size by 47M and Pre‑install Package by 127M with Componentization

Background and Challenges

Alipay’s super‑app grew from 136 MB to 211 MB in a year, with over 70 modules needing changes for each baseline sync, and bundles depending on dozens of unknown bundles, creating severe package‑size pressure and architectural complexity.

Key problems were low baseline‑sync efficiency, severe package‑size constraints (OEMs required <80 MB pre‑install), and high engineering complexity due to tangled dependencies.

Architecture Design

Strategy

Treat each component as the unit of reuse.

Build a plug‑in component model with static trimming and dynamic loading support.

Adopt an “app = base + N components” model for rapid product assembly.

Standardize cross‑component communication via ComponentService.

Drive large‑scale reuse through a metadata platform and baseline‑sync system.

Close the governance loop with quality gates and metrics.

Design Principles

Component‑as‑microservice: each component has a single clear responsibility and exposes only a few high‑cohesion interfaces.

Interface‑first service contracts: all services are defined as interfaces extending Component, with versioned compatibility.

Full plug‑in capability: components can be added, removed, or replaced at build‑time or runtime without affecting the core.

Runtime resilience: NoOp implementations guarantee graceful degradation when a component fails to load.

Dependency governance: strict top‑down single‑direction dependencies; internal bundles may depend on API bundles but never the reverse.

Quality control: automated architecture scores, CI gate checks, and continuous monitoring.

Platform consistency: the same component definition works across Android, iOS, HarmonyOS, C++, and KMP.

Strategic reuse: standardized components are instantly reusable across the product matrix.

Component Model

A component consists of one API bundle (exposes contracts) and multiple internal bundles (contain implementation). Interfaces must extend Component, and each service must provide a NoOp fallback. The API bundle never depends on internal bundles, ensuring a clean contract layer.

Layered Architecture

The system follows a five‑layer model: product → container → base_component → framework → lib . Dependencies flow only downward, preventing circular dependencies and enabling independent evolution of lower layers.

Component Framework Capabilities

ComponentService is the core runtime providing component definition, communication, plug‑in handling, multi‑tech‑stack support, and build‑time customization.

Performance‑Optimized Service Creation

To avoid reflection overhead, Alipay parses classes.dex files with com.alipay.com.android.dex.Dex, extracts @Impl annotations, generates ComponentRegistry.java, creates stub JARs for compile‑time placeholders, and uses a Lazy CompileOnly mechanism so that object creation approaches raw new performance.

Dynamic JNI Adaptation

Over 1,000 JNI methods were automatically converted from static to dynamic registration. The pipeline extracts ELF symbols, resolves Java class names, reconstructs JNI signatures, and registers natives at runtime via RegisterNatives, reducing the pre‑install package by >70 MB and the main bundle by ~20 MB.

Multi‑Tech‑Stack Support (KMP)

Three Gradle plugins (KSP processor, Bundle plugin, Portal plugin) collect annotation metadata, generate component‑registry.json, and produce platform‑specific entry points ( @ObjCName for iOS, @CName for HarmonyOS). Runtime initialization uses reflection bridges (e.g., NSClassFromString on iOS) to load component registries across Android, iOS, HarmonyOS, and C++.

Platform‑Level Construction

Dependency Analysis

A tooling suite scans compiled artifacts to extract class‑level upstream/downstream dependencies, reflection usage, JNI bindings, SO imports, and exported Android components, feeding a digital metadata platform.

Metadata Management

The metadata platform stores component hierarchy, service interfaces, and dependency graphs, enabling quick lookup, change history tracking, and governance enforcement.

Quality Gates

Build‑time checks enforce component definition standards, API compliance, and dependency rules; CI integrates these gates to block architectural degradation before integration.

Results and Future Plans

The componentization effort reduced the main app from 206 MB to 159 MB and the pre‑install package from 206 MB to 79 MB. Baseline sync modifications dropped from >70 modules to single‑digit numbers, and code‑reuse efficiency dramatically improved. Future work includes completing remaining core component standardization, enhancing runtime plug‑in smoothness, deepening multi‑stack integration, and extending the platform governance model to other Alibaba Group products.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

software architectureAndroidComponentizationmultiplatform
Alipay Experience Technology
Written by

Alipay Experience Technology

Exploring ultimate user experience and best engineering practices

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.