问题
由于App随时可能被销毁，而且四大组件是短暂且生命周期不可控，在重建时
App数据和状态不能依赖四大组件。架构原则
1.所有不与UI及系统交互的代码能不要写在Activity/Fragment中，从而避免生命周期相关的问题。
2.将UI与Model分离。Model最好能持久化，保证异常情况下的恢复及离线展示。将View和Model分开能明确Model管理数据的职责，便于测试。
当前的前后端广泛采用的Restful接口通信。
REST(Representational State Transfer)，是一组架构约束条件和原则，描述了一个架构式的网络系统，比如web应用程序。
1.客户端和服务端之间的交互在请求之间是无状态的。从客户端到服务端的每个请求必须包含理解请求所必需的信息。无状态请求可由任何可用服务器回答。
2.服务端的应用程序状态和功能可分为各种资源，客户端和服务端的传输可使用资源统一接口去访问该URI地址。比如标准HTTP的GET/PUT/POST/DELETE方法。
注意：虽然这个官方架构能让系统更健壮，但是选择适应于当前项目，性价比高的架构才是最合理的。LiveData/ViewModel/Lifecycle-aware/Room可独立使用，按需接入项目中。
ROOM
持久化SQLite数据库映射层。主要分三层：
1.Database：维持数据库容器，负责APP中持久化关系型的数据底层连接。
2.Entity：描述数据库中的表实体。
3.DAO（Data Access Point）：包含数据库中的数据查询方法。-
Lifecycle-aware
当其他组件（Activity/Fragment等）的生命周期状态改变时，Lifecycle-aware组件会做出反应。
目前Fragment/Fragment在26.1.0的Support库中已实现了LifeCycleOwner接口。其他需要自主实现生命周期的宿主，须实现LifecycleRegister类。
需要对宿主生命周期做出响应的类只需实现LifecycleObserver接口。
Lifycycle状态变化图
LiveData
主要应用了MVVM模式。可参见如何构建Android MVVM 应用框架。
LiveData负责监听数据变化回传给UI视图，持有可观测的数据，在组件出现活跃状态时提供更新，一般用于创建反应式UI。ViewModel
ViewModel的职责是作为UI控制器和视图容器（Fragment/Activity）的连接层。负责控制数据逻辑，在重新创建UI组件时将数据保存起来，简化了视图容器的逻辑。ViewModel不持有View引用，更新数据使用LivaData.
DataBinding负责维护一个介于UI和视图容器之间的干净接口。
UI的职责是当数据变化时更新视图，通知ViewModel用户的交互行为。-
架构通信
架构中各组件的通信 指导原则
1.Manifest定义的组件只能处理部分与入口相关的数据。
2.不同模块的责任边界必须单一明确。
3.模块暴露的接口尽可能少，尽量对外隐藏内部实现细节。
4.核心基础模块尽量与业务分离，避免重复造轮子。
5.持久化尽可能多的有效数据，提升用户的离线体验。
6.数据源维持单一可信。数据变化的同步必须对APP获取数据的接口无感知。
