Android Framework
常见的架构原则
分离关注点
Activity 和 Fragment 中写所有代码是错误的, 它们只是系统和应用间的粘合类.
通过数据模型驱动界面
应该通过数据模型驱动界面（最好是持久性模型）。数据模型代表应用的数据。
持久性模型是理想之选，原因如下：
- 如果 Android 操作系统销毁应用以释放资源，用户不会丢失数据。
- 当网络连接不稳定或不可用时，应用会继续工作。
单一数据源(SSOT)
在离线优先应用中，应用数据的单一数据源通常是数据库。在其他某些情况下，单一数据源可以是 ViewModel 甚至是界面。
单向数据流(UDF)
在我们的指南中，单一数据源原则常常与单向数据流 (UDF) 模式一起使用。
在 UDF 中，状态仅朝一个方向流动。修改数据的事件朝相反方向流动。
推荐的应用架构
- 界面层 - 在屏幕上显示应用数据。
- 网域层 - 简化和重复使用界面层与数据层之间的交互
- 数据层 - 包含应用的业务逻辑并公开应用数据。
界面层
界面层由以下两部分组成：
- 在屏幕上呈现数据的界面元素。您可以使用 View 或 Jetpack Compose 函数构建这些元素。
- 用于存储数据、向界面提供数据以及处理逻辑的状态容器（如 ViewModel 类）。
数据层
应用的数据层包含业务逻辑。业务逻辑决定应用的价值，它包含决定应用如何创建、存储和更改数据的规则。
数据层由多个代码库组成，其中每个代码库可包含零到多个数据源。您应该为应用中处理的每种不同类型的数据分别创建一个存储库类。
代码库类负责以下任务：
- 向应用的其余部分公开数据。
- 集中处理数据变化。
- 解决多个数据源之间的冲突。
- 对应用其余部分的数据源进行抽象化处理。
- 包含业务逻辑。
网域层
该层中的类通常称为用例或交互方。每个用例都应仅负责单个功能。
例如，如果多个 ViewModel 依赖时区在屏幕上显示适当的消息，则您的应用可能具有 GetTimeZoneUseCase 类。
管理组件之间的依赖关系
- 依赖注入 (DI) 推荐, 使用hilt库
- 服务定位器
常见的最佳做法
- 不要将数据存储在应用组件中.
- 减少对 Android 类的依赖.
- 在应用的各个模块之间设定明确定义的职责界限.
- 尽量少公开每个模块中的代码.
- 专注于应用的独特核心，以使其从其他应用中脱颖而出.
- 考虑如何使应用的每个部分可独立测试.
- 类型负责其并发政策.
- 保留尽可能多的相关数据和最新数据.
架构的优势
在应用中实现良好的架构会为项目和工程团队带来诸多好处：
- 提高整个应用的可维护性、质量和稳健性。
- 允许应用扩缩。尽可能减少代码冲突，使更多人和更多团队可以为同一代码库做贡献。
- 有助于新手上手。架构能使您的项目保持一致性，让团队中的新成员可以快速上手，并在更短时间内提高效率。
- 更易于测试。良好的架构鼓励使用更简单的类型，这些类型通常更易于测试。
- 可以使用明确定义的流程有条理地调查 bug。
Reference
应用架构