- 第一条准则：「不要在应用程序组件中保存任何应用数据或状态，并且组件间也不应该相互依赖」。
最常见的错误就是在 Activity 或 Fragment 中写了与 UI 和交互无关的代码。尽可能减少对它们的依赖，这能避免大量生命周期导致的问题，以提供更好的用户体验。
- 第二条准则：「通过 model 驱动应用 UI，并尽可能的持久化」。
这样做主要有两个原因：
如果系统回收了你的应用资源或其他什么意外情况，不会导致用户丢失数据。 Model 就应该是负责处理应用程序数据的组件。独立于视图和应用程序组件，保持了视图代码的简单，也让你的应用逻辑更容易管理。并且，将应用数据置于 model 类中，也更有利于测试。
-
所有您在 manifest 中定义的组件 - activity, service, broadcast receiver... 都不是数据源。因为每个组件的生命周期都相当短，并取决于当前用户与设备的交互和系统的运行状况。简单来说，这些组件都不应当作为应用的数据源。
-
在您应用的各个模块之间建立明确的责任边界。比如，不要将与数据缓存无关的代码放在同一个类中。
-
每个模块尽可能少的暴露内部实现。从过去的经验来看，千万不要为了一时的方便而直接将大量的内部实现暴露出去。这会让你在以后承担很重的技术债务（很难更换新技术）。
-
在您定义模块间交互时，请考虑如何使每个模块尽量隔离，通过设计良好的 API 来进行交互。
-
您应用的核心应该是能让它脱颖而出的某些东西。不要浪费时间重复造轮子或一次次编写同样的模板代码。相反，应当集中精力在使您的应用独一无二，而将一些重复的工作交给这里介绍的 Android Architecture Components 或其他优秀的库。
-
尽可能持久化数据，以便您的应用在脱机模式下依然可用。虽然您可能享受着快捷的网络，但您的用户可能不会。