Google APP架构指北

1. 问题
   由于App随时可能被销毁，而且四大组件是短暂且生命周期不可控，在重建时
   App数据和状态不能依赖四大组件。

2. 架构原则
   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可独立使用，按需接入项目中。

3. ROOM
   持久化SQLite数据库映射层。主要分三层：
   1.Database：维持数据库容器，负责APP中持久化关系型的数据底层连接。
   2.Entity：描述数据库中的表实体。
   3.DAO（Data Access Point）：包含数据库中的数据查询方法。

4. Lifecycle-aware
   当其他组件（Activity/Fragment等）的生命周期状态改变时，Lifecycle-aware组件会做出反应。
   目前Fragment/Fragment在26.1.0的Support库中已实现了LifeCycleOwner接口。其他需要自主实现生命周期的宿主，须实现LifecycleRegister类。
   需要对宿主生命周期做出响应的类只需实现LifecycleObserver接口。

   
   Lifycycle状态变化图

5. LiveData
   主要应用了MVVM模式。可参见如何构建Android MVVM 应用框架。
   LiveData负责监听数据变化回传给UI视图，持有可观测的数据，在组件出现活跃状态时提供更新，一般用于创建反应式UI。

6. ViewModel
   ViewModel的职责是作为UI控制器和视图容器（Fragment/Activity）的连接层。负责控制数据逻辑，在重新创建UI组件时将数据保存起来，简化了视图容器的逻辑。ViewModel不持有View引用，更新数据使用LivaData.
   DataBinding负责维护一个介于UI和视图容器之间的干净接口。
   UI的职责是当数据变化时更新视图，通知ViewModel用户的交互行为。

7. 架构通信

   
   架构中各组件的通信

8. 指导原则
   1.Manifest定义的组件只能处理部分与入口相关的数据。
   2.不同模块的责任边界必须单一明确。
   3.模块暴露的接口尽可能少，尽量对外隐藏内部实现细节。
   4.核心基础模块尽量与业务分离，避免重复造轮子。
   5.持久化尽可能多的有效数据，提升用户的离线体验。
   6.数据源维持单一可信。数据变化的同步必须对APP获取数据的接口无感知。

原文链接