Design and Implementation of a Modular Mobile Application Framework

Tech Guide

Source: Huajiao Technology, author: Huajiao Android Team.

Background

As company business demands increase, third‑party integrations multiply, and new apps are produced quickly, developers face the dilemma of adding new features without affecting existing logic. A well‑designed basic framework architecture is needed to enable fast reuse, reduce tangled coupling, and lower development and testing costs.

Design

The design analyzes company business, features, and third‑party integrations, then slices and layers the modules. The approach consists of three aspects:

Vertical slicing: encapsulate each business or functional module separately to avoid dependencies outside its responsibility.

Horizontal slicing: layer the architecture by business, feature, and foundational dependency levels, allowing integration from different layers.

Three‑dimensional expansion: facilitate rapid integration and output of new apps.

The framework consists of the following layers:

Business Module Layer : manages interactions between business logic, feature modules, UI components, and data models.

Functional Module Layer : provides a unified encapsulation of third‑party interfaces and protocols, making integration transparent.

UI Component Layer : encapsulates common UI components for reuse.

Basic Support Layer : contains third‑party SDKs and APIs on which the other layers depend.

Implementation

Basic Support Layer

This is the smallest unit of the application, containing all third‑party libraries and API interfaces required by the app.

Functional Module Layer

Analyzes and abstracts similar third‑party libraries into unified interfaces and protocols, reducing coupling and simplifying developer usage. Key points:

Abstract same‑type, same‑function third‑party interfaces.

Design modules focused on a single function.

Make third‑party usage transparent to the consumer.

UI Component Layer

Encapsulates common UI components to promote reuse and reduce redundant view creation, following the Flyweight design pattern. Key points:

Avoid repeated creation and destruction of Views, which increases memory overhead.

Separate lifecycle management from view creation/destruction.

Business Logic Layer

Designed to allow business extensions and reuse without modifying existing code. It encapsulates business logic, views, and data models, distinguishing immutable elements (which are encapsulated) from mutable ones (which are abstracted). Key points:

Modules focus on a single business function.

Identify immutable vs. mutable factors.

Provide simple, clear module interfaces.

Encapsulate immutable parts as much as possible.

Three‑Dimensional Layering

The framework aims for rapid app output, but cannot satisfy every new app requirement. Therefore, extensions are added to the basic framework, UI layer, and business layer as needed. The hierarchy includes:

Basic Architecture Framework: core functional encapsulation and abstraction.

Business App Extension Framework: extensions for unmet business or feature needs.

App Layer: composition and packaging of a new app.

Architecture Layer Dependency Calls

During architecture design, call sequencing is crucial. Key guidelines:

Avoid lower layers calling upper layers.

Avoid same‑level mutual dependencies.

Avoid cross‑layer holding.

Prefer star‑shaped over mesh‑shaped structures.

Architecture Optimization Considerations

Apply design principles such as composition reuse, Open/Closed, Liskov substitution, Dependency Inversion, Single Responsibility, Interface Segregation, and Law of Demeter (use mature design patterns where applicable).

Simplify usage, reduce coupling, and enhance reuse and extensibility.

Encapsulated modules should expose their own input/output models to avoid excessive dependencies.

Distinguish between “is‑a” and “has‑a” relationships to choose composition vs. inheritance.

Avoid blind over‑engineering or unrealistic extensions.