这是我参与8月更文挑战的第11天，活动详情查看：8月更文挑战
Activity 为什么需要生命周期
前面提到过，Activity 的创建和销毁由系统控制，所以才提供生命周期的回调给开发者使用而不允许开发者自己管理 Activity 对象。所以要理解 Activity 的生命周期首先得了解系统如何管理 Activity。
Activity 的创建可跨进程
Android 系统是基于 Linux 内核的，每个 App 都运行在一个独立的进程中，这种设计让每个 App 都很独立，很大程度提高了安全性降低了开发难度，也导致 App 之间协作必须面对跨进程通信的成本。好在 Activity 是完全跨进程启动的，即使是自己的 App 内部也是跨进程启动的，所以开发者不需要自己处理跨进程通信的问题，只要 startActivity 就行了。
低内存下 Activity 的回收与重建
Android 手机的内存管理也是贴近 Linux 的，主要策略是尽量提高内存利用率，不设严格限制，有多少用多少，不够用了再回收。这样做可以在内存够用的情况下给用户最好的体验，最直接的感受是后台应用可以运行。
讲个真实的例子，有一次我打明日方舟剿灭中途有事直接出门了，直到晚上回家才有时间再玩游戏，这时候打开明日方舟还能继续之前的剿灭。后来我换了 iOS 设备，切出去回个微信消息，5分钟，游戏就要重进了。
缺点也是十分明显的，也是 Android 机普遍存在的一个问题：用久了会卡。也不是绝对的，主要原因是用得够久的手机通常都会安装很多 App，其中会有一些不太讲武德的 App 想尽办法自启动或者互相启动进行「保活」，保活的目的大多数是为了及时发推送，也不排除有些 App 在做坏事。总之，Android 的内存管理策略在流氓 App 的攻击下暴露出了问题。
卡顿的问题手机厂商无法从根本上解决，但他们可以加内存。这些年 Android 机的内存提升相当明显，从最初的的 1G 左右一路提高到现在的 8G 或 12G，近两年没有再提升，应该是 12G 是一个好用和研发成本的平衡点了。
于是在宽松的内存管理策略下，内存总会不够用的。在内存实在不足的情况下，Android 系统会杀死后台运行的 App 回收内存，这就是 Activity 被系统强制回收的过程。但这个 App 可能同时开着 100 个 Activity，为了让用户下次打开 App 的时候不用从头开始点 99 次，Android 在回收 Activity 的同时会将 Activity 的一些数据保存起来，下次打开 App 的时候直接恢复页面栈并优先打开栈顶 Activity，这是 Activity 重建的过程。
Activity 需要相对复杂的管理方式，不能交给开发者，于是才有了生命周期。
结
没有想到写什么代码验证文章内容，有点空洞，我也不知道怎么办，sad。
