网站做网络营销,ui做的好看的论坛网站,石家庄以岭药业股份有限公司招聘,外贸网站推广收费项目架构指南
本指南包含一些最佳做法和推荐架构#xff0c;有助于构建强大而优质的应用。
注意#xff1a; 本页假定您对 Android 框架有基本的了解。
移动应用用户体验
典型的 Android 应用包含多个应用组件#xff0c;包括 Activity、Fragment、Service、内容提供程序…项目架构指南
本指南包含一些最佳做法和推荐架构有助于构建强大而优质的应用。
注意 本页假定您对 Android 框架有基本的了解。
移动应用用户体验
典型的 Android 应用包含多个应用组件包括 Activity、Fragment、Service、内容提供程序和广播接收器。应用需要适应不同类型的用户驱动型工作流和任务因为用户经常在短时间内与多个应用进行互动。
请注意移动设备的资源也很有限因此操作系统可能随时终止某些应用进程以便为新的进程腾出空间。
鉴于这种环境条件您的应用组件可以不按顺序地单独启动并且操作系统或用户可以随时销毁它们。由于这些事件不受您的控制因此您不应在内存中存储或保留任何应用数据或状态并且应用组件不应相互依赖。
常见的架构原则
如果您不应使用应用组件存储应用数据和状态那么您应该改为如何设计应用呢
随着 Android 应用大小不断增加您定义的架构务必要能允许应用扩缩、提升应用的稳健性并且方便对应用进行测试。
应用架构定义了应用的各个部分之间的界限以及每个部分应承担的职责。为了满足上述需求您应该按照某些特定原则设计应用架构。
分离关注点
分离关注点是遵循的最重要的原则。不要在一个 Activity 或 Fragment 中编写所有代码保持界面相关类精简减少与组件生命周期相关的问题提高可测试性。
请注意您并非拥有 Activity 和 Fragment 的实现它们只是表示 Android 操作系统与应用之间关系的粘合类。操作系统可能会根据用户互动或因内存不足等系统条件随时销毁它们。为了提供令人满意的用户体验和更易于管理的应用维护体验最好尽量减少对它们的依赖。
通过数据模型驱动界面
通过数据模型驱动界面使用持久性模型独立于界面元素和其他组件提高测试性和稳定性。
持久性模型是理想之选原因如下
如果 Android 操作系统销毁应用以释放资源用户不会丢失数据。当网络连接不稳定或不可用时应用会继续工作。
如果您的应用架构以数据模型类为基础您的应用会更便于测试、更稳定可靠。
单一数据源
为应用中的每种不同类型的数据分配单一数据源 (SSOT)集中更改、保护数据更易于跟踪数据变化。
此模式具有多种优势
将对特定类型数据的所有更改集中到一处。保护数据防止其他类型篡改此数据。更易于跟踪对数据的更改。因此也就更容易发现 bug。
在离线优先应用中应用数据的单一数据源通常是数据库。在其他某些情况下单一数据源可以是 ViewModel 甚至是界面。
单向数据流
采用单向数据流 (UDF) 模式确保状态或数据从高层次结构流向低层次结构事件从低层次结构触发保证数据一致性。
在 Android 中状态或数据通常从分区层次结构中较高的分区类型流向较低的分区类型。事件通常在分区层次结构中较低的分区类型触发直到其到达 SSOT 的相应数据类型。例如应用数据通常从数据源流向界面。用户事件例如按钮按下操作从界面流向 SSOT在 SSOT 中应用数据被修改并以不可变类型公开。
此模式可以更好地保证数据一致性不易出错、更易于调试并且具备 SSOT 模式的所有优势。
推荐的应用架构
基于上一部分提到的常见架构原则每个应用应至少有两个层
界面层 - 在屏幕上显示应用数据。 数据层 - 包含应用的业务逻辑并公开应用数据。 您可以额外添加一个名为“网域层”的架构层以简化和重复使用界面层与数据层之间的交互。
现代应用架构
此现代应用架构鼓励采用以下方法及其他一些方法
反应式分层架构。应用的所有层中的单向数据流 (UDF)。包含状态容器的界面层用于管理界面的复杂性。协程和数据流。依赖项注入最佳实践。
界面层
界面层包括界面元素和状态容器用于显示应用数据通过依赖于状态容器获取数据。 界面层由以下两部分组成
在屏幕上呈现数据的界面元素。您可以使用 View 或 Jetpack Compose 函数构建这些元素。用于存储数据、向界面提供数据以及处理逻辑的状态容器如 ViewModel 类。
数据层
应用的数据层包含业务逻辑。业务逻辑决定应用的价值它包含决定应用如何创建、存储和更改数据的规则。
数据层由多个仓库组成其中每个仓库都可以包含零到多个数据源。您应该为应用中处理的每种不同类型的数据分别创建一个存储库类。例如您可以为与电影相关的数据创建一个 MoviesRepository 类或者为与付款相关的数据创建一个 PaymentsRepository 类。 存储库类负责以下任务
向应用的其余部分公开数据。集中处理数据变化。解决多个数据源之间的冲突。对应用其余部分的数据源进行抽象化处理。包含业务逻辑。
每个数据源类应仅负责处理一个数据源数据源可以是文件、网络来源或本地数据库。数据源类是应用与数据操作系统之间的桥梁。
网域层
网域层是可选的用于封装复杂业务逻辑提供依赖给界面层依赖于数据层。
网域层负责封装复杂的业务逻辑或者由多个 ViewModel 重复使用的简单业务逻辑。此层是可选的因为并非所有应用都有这类需求。请仅在需要时使用该层例如处理复杂逻辑或支持可重用性。 此层中的类通常称为“用例”或“交互方”。每个用例都应仅负责单个功能。例如如果多个 ViewModel 依赖时区在屏幕上显示适当的消息则您的应用可能具有 GetTimeZoneUseCase 类。
管理组件之间的依赖关系
应用中的类要依赖其他类才能正常工作。您可以使用以下任一设计模式来收集特定类的依赖项
依赖注入 (DI)依赖注入使类能够定义其依赖项而不构造它们。在运行时另一个类负责提供这些依赖项。服务定位器服务定位器模式提供了一个注册表类可以从中获取其依赖项而不构造它们。
您可以借助这些模式来扩展代码因为它们可提供清晰的依赖项管理模式无需复制代码也不会增添复杂性。 此外您还可以借助这些模式在测试和生产实现之间快速切换。
我们建议在 Android 应用中采用依赖项注入模式并使用 Hilt 库。Hilt 通过遍历依赖项树自动构造对象为依赖项提供编译时保证并为 Android 框架类创建依赖项容器
常见的最佳实践
编程是一个创造性的领域构建 Android 应用也不例外。 无论是在多个 activity 或 fragment 之间传递数据检索远程数据并将其保留在本地以在离线模式下使用还是复杂应用遇到的任何其他常见情况解决问题的方法都会有很多种。
虽然以下建议不是强制性的但在大多数情况下遵循这些建议会使您的代码库更强大、可测试性更高且更易维护 不要将数据存储在应用组件中。请避免将应用的入口点如 activity、Service 和广播接收器指定为数据源。相反您应只将其与其他组件协调以检索与该入口点相关的数据子集。每个应用组件存在的时间都很短暂具体取决于用户与其设备的交互情况以及系统当前的整体运行状况。 减少对 Android 类的依赖。您的应用组件应该是唯一依赖于 Android 框架 SDK API例如 Context 或 Toast的类。将应用中的其他类与这些类分离开来有助于改善可测试性并减少应用中的耦合。 在应用的各个模块之间设定明确定义的职责界限。例如请勿在代码库中将从网络加载数据的代码散布到多个类或软件包中。同样也不要将不相关的职责如数据缓存和数据绑定定义到同一个类中。遵循推荐的应用架构可以帮助您解决此问题。 尽量少公开每个模块中的代码。例如请勿试图创建从模块提供内部实现细节的快捷方式。短期内您可能会省点时间但随着代码库的不断发展您可能会反复陷入技术上的麻烦。 专注于应用的独特核心使其脱颖而出。不要一次又一次地编写相同的样板代码这是在做无用功。 相反您应将时间和精力集中放在能让应用与众不同的方面上并让 Jetpack 库以及建议的其他库处理重复的样板。 考虑如何使应用的每个部分可独立测试。例如如果使用明确定义的 API 从网络获取数据将会更容易测试在本地数据库中保留该数据的模块。如果您将这两个模块的逻辑混放在一处或将网络代码分散在整个代码库中那么即便能够进行有效测试难度也会大很多。 类型负责其并发政策。如果某种类型正在执行长时间运行的阻塞工作则应负责将该计算移至正确的线程。该特定类型知道它正在执行的计算类型及其应在哪个线程中执行。类型应该具有主线程安全性这意味着您可以安全地从主线程调用这些类型而不会阻塞。 保留尽可能多的相关数据和最新数据。这样即使用户的设备处于离线模式他们也可以使用您应用的功能。请记住并非所有用户都能享受到稳定的高速连接 - 即使有时可以使用在比较拥挤的地方网络信号也可能不佳。
架构的优势
良好的架构为项目和工程团队带来多方面的好处
提高整个应用的可维护性、质量和稳健性。允许应用扩缩减少代码冲突增加贡献者。新手上手更容易团队效率提高。更易于测试调查 bug 更有条理。用户体验更稳定工程团队效率提高。
架构需要前期时间投入但会对项目产生积极影响。
