How NetEase Yanxuan Solved Android Componentization Challenges and Boosted Development Efficiency

Background

In early 2021 the NetEase Yanxuan Android team migrated from a monolithic multi‑module project to a multi‑component architecture. The change increased code reuse, reduced coupling, and accelerated new app development, but introduced new maintenance and collaboration challenges.

Issues in component‑based development

Version management : developers often forget to push local changes or tags, leading to outdated component versions and difficulty tracing history.

Quality assurance : existing code‑review, static analysis, and CI mechanisms for the application project cannot be directly applied to isolated component projects.

Semantic versioning : components use MAJOR.MINOR.PATCH but frequently violate compatibility rules, causing unclear guarantees.

Binary compatibility : Android components are distributed as AAR/JAR bytecode. Ignoring binary compatibility leads to hidden runtime errors and large‑scale breakage when a widely used component changes incompatibly.

Development convenience : debugging requires switching between the application project and the component project, making the workflow cumbersome.

YAC – Yanxuan Android Components Management

Standardized development process

Version control : all component changes must be committed and pushed to a remote Git repository. Component releases are tied to Git tags; tag creation automatically triggers version publishing.

Snapshot handling : the main branch always publishes a snapshot version (e.g., 1.2.0‑SNAPSHOT) to an internal Maven snapshot repository, enabling downstream projects to use the latest unreleased changes.

Code admission : a mandatory code‑review process and static analysis (Android Lint, Error Prone, NullAway) are integrated into merge‑request pipelines.

Binary‑compatibility checks : the build runs a binary‑compatibility detector based on japicmp (https://github.com/siom79/japicmp) that compares the current artifact against a baseline version to ensure public APIs remain compatible.

Component Gradle plugin (Yac Gradle Plugin)

apply plugin: 'com.netease.yanxuan.yac'

yac {
    name = '<component name>'     // e.g., 'lib-common'
    version = '<component version>' // e.g., '1.2.0'

    japicmp {
        // Baseline version for binary‑compatibility check, e.g., '1.1.0'
        baselineVersion = '<baseline version>'
    }
}

CI/CD automation

MR pipeline : triggered on merge‑request creation; runs code formatting, static analysis, component compilation (including unit tests), and binary‑compatibility checks.

Main‑branch pipeline : runs on changes to the main branch; performs the same checks and publishes a snapshot to the internal Maven snapshot repository.

Component release pipeline : triggered when a version tag is created; publishes the final artifact to the internal Maven release repository.

Development efficiency tools

Component source debugging tool : replaces an AAR dependency with a local source checkout, allowing developers to edit and debug component code directly within the application project.

Command‑line utility : distributed via Homebrew; the yac CLI provides commands for source debugging, disabling debugging, auto‑configuring GitLab CI/CD rules, and other utilities.

Summary

The YAC system stabilizes component development, improves reuse, reduces coupling, and streamlines releases. Future work includes a visual component‑library management console, a scaffolding tool for rapid app assembly, and extending the approach to business‑level modules, which will introduce new engineering challenges.

References

Semantic Versioning: https://semver.org/lang/zh-CN/

Java Binary Compatibility: https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html

japicmp: https://github.com/siom79/japicmp

Error Prone: https://github.com/google/error-prone

NullAway: https://github.com/uber/NullAway

Gradle Composite Builds: https://docs.gradle.org/current/userguide/composite_builds.html