共计 3793 个字符，预计需要花费 10 分钟才能阅读完成。
如何构建高质量并稳如狗的 APP？该指南蕴含了你想要的的最佳实际计划和官网举荐的架构。
注：该指南假设你曾经相熟 Android Framework，如果是老手，请学习课程 Android Basics course，你会学一些该指南中提到的概念和常识。
挪动 APP 的用户体验
一个典型的 Android APP 会用到以下组件：activity, fragment, service, content provider, broadcast receivers，大部分会在 menifest 文件中申明。Android OS 应用该文件把利用和用户交互整合起来。一个设施上有多个 app，一个 app 有多个组件，用户在玩手机，短时间内他会在几个 app 间来回切换，比方在音乐 APP 听歌，老板来电话了，就切换到电话 APP 接听，老板让发一份资料到邮箱，挂断当前就切换到邮件 APP 发邮件，关上文件治理 APP 选了须要的文件，把邮件发送进来后从新切换回音乐 APP 听音乐，这一系列操作背地都暗藏了不同类型的用户驱动的工作流程和工作。试想一下音乐 APP 是你开发的，如何设计来适配这些流程和工作？
挪动设施资源无限，零碎可能会在任何时刻杀掉某些 APP 过程来为新启动的过程腾出空间。
在这种条件下，你的 APP 组件可能是独自并随机无序的启动的，OS 或用户可能随时关掉它。这种随机性事件是你无法控制的，所以不应该在组件中保留利用数据或状态，且组件间不应相互依赖。
常见的架构准则
如果不应该应用组件来保留利用数据和状态，那应该怎么设计 APP 呢？
随着 android 利用的规模不断扩大，对利用就有肯定的要求了，可能不便的扩大，保障稳健性，保障易于测试，这些要求意味着须要一个好的架构。
APP 架构会定义：1. 应用程序中有几个 part, 2.part 的边界，3.part 承当的职责。要满足这些需要，架构要遵循一些特定的准则。
Separation of concerns 关注点拆散准则
SOC
对只与“特定概念、指标”(关注点)相关联的软件组成部分进行“标识、封装和操纵”的能力，即标识、封装和操纵关注点的能力。
这是解决复杂性的一个准则，因为关注点混淆在一起会导致复杂性减少，所以要把不同的关注点拆散开来，别离解决。
益处：
“零碎中的一个局部产生了变动，不会影响其余局部。”
“即便须要扭转，也可能清晰地辨认出那些局部须要扭转。”
“如果须要扩大架构，将影响最小化，曾经能够工作的每个局部都将持续工作。”
常见的谬误是把所有的代码都写在 activity 或者 fragment 中。这些基于 UI 的类应该只蕴含解决 UI 和操作系统交互的逻辑。精简这些类，能防止许多与组件生命周期相干的问题，并进步这些类的可测试性。
Activity 和 Fragment 的实现是 android 零碎负责的，你并没有负责其实现，它们只是一个胶水类，用来粘合你写的 APP 和 Android 零碎，这种粘合性的体现就是 APP 和零碎之间的契约。零碎在某些情况下会杀掉 APP。例如用户交互时被动关掉 APP，或者设施电量有余时零碎杀掉 APP。为了提供令人满意的用户体验和更易于治理的应用程序保护体验，最好尽量减少对它们的依赖。
Drive UI from data models(数据模型驱动 UI)
另一个重要准则是用数据模型驱动 UI, 最好是长久化模型。数据模型决定了展示在 APP 上的数据。数据模型独立于 APP 的 UI 元素和其余组件，这也意味着数据模型和 UI& 组件的生命周期无关。然而当 OS 从内存中删除利用过程的时候，它们依然会隐没。
应用长久化模型会很爽，起因如下：
- 当 Android 零碎杀掉 APP 的时候，用数据不会失落。
- 当网络连接很弱，或者不可用的时候，APP 能够持续运行。
如果 App 架构基于数据模型，App 就会更强壮，更加不便测试。
举荐的利用架构
本节演示如何依照举荐的最佳实际来构建你的利用。
留神：这里的倡议和最佳实际可宽泛的利用于 APP 架构，不便扩大、进步 APP 品质和稳健性，并使之易于测试。然而，这只是一个指南，要依据须要进行调整以适应您的要求。
依据下面提到的架构准则，每个应用程序至多要有两层：
- UI 层：把数据展示在屏幕上
- 数据层：解决业务逻辑；提供数据
能够另外的层，如 domain 层，用来简化和重用 UI 层和 DATA 层之间的交互。
注：图中的箭头示意类之间的依赖。domain layer 依赖 data layer。
UI Layer
该层的职责是展现利用数据到屏幕上。当数据发生变化时，要把这些变动展示在屏幕上。数据变动来自用户交互（如点击按钮）或者内部输出（如 network response）。
UI 层由两局部组成：
- UI elements: 把数据渲染到屏幕上，应用各种 View 或者 Jetpack Compose 来构建 elements.
- State holders: 例如 ViewModel 类，用来持有数据并把数据提供给 UI，并且负责逻辑解决。
于是上图扩大为：
Data Layer
该层蕴含业务逻辑，业务逻辑由一系列规定组成，决定了 APP 如何创立，存储并更改数据，这会赋予 APP 价值。
该层由 repositories 组成，每一个 repository 都蕴含 0 到多个数据源。对每个不同的数据类型都要创立一个 repository 类。例如，对于 movie 相干的数据要创立一个 MoviesRepository 类，对于 payments 相干的数据要创立一个 PaymentsRepository。
Repository 类次要负责下列工作：
- 为利用的其余局部提供数据
- 集中处理数据更新
- 协调多数据源
- 从利用的其余局部冲向数据源
- 解决业务逻辑
每个数据源类只负责解决一个数据源，能够是文件数据源，网络数据源，本地 DB 数据源。数据源类是 application 和 system 之间操作数据的桥梁。
Domain Layer
该层是可选的，位于 UI Layer 和 Data Layer 之间。用于封装简单的业务逻辑或者简略的被多个 ViewModel 复用的简略业务逻辑。因为并不是所有的 APP 都有这些需要，所以它是可选的。在须要的时候才用到，例如解决复杂性和可复用性。
这一层的类通常称为 use cases / interactors. 每个 use case 负责一个繁多的性能。例如有好几个 ViewModel 都要依赖时区信息在屏幕上展现信息，那么就能够设计一个 GetTimeZoneCase 类来专门负责。
解决各组件之间的依赖
APP 中的类须要其余类能力正确的运行。能够应用上面任意一种设计模式来收集相干类的依赖：
- DI: 依赖注入容许类在不结构它们的状况下定义它们的依赖关系。在运行时，由另一个类负责这些依赖项。
- Service Locator: 服务定位器模式为类提供了一个注册表，能够在其中获取类的依赖而不是结构它们。
这些模式容许你不便的扩大代码，因为它们提供了清晰的模式用于治理类之间的依赖，去掉了反复代码，防止掉了复杂性。另外这些模式还有助于在测试和生产环境中疾速切换。
通用的最佳实际
编程是一个创造性的畛域，构建 Android 利用也不例外。对于一个问题能够有很多中解决方案；你可能会在多个 activity 和 fragment 中传递数据；为了离线模式，可能从近程获取数据并将其长久化在本地；或解决其余常见的场景。
尽管上面的倡议不是强制性的，然而在少数状况下，从久远角度来看，遵循这些倡议会使得代码库更加健壮，易于测试和保护。
不要在组件中存储数据
防止将 APP 的 entry point（如 activity，service，broadcast receiver）指定为数据源。相同，entry point 应只和其余组件协调来获取该 entry point 相干的数据子集。组件的生命周期都取决于用户和设施的交互，以及零碎以后的情况，它们的生命周期都很短。
缩小 android 类的依赖
你的利用组件应该是惟一依赖 android framework sdk api 的类，将利用中的其余类从中形象进去有助于进步可测试性，并缩小耦合度。
在应用程序的各个模块之间创立明确定义的职责边界
例如，不要将从网络加载数据的代码扩散到代码库中的多个类或包中。同样，不要在同一个类中定义多个不相干的职责——例如数据缓存和数据绑定。遵循该指南有助于解决此问题。
每个模块不要裸露太多
例如，对与一个模块，不要试图向外裸露外部实现细节。可能在短期内很爽，工夫长了代码就会越来越乱。
关注本人 APP 的外围是指在泛滥 APP 中怀才不遇
不要编写雷同的样板代码来从新创造轮子。相同，将工夫和精力集中在使您的 APP 不同凡响的中央，并让 Jetpack 库和其余举荐的库来解决反复的样板文件。
思考如何使您的应用程序的每个局部都可独自测试
例如，如果有一个从网络获取数据的定义明确的 API，那么久能够更轻松地测试将数据保留在本地数据库中的模块。相同，如果您将这两个模块的逻辑混合在一起，或者将网络代码散布在整个代码库中，那么无效测试会变得更加艰难。
尽可能多地保留相干的最新数据
这样，即便设施处于离线模式，用户也能够应用您的应用程序的性能。请记住，并非所有用户都有继续的高网速——即便他们有，在有的中央网速也不会高。
Samples
上面这些例子是 Google 官网例子，依照该指南进行设计。
- iosched, the Google I/O app
- Sunflower
- Trackr
- Jetnews, (Jetpack Compse)
- Architecture samples