简介(一)
===
应用开发者面临的常见问题
---
在大多数情况下，桌面应用程序在启动器快捷方式中有一个单一的入口并且作为单独的独立进程运行，与桌面应用程序不同的是`Android`应用具有更复杂的结构。一个典型的`Android`应用是由多个应用程序组件构成的，包括`activity`，`fragment`，`service`，`content provider`和`broadcast receiver`。
这些应用程序组件中的大部分声明在`manifest.xml`文件中，用来决定如何将应用融入到用户设备的整体体验中。尽管如前所述，传统的桌面应用程序作为独立进程运行，但是正确的编写`Android`应用程序需要更加灵活，因为用户会同过设备上不同的应用程序组织成自己的方式不断切换流程和任务。
例如，考虑下在你喜欢的社交网络应用中分享照片时会发生什么。该应用会触发一个启动相机的`intent`，从该`intent`会启动一个相机应用来处理这个请求。在此刻，用户离开社交网络应用但是用户的体验是无缝的。相机应用转而可能会触发其它的`intent`例如启动文件选择器，这可能会启动另一个应用。最终用户回到社交网络应用并且分享照片。此外，在这个过程中的任何时刻用户都有可能会被一个电话打断，并且在结束通话后再回来继续分享照片。
在`Android`中，这种应用切换行为很常见，所以你的应用程序必须正确处理这些流程。记住，移动设备的资源是有限的，所以在任何时候，操作系统都可能会杀死一些应用为新的应用腾出空间。
其中的重点是应用程序组件可能会被单独和无序的启动，并且可能会被用户或系统在任何时候销毁。因为应用程序组件是短暂的，并且其声明周期（什么时候被创建和销毁）不受你控制，所以不应该在应用程序组件中存储任何应用数据或状态，同时应用程序组件不应该相互依赖。
通用的框架准则官方建议在架构`App`的时候遵循以下两个准则:
- 关注分离
其中早期开发`App`最常见的做法是在`Activity`或者`Fragment`中写了大量的逻辑代码，导致`Activity`或`Fragment`中的代码很臃肿，十分不易维护。现在很多`App` 开发者都注意到了这个问题，所以前两年`MVP`结构就非常有市场，目前普及率也很高。
- 模型驱动`UI`
模型持久�
