初识 Jetpack
Android 应用程序架构设计
一个应用程序通常至少有一个 Activity，当我们开发一个 Android 应用时，通常会将大部分的代码都写在 Activity/Fragment 中。这些代码包括UI控件、业务逻辑、数据库操作、网络请求操作、处理请求结果的操作等，随着时间推移和业务的增加，Activity/Fragment 中的代码会得越来越复杂和难以维护。
除此之外，我们还需要考虑用户的体验问题。例如：我们会从当前应用触发其他 intent（打开相机，文件管理），启动其他应用，或者用户随时会被电话或者通知打断，然而移动设备的资源非常有限，操作系统可能会随时终止某些应用进程，来为新的进程腾出空间。鉴于这些情况：应用组件可以不按顺序的单独启动，而且操作系统或用户可以随时销毁它们，因为这些事件不受我们的控制，所以不应该在应用组件中存储任何应用数据或状态，并且应用组件不应该互相依赖（包括Activity、Fragment、Service、ContentProvider、Broadcasts）。
常见的架构原则
为了应对上面这些问题，工程师们在应用程序中引入了“架构”的概念；即在不影响应用程序各模块组件间通信的同时，还能保持模块的相对独立；既有利于后期维护，也有利于代码测试。
Google 官方建议在架构 APP 时应当遵循以下两个原则：
分离关注点
一个常见的错误是在一个 Activity 或 Fragment 中编写所有代码。这些基于页面的类应该仅包含处理页面和操作系统交互的逻辑。您应使这些类尽可能保持精简，这样可以避免许多与生命周期相关的问题（像 MVC 或 MVP 这样的架构设计模式，都属于分离关注点这一做法的实践）。
通过模型驱动页面（最好是持久性模型）
模型 Model 是负责处理应用数据的组件。它们独立于应用的 View 对象和应用组件，因此不受应用的生命周期以及相关关注点的影响。
持久性是理想之选，原因如下：
- 如果 Android 操作系统销毁应用以释放资源，用户不会丢失数据。
- 当网络连接不稳定或不可用时，应用会继续工作。
在 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 的重构，那为什么要迁移呢? 关于这个问题，我们有下面几个理由:
- Support Library 已经完成了它的历史使命，28 将会是它的最后发布版。我们接下来将不会继续在 Support Library 中修复 bug 或发布新功能;
- 更好的包管理: 独立版本、独立命名以及更高频率的更新。以上优点，AndroidX 开箱既得;
- 目前已经有许多我们耳熟能详的工具库已经迁移至 AndroidX，例如 Google Play 服务、Firebase、Bufferknife、Mockito 2、SQL Delight，我们后面会提到如何迁移它们的依赖;
- 我们正在努力推广 AndroidX 命名空间，未来所有新推出的组件库，例如 Jetpack Compose 和 CameraX，都将成为 AndroidX 的一员。
迁移至 AndoridX 的具体操作可以参考这里：是时候迁移至 AndroidX 了
总结
本文先对 Android 的架构中存在问题进行分析，介绍了 Jetpack 产生的历史背景，并介绍了它与 AndroidX 之间的关系，在之后的文章中，将对 Jetpack 中的各个组件进行学习。
参考
应用架构指南
《Android Jetpack应用指南》
分离关注点（中文维基百科）
是时候迁移至 AndroidX 了
面向对象的三大特性，五大原则
