Daojia App General Development Framework: Architecture, Componentization, and Project Practice

Since its founding in 2014, Daojia has built multiple apps (user, merchant, employee) and accumulated extensive mobile development experience, leading to the creation of a unified "Daojia App General Development Framework" primarily described from an Android perspective.

The framework emerged to address the need for reusing common functionalities—such as login, sharing, push, and location—across different apps, adopting a component‑based approach to avoid duplicated implementations.

Componentization faced issues like inconsistent technology stacks (Java vs. Kotlin, different SDK versions), divergent dependency libraries, varied coding standards, and unclear component relationships, which caused tight coupling and maintenance difficulties.

To resolve these, Daojia established a set of basic rules: unify the tech stack to Java 1.8, standardize dependencies (e.g., Retrofit + OkHttp, Glide), align business definitions, and enforce naming and MVP coding conventions.

Components are encapsulated with adaptation layers (e.g., a location wrapper that hides the underlying map SDK), enabling seamless vendor switching and providing Daojia‑specific entities and listeners.

The component hierarchy is divided into four layers: basic functional components, common business components, vertical support components, and the application shell, following the principle that higher layers depend only on lower ones.

Architecturally, the framework follows a layered design with a micro‑kernel, integrating common business components, native modules, and a hybrid Web container, while the bottom layer includes third‑party libraries and system frameworks.

In practice, the framework was applied to the Jiazheng Cloud project, which delivers management and service features for thousands of housekeeping companies. The project’s requirements were analyzed, distinguishing between generic and domain‑specific functionalities, and allocating development between native (Android/iOS) and H5/Flutter based on feature stability, performance needs, and team resources.

To accelerate native development, Flutter was selected as the cross‑platform solution for parts of the app, complementing the existing native modules.

Future plans include advancing Flutter componentization, automating component registration and compliance checks, and providing one‑click generation of the framework shell to further streamline development.