初识 Jetpack

Android 应用程序架构设计

一个应用程序通常至少有一个 Activity,当我们开发一个 Android 应用时,通常会将大部分的代码都写在 Activity/Fragment 中。这些代码包括UI控件、业务逻辑、数据库操作、网络请求操作、处理请求结果的操作等,随着时间推移和业务的增加,Activity/Fragment 中的代码会得越来越复杂和难以维护。
除此之外,我们还需要考虑用户的体验问题。例如:我们会从当前应用触发其他 intent(打开相机,文件管理),启动其他应用,或者用户随时会被电话或者通知打断,然而移动设备的资源非常有限,操作系统可能会随时终止某些应用进程,来为新的进程腾出空间。鉴于这些情况:应用组件可以不按顺序的单独启动,而且操作系统或用户可以随时销毁它们,因为这些事件不受我们的控制,所以不应该在应用组件中存储任何应用数据或状态,并且应用组件不应该互相依赖(包括Activity、Fragment、Service、ContentProvider、Broadcasts)。

常见的架构原则

为了应对上面这些问题,工程师们在应用程序中引入了“架构”的概念;即在不影响应用程序各模块组件间通信的同时,还能保持模块的相对独立;既有利于后期维护,也有利于代码测试。
Google 官方建议在架构 APP 时应当遵循以下两个原则:

分离关注点

一个常见的错误是在一个 Activity 或 Fragment 中编写所有代码。这些基于页面的类应该仅包含处理页面和操作系统交互的逻辑。您应使这些类尽可能保持精简,这样可以避免许多与生命周期相关的问题(像 MVC 或 MVP 这样的架构设计模式,都属于分离关注点这一做法的实践)。

通过模型驱动页面(最好是持久性模型)

模型 Model 是负责处理应用数据的组件。它们独立于应用的 View 对象和应用组件,因此不受应用的生命周期以及相关关注点的影响。
持久性是理想之选,原因如下:

  1. 如果 Android 操作系统销毁应用以释放资源,用户不会丢失数据。
  2. 当网络连接不稳定或不可用时,应用会继续工作。

在 Andorid 应用中,一直以来都有用到 MVC,将 Activity/Fragment 与布局文件分开就是一种基本的 MVC 思想,不过它并没有很好的解决我们的问题,所以也出现了 MVP 和 MVVM。

总的来说由于 Google 官方一直没有推出一套关于架构的组件和指南,所以 Android 的应用架构始终处于一个混乱的状态,Android 工程师们不仅不确定自己的架构是否是最佳方案,同时学习成本也很高,还可能导致最终开发的应用程序质量参差不齐。

Android Architecture Components

长久以来,Google 一直希望能帮助开发们集中精力专注在真正需要考虑的逻辑中去。终于在 2017 年的 I/O 大会,Google 推出了 Android Architecture Components (简称AAC)来帮助 Android 开发者构建更好应用架构。AAC 主要包含了 LiveData、ViewModel、Room等专门为架构所设计的组件。
AAC 组件的依赖是以 android.arch 命名空间开头:

android.arch.lifecycle:livedata:1.1.0
android.arch.lifecycle:viewmodel:1.1.0

Jetpack

到了 2018 年,Google 在 AAC 的基础上推出了 Jetpack,按照官方的说法,“Jetpack 是一套库、工具和指南,可帮助开发者更轻松地编写优质应用。这些组件可帮助您遵循最佳做法、让您摆脱编写样板代码的工作并简化复杂任务,以便您将精力集中放在所需的代码上。”

特点(优点)

  • 加速开发:组件可以单独采用(不过这些组件是为协同工作而构建的),同时利用 Kotlin 语言功能帮助您提高工作效率。
  • 消除样板代码:Android Jetpack 可管理繁琐的 Activity(如后台任务、导航和生命周期管理),以便您可以专注于如何让自己的应用出类拔萃。
  • 构建高质量的强大应用:Android Jetpack 组件围绕现代化设计实践构建而成,具有向后兼容性,可以减少崩溃和内存泄漏。

组成

Jetpack 主要包括 4 个方面:

Jetpack 与 AndroidX

在 2018 年的 I/O 大会上 Google 还宣布了把 Support Library 重构至 AndoridX 命名空间的计划。
并且在 Support Library 28 版本时完成了重构,发布了 AndroidX 1.0。同时宣布 Android Support Library 在版本 28 之后就不再更新了,未来的更新都会在 AndroidX 中进行。不仅如此,AAC(Android Architecture Components)中的组件也被并入了以 “AndroidX” 开头的包名。

为什么要迁移至 AndroidX ,官方给出了这样的答复:

您可能会想: 既然 AndroidX 只是 Support Library 28 的重构,那为什么要迁移呢? 关于这个问题,我们有下面几个理由:

  1. Support Library 已经完成了它的历史使命,28 将会是它的最后发布版。我们接下来将不会继续在 Support Library 中修复 bug 或发布新功能;
  2. 更好的包管理: 独立版本、独立命名以及更高频率的更新。以上优点,AndroidX 开箱既得;
  3. 目前已经有许多我们耳熟能详的工具库已经迁移至 AndroidX,例如 Google Play 服务、Firebase、Bufferknife、Mockito 2、SQL Delight,我们后面会提到如何迁移它们的依赖;
  4. 我们正在努力推广 AndroidX 命名空间,未来所有新推出的组件库,例如 Jetpack Compose 和 CameraX,都将成为 AndroidX 的一员。

迁移至 AndoridX 的具体操作可以参考这里:是时候迁移至 AndroidX 了

总结

本文先对 Android 的架构中存在问题进行分析,介绍了 Jetpack 产生的历史背景,并介绍了它与 AndroidX 之间的关系,在之后的文章中,将对 Jetpack 中的各个组件进行学习。

参考
应用架构指南
《Android Jetpack应用指南》
分离关注点(中文维基百科)
是时候迁移至 AndroidX 了
面向对象的三大特性,五大原则

posted @ 2020-08-15 17:03  Helldorado  阅读(886)  评论(0编辑  收藏  举报