Android框架式编程之Android Architecture Components

1. 当前Android开发面临的问题

Android开发不同于传统的桌面程序开发，桌面程序一般都有唯一的快捷方式入口，并且常作为单进程存在；而一个典型的Android应用通常由多个应用组件构成，包括不同数量的Activity、Fragment、Service、Content Provider、Broadcast Receiver等。

此外，用户在移动设备上常常会在多个App之间切换。例如，如果用户想要在一个社交应用上分享一张图片，那么一般的流程是首先该社交应用可能会使用Intent的方式通过Android系统来启动一个拍照应用，此时用户虽然离开了社交App，但其体验是无缝衔接的。同样地，拍照应用也可能启动其他应用，如文件选择器或其他。最终用户返回社交应用然后分享图片。当然，用户操作可能在上述过程中的任何时刻被电话打断，当通话结束再继续进行图片分享流程。

在Android系统中类似的应用切换非常频繁，因此需要使得我们的应用能够正确处理上述流程。而且移动设备的资源是有限的，所以在任何时候，操作系统都有可能杀死一些应用来为一些新的应用腾出资源。

综上，我们的应用组件可能被无规则地启动，也可能随时被用户或系统销毁，其生命周期并不由我们控制，因此我们不应该在应用组件中存储任何数据而且组件之间也不应该互相依赖。这时候，我们就需要重新考虑如何设计Android应用的架构了。

2. Android 应用架构设计原则

在设计Android应用架构的时候，我们需要考虑以下两个设计原则：

第一，职责分离。我们不应该把任何跟UI处理或系统交互无关的代码写到Activity或Fragment中，而是尽可能保持Activity和Fragment的简洁（职责单一化），这样可以避免许多生命周期相关的问题。因为我们并不能控制这些类，所以我们应该最小化对App组件的依赖从而提供稳定的用户体验。

第二，数据模型（Model）驱动UI，最好是可持久化的数据模型。持久化数据不仅可以保证当系统为了释放资源而销毁掉App时用户不会丢失数据，而且当网络状况差或无网络时App依然可以工作。Model也可以看成一种处理应用数据的组件，它们独立于视图和其他App组件，因此Model不存在和生命周期相关的问题。