How a Layered Unity Framework Boosts Code Reuse and Development Speed

Background

Increasing demand for 3D virtualization at AutoHome has led to many Unity‑based product lines. Concurrent legacy and new projects cause divergent code quality, high learning cost, and heavy maintenance.

To mitigate these problems a mobile‑friendly, universal Unity code framework was created to standardize development processes, accelerate onboarding, and enable component reuse across projects.

Unity Architecture Research

The goal of the universal architecture is to apply accumulated experience and best practices to produce high‑quality, robust, and extensible Unity projects while reducing learning and maintenance overhead.

Unity’s ecosystem is relatively limited: few open‑source foundations exist, project types range from heavy MMORPGs to lightweight simulations, and most core functionalities are commercial. Consequently a one‑size‑fits‑all foundation is difficult.

Common Open‑Source Unity Frameworks

UnityGameFramework : Provides a UnityFramework wrapper and a GameFramework with extensions such as ECS and UI. It is heavyweight; even simple UI features pull many dependent modules.

QFramework : Offers a SOLID‑compliant, DDD‑friendly architecture with layered, MVC, CQRS, and modular extensions. It is lighter than UnityGameFramework but provides less source code for deep customization.

Both frameworks are solid but present integration challenges for our specific tech stack.

Design Considerations

Lifecycle : Simple, efficient object creation, modification, and destruction mechanisms.

Layered Design : Decouple code by referencing backend patterns (MVC, DDD, onion architecture) to reduce coupling and refactoring frequency.

Learning Cost : Balance power with ease of use; avoid designs that require deep low‑level knowledge.

Production Validation : Architecture must be proven across multiple projects.

AutoHome Unity Architecture Design

The universal architecture adopts a four‑layer structure: Logic, Middle, Base, and Data.

Logic Layer

Handles project‑specific interaction logic.

Calls services in the Middle and Base layers.

Accesses models and data via the Base and Data layers.

Middle Layer

Encapsulates the Logic and Base layers, providing clearer interfaces and better abstraction. It is split into:

Business Layer : Wraps and processes requests from the Logic layer.

Adapter Layer : Re‑wraps Base layer capabilities, combining multiple utilities for complex features.

Base Layer

Abstracts fundamental functionalities with unified interfaces, supporting all Unity projects.

Typical utilities include TextMeshPro, DoTween, etc., focusing on robustness and extensibility without business concerns.

Data Layer

Manages backend storage, data, and model information; reusable across projects that share the same backend services and art standards.

Special requirements can be handled in the Middle layer following onion‑architecture principles.

Code Example: Native Message Communication

The example demonstrates layer separation and reusability using a native‑message module.

Base Layer – NativeMessage (located in Plugin folder) implements core send/receive functions for iOS and Android.

Middle Layer – XGNativeMessage (located in Scripts/Manager folder) inherits from NativeMessage and adds business‑specific settings.

Logic Layer – Modules or controllers invoke XGNativeMessage to communicate with native platforms.

Overall flow:

Architecture Benefits

Code Quality +20% : Decoupling lower‑level and middle layers reduces bug rates by over 20% per iteration.

Development Efficiency +30% : A unified framework standardizes development, enabling a single team to deliver 30% faster and share core functionalities across projects.

Performance Improvements +20% : Asset upgrades (e.g., GLB → AssetBundle) cut memory usage and CPU load >30%; modular loading reduces startup time by 50%.

Cross‑Project Code Reuse +50% : Reuse rates – Logic 0% (project‑specific), Middle 60% (abstracted and adaptable), Base 100% (generic utilities), Data 100% (shared backend).

Conclusion

The layered design lowers onboarding cost: junior developers can quickly implement business features in the Logic layer, while senior engineers enhance the Middle and Base layers for robustness. Simple state‑machine logic in the Logic layer can be expanded to layered state machines as requirements evolve.

References

UnityGameFramework: https://github.com/EllanJiang/UnityGameFramework

QFramework: https://github.com/liangxiegame/QFramework