Evolution of the Android Architecture of the English Fluency App

I. Early Architecture

The initial Android architecture relied on internal broadcasts for decoupling, with core modules A, B, and C emerging as features grew, but increasing business complexity led to tighter coupling and maintenance challenges.

II. Core Architecture

The core adopts a Plugin pattern inspired by leading Android projects, splitting the project into three layers: foundation, functional modules, and the App layer. Foundation modules follow a unidirectional dependency chain from center to monitor , ui , net , sdk , language , and support .

1. Core Architecture Description

Each functional module is decoupled via the plugin mechanism, allowing the App module to drop dependencies without breaking compilation. The central center module defines interfaces, implementations reside in the functional modules, and the App loads them via reflection, providing fallback EmptyAPlugin when a module is absent.

2. Multi‑Process Layer

To isolate memory across JVMs, non‑UI processes expose Package Visible data structures. Process modules are prefixed with lls_process and are distinguished per process.

Reasons for Multi‑Process

Improve UI and overall process stability.

Achieve full component decoupling.

Save memory by keeping only necessary processes alive.

Reduce risk from third‑party components.

Mitigate UI‑process crashes by restarting isolated processes.

Allow large‑memory tasks (e.g., image preview) to run in separate JVMs.

Multi‑Process Communication Architecture

Non‑UI services are wrapped to expose Binder interfaces and communicate with the UI via an UIGuard component. Communication rules include UI‑only access through UIGuard , one‑way service references, and event‑bus based reverse flows. Synchronous calls use a oneway ‑blocked interface that forwards events through UIGuard .

III. Common Auxiliary Architectures

1. Asynchronous Loading Mechanism

Reflection‑based plugin injection incurs ~100 ms latency; an asynchronous loading layer moves this work off the UI thread, reducing perceived startup cost.

2. Flexible EventBus

A lightweight local‑broadcast‑style EventBus decouples senders and receivers for cross‑module communication, used sparingly to preserve maintainability.

3. Monitoring System

Multiple monitors track ANR via /data/anr/traces.txt , crashes via Fabric with native support, activity lifecycle via Application.ActivityLifecycleCallbacks , memory leaks with LeakCanary, and generic business metrics through a selective logging system. A MonitorPool registers components such as image‑load monitoring.

4. Admin System

An admin framework, compiled into the app, provides hidden “green‑channel” features for testers and developers, emphasizing security.

IV. Supporting Architectures

1. File Storage System

LLSPath handles versioned data migration; LLSUserPath extends it with user‑specific paths.

2. Anti‑DNS Hijacking System

HttpDNS is used with lightweight LRU cache, TTL‑based host entries, fallback IP selection, and server‑side latency‑sorted IP lists.

3. Image Loading System

Open‑sourced as lingochamp/QiniuImageLoader , it enforces WEBP by default, performs all transformations on the server, requires explicit size specifications, and offers a simple API.

4. Download System

Open‑sourced as lingochamp/FileDownloader , it provides high concurrency, configurable process placement, simple APIs, and built‑in monitoring.

Overall, the architecture has stabilized but continues to evolve with goals such as unit‑test integration, configurable strategies, and annotation‑processing‑driven code reduction.