用户触发或系统的触发的不同事件会导致Activity从一个状态转换为另外一个状态。
下面介绍一下触发状态转化的几种事件：
第一种：配置发生了更改
典型的配置发生更改的场景为横屏和竖屏之间的切换。当在横竖屏之间切换时，Activity会依次经过Pause->Stop->Destory->Create->Start->Resume的过程。即先销毁当前Activity，然后再重新创建Activity。
第二种：处理多窗口模式的情况
当应用进入多窗口模式的时候，会和配置发生变更经历的状态一致。
如果应用已经处于多窗口模式，这时候调整窗口的大小，Activity会销毁并重新创建。
再Android7及以上Android10一下的版本中，当Activity失去焦点后将会处于Pause状态。在模拟器中点击下方空白处即会转移到Pause状态。
但是在Android10版本的系统中，对这一特性进行了改变，Android10提出了Multi Resume的概念，即可见堆栈中所有可设置为焦点的顶层Activity都处于Resume状态。
于是我下载了Android10版本的模拟器进行了测试。
从上面的测试可以看出，即使我们的应用没有拥有焦点，但是它的状态依然是Resume。这两个应用分别创建了任务栈，而且都是可见堆栈，并且我们看到的这两个Activity都是各自堆栈的顶层Activity，因此这两个Activity都是Resume状态。
第三种：Activity或对话框显示在前台
这里又分为两种情况：
第一种情况：Activity被另外一个Activity部分遮掩，这时候被遮掩的Activity会一直处于Pause状态，等上层Activity销毁后重新进入Resume状态。
第二种情况：Acitivity被两外一个Acvitity完全遮挡，即原来的Activity变得完全不可见，这时候，原Activity会先进入Pause状态，当另外一个Activity变为Resume状态的时候，原Activity这时变得完全不可见，进入Stop状态。当被覆盖的Activity重新回到前台的时候，会先变为ReStart状态，然后变为Start状态，最后变为Resume状态。
跳转到另外一个Activity:
回到原来的Activity:
第四种：用于点击返回按钮
点击返回按钮的行为是用户期望完全退出此Acitivity，这意味着此Activity不仅会被销毁且会被移出返回栈，因此当用于点击返回按钮时，Activity会依次经过Pause状态、Stop状态、Destory状态，并且不会触发onSaveIinstanceState回调，因为完全退出和再次开启时的Activity应该时完全不同的两个的Activity。
第五种：系统终止应用进程
这种情况时当系统内存不够时，系统会终止优先级较低的进程以释放内存。系统终止进程时Activity经过的状态和点击返回键时的状态类似，差别可能时被终止的Activity被终止时所处的状态可能不是Resume状态。
