Android架构组件
App开发者面临的常见问题
与传统的桌面应用程序不同，android应用程序的结构要复杂得多，在大多数情况下，它们只在桌面快捷启动方式中有一个入口，并且作为单个进程运行。一个典型的android应用程序是由多个app组件（android四大组件）构成的，包括activities，fragments,services,content providers and broadcast receivers。
这些app组件中的大部分都是在应用清单中声明的，android操作系统使用这些组件来决定如何将应用程序集成到设备的用户体验中。虽然，如前所述，桌面应用程序通常上是以单个进程运行的，但是一个合理的andoroid应用需要更加灵活，因为用户可以通过不同的应用程序，在他们的设备上不断切换流程和任务。
例如，想象下您在最喜爱的社交网络应用中分享照片时会发生什么情况。这个应用程序触发了一个Camera（拍照或摄像）意图，由android操作系统启动一个camera应用来处理请求。此时，用户虽然离开了这个社交网络应用，但他们的体验是无缝的。相机应用程序又可能触发其他意图，例如启动文件选择器，该文件选择器可以启动另一个应用程序。最终用户回到社交网络应用并分享照片。此外，用户在这个过程的任何时候都可能被电话打断，并在打完电话后回来继续分享照片。
在andorid中，这种应用程序跳转行为是常见的，所以您的应用程序必须正确处理这些流程。请记住，移动设备是资源受限的，所以在任何时候，操作系统都可能需要杀死一些应用程序，以腾出空间给新的应用。
这一切的要点在于，您的app组件可以单独和无序地启动，并且可以在任何时候由用户或系统销毁。由于app组件是短暂的，并且他们的生命周期（创建和销毁时）不在您的控制之下，因此您不应该再app组件中存储任何app数据或状态，并且你的app组件不应相互依赖。
通用架构原则
如果你不使用app组件存储app数据和状态，那么应该如何构造应用程序呢？
你关注的最重要的事情是如何在你的应用中分离关注点。常见的错误是将所有的代码写入一个actviity或feagment，任何不处理ui或与操作系统交互的代码都不应该出现在这些类中，你应该尽可能保持actviity或fragment精简，这样可以避免许多生命周期相关的问题。请记住，你不拥有这些类，它们只是简历操作系统和你的应用程序之间契约的胶水类。android操作系统可能会随时根据用户交互或其他因素（如低内存）来销毁它们。最好尽可能地减少依赖它们，以提供可靠的用户体验。
第二个重要原则是 你应该从一个模型驱动你的UI，最好是一个持久化的模型。之所以说持久化是理想的模型，原因有两个：如果操作系统销毁你的应用程序以释放资源，那么你的用户就不会丢失数据，即使网络连接不稳定或连接不上，您的应用程序也会继续工作。模型是负责处理应用程序数据的组件。他们独立于应用程序的views和app组件，因此模型与这些app组件的生命周期问题是相隔离的。保持简洁的UI代码，以及不受约束的应用程序逻辑，可以使app的管理更加容易，基于具有明确定义的管理数据责任的模型类的应用程序，会更加具有可测试性，并使你的应用程序状态保持前后一致。