为什么安卓不采用墓碑机制？

很多答主并不是开发者，不了解系统实现的细节。所以我相对专业地回答一下。

首先要弄清楚什么是『墓碑机制』。简单来说墓碑机制就是当 app 进入后台前将应用状态以某种形式持久化，然后释放其正在使用的资源（包括内存、CPU 等），等待 app 再次进入前台时再将这个保存的状态恢复出来，此时应用就跟没有被杀死继续运行了一样。

实际上 iOS 不是严格意义上的墓碑机制，因为 iOS 应用在进入后台时可以向系统申请一定时间的后台运行时间（一般不超过 10 分钟），在这个时间超过后进程会被挂起，CPU 资源完全释放，内存会被保留，这时再次进入应用，系统直接将挂起的进程继续就可以了，不需要做任何显式的状态保存和恢复。然而如果应用很长时间没有被调到前台了，或者内存资源十分紧张，系统缺页且虚拟内存也十分紧张，那么 UIApplication 会代理系统告诉应用『你要被杀死了』，部分应用就会做最后的状态保存工作（application:shouldSaveApplicationState: 需要返回 YES 并且开发者需要做适配工作），之后系统会完全关闭应用的进程并且释放所有内存，再次进入应用时如果开发者没做（国内大部分 app 都没做）上面的状态保存工作的话，这个应用就跟全新打开一样，之前编辑的文本、浏览的文章全部丢失，应用重新从 main 函数执行。

再说 Android，Android 没有像 iOS 那用严格限制应用的后台时间，相反还允许开发者使用 Service、Broadcast Receiver 等组件长时间驻留在后台。正是由于没有 iOS 这种限制，开发者开始肆无忌惮地开 Service，疯狂防止被杀死，很遗憾，内存满了。这时系统就会发出警告（onTrimMemory），如果应用仍然不管不顾地不释放资源（包括 Java VM Heap 和 Ashmem 等区域），系统只好把这个应用杀掉了，但是 Android 会通过自己的状态保存与恢复机制存储部分应用数据，大部分的 Widgets 都实现了状态保存与恢复，那么下次应用重启时这些 UI 的状态还在，但是其他的数据就会丢失掉。由于 Android 对很多组件都做了简单的状态管理，所以像 Intent、Bundle 这样的对象都可以很容易地被系统序列化保存到磁盘。用户也就很少会看到像 iOS 应用那样从头运行的情况，一般都是以 Activity 为单位地恢复，但是缓存在内存的图片、数据会丢失，需要重新加载。

所以不是不能采用墓碑机制，是现在的系统会分情况使用不同的内存管理机制。如果 Android 一开始就用墓碑机制，Service、AIDL、Binder 啥的我们都可以不学了。要知道墓碑机制鼻祖 Windows Phone 就是个单任务系统。