完整文章地址：App开发架构指南（谷歌官方文档译文）
通用的架构准则
最重要的一个原则就是尽量在app中做到separation of concerns（关注点分离）。常见的错误就是把所有代码都写在Activity或者Fragment中。任何跟UI和系统交互无关的事情都不应该放在这些类当中。尽可能让它们保持简单轻量可以避免很多生命周期方面的问题。别忘了能并不拥有这些类，它们只是连接app和操作系统的桥梁。根据用户的操作和其它因素，比如低内存，Android OS可能在任何时候销毁它们。为了提供可靠的用户体验，最好把对它们的依赖最小化。
第二个很重要的准则是用model驱动UI，最好是持久化的model。之所以要持久化是基于两个原因：如果OS销毁app释放资源，用户数据不会丢失；当网络很差或者断网的时候app可以继续工作。Model是负责app数据处理的组件。它们不依赖于View或者app 组件（Activity，Fragment等），因此它们不会受那些组件的生命周期的影响。保持UI代码的简单，于业务逻辑分离可以让它更易管理。
分离出Repository
ViewModel的一个简单的实现方式是直接调用Webservice获取数据，然后把它赋值给User对象。虽然这样可行，但是随着app的增大会变得难以维护。ViewModel的职责过多也违背了前面提到的关注点分离（separation of concerns）原则。另外，ViewModel的有效时间是和Activity和Fragment的生命周期绑定的，因此当它的生命周期结束便丢失所有数据是一种不好的用户体验。相反，我们的ViewModel将把这个工作代理给Repository模块。
缓存数据
UserRepository的问题在于当获取完数据之后，它并没有把数据保存下来。如果用户离开UserProfileFragment然后在回来，app会重新获取数据。这是很不好的，原因有二：1.浪费了带宽资源，2.用户被迫等待新的查询完成。为了解决这个问题，我们向UserRepository中添加了一个新的数据源，它将把User对象缓存到内存中。
暴露网络状态
在前面app架构推荐一节中，为了保持例子的简单，我们有意省略了网络错误以及加载状态。这一节我们将演示一种暴露网络状态的方法，使用一个Resource类来封装数据以及数据的状态。
//a generic class that describes a data with a status
public class Resource<T> {
@NonNull public final Status status;
@Nullable public final T data;
@Nullable public final String message;
private Resource(@NonNull Status status, @Nullable T data, @Nullable String message) {
this.status = status;
this.data = data;
this.message = message;
}
public static <T> Resource<T> success(@NonNull T data) {
return new Resource<>(SUCCESS, data, null);
}
public static <T> Resource<T> error(String msg, @Nullable T data) {
return new Resource<>(ERROR, data, msg);
}
public static <T> Resource<T> loading(@Nullable T data) {
return new Resource<>(LOADING, data, null);
}
}
