Design and Implementation of an Android Chain Framework for Business Decoupling

During rapid business iteration, code from different features often becomes interleaved, making maintenance difficult. This article presents an Android framework called Chain that abstracts call points as extension points, enabling fine‑grained separation of business logic with minimal development overhead.

The design follows classic SOLID principles: the Open‑Closed Principle through extension‑point design, Dependency Inversion by programming to interfaces, and Interface Segregation by splitting functionalities into multiple isolated interfaces.

In a typical scenario with modules A, B, and C that depend on each other, the framework extracts a common interface A_Interface from module A. B and C are divided into an implement layer (business logic, hidden) and an interface layer (public contracts). The mapping between interfaces and implementations is stored in a utility API, ensuring that A only depends on the interface, not on concrete B or C classes.

The Chain framework uses annotations to register implementations. Classes annotated with @Chain are processed by an annotation processor that generates an XChainImpl.class for each AAR module. At build time a custom Gradle plugin merges all generated index classes into ChainJoint.class . At runtime, the singleton ChainBlock reads these indices, allowing callers to obtain a chain by interface and name:

ChainBlock.instance().obtainChain(IProvider.class, "A").log("hello");
ChainBlock.instance().obtainChain(IProvider.class, "BProvider").log("hi");

Additional runtime features include priority‑based invocation, dynamic proxy handling for missing implementations, and a custom URL protocol (e.g., chainblock://iprovider/A/log?text=hello ) for cross‑process calls.

The authors discuss several practical issues: index name collisions, stability when annotated classes are removed, and Gradle broken jar errors caused by unreleased resources. Solutions involve compile‑time conflict detection, proxy‑based null‑safe calls, and proper class‑loader cleanup.

Key advantages of the framework are:

Interface‑driven decoupling.

Low‑intrusion annotation‑only integration.

Automatic component registration.

Support for custom protocols and cross‑process invocation.

Generated documentation and Graphviz visualizations.

ProGuard‑friendly without extra rules.

Best‑practice guidance recommends using Chain when multiple independent business modules need to share extensible capabilities, while avoiding it for simple direct calls or generic utilities that belong in a lower‑level library.

In summary, the Chain framework provides a lightweight, annotation‑driven solution for modularizing Android business logic, reducing coupling, and simplifying large‑scale codebase refactoring.