Designing a Scalable Android Architecture: Lessons from Top Apps

1. VDisk

VDisk has a simple architecture. The top package is com.sina.VDisk (company domain + app name). Below are modules: main module VDiskClient and entity module entities, then sub‑packages with implementation classes.

First layer: com.sina.VDisk. Second layer: module names (VDiskClient, entities). Third layer: concrete sub‑packages with implementation classes.

Typically, global classes like BaseActivity are placed in the main module. If only one main module, the module layer can be omitted.

Entity module should contain only entity classes. In VDisk most entities are named xxxInfo; the author prefers xxxModel for readability. Public fields are used instead of getters/setters to improve performance, though getters/setters can be used when needed.

2. JiuYi Diary

The structure is slightly more complex. The first layer is the same as VDisk. The second layer does not separate modules; all implementation classes, especially diary‑related Activities, are placed directly.

The entity package is named model and contains not only entity classes (xxx.java) but also higher‑level classes such as xxxManager and xxxFactory, similar to Android’s Activity/ActivityManager pattern.

Additional packages include config (system constants, static variables), constant (public static final values, avoiding enums for performance), and common (shared utilities). These packages are discussed further after comparing multiple apps.

3. NetEase News

NetEase News organizes code by component type rather than by module. The first layer uses a common library named with the company domain. The third layer contains activity and service packages that hold all Activities and Services, often with inner classes or anonymous classes to keep the packages tidy.

This approach is common in Android projects and provides useful reference.

4. Xiaomi Apps

Three Xiaomi apps (Share, Reader, Tag) appear to be developed by different teams. Their architecture includes special modules such as widget and provider. Each app has a common package at both application‑level and project‑level, allowing shared utilities and code.

Whether to further subdivide the common package depends on project size; large projects may benefit from finer granularity, while small projects keep it simple.

5. Consolidated Architecture

Based on the analysis, a generic Android project structure is proposed for a company (e.g., tianxia) developing multiple apps (reader, friend, life). The top‑level contains a base library with common initialization, a common jar for shared code, optional config and oauth packages, and a view package for reusable custom views.

Each app module includes its own config (AppConfig.java), feature modules (blog, bbs, person, widget), and a common package for utilities and custom views. The base library can be an Android library project, while common can be a jar or library.

Additional optional packages such as ad (soft ads), feedback, and upgrade can be added as needed.