第一章 Activity生命周期和启动模式
<正常情况下的生命周期分析>
1. 关于 onStart() onResume() 和 onPause() onStop()的实质区别：
onStart()和onStop()是对于Activity 是否可见这个角度来进行的方法
而onResume()和onStop()是对于Activity 是否处于前台这个角度来进行的方法，除此之外没有实质的区别
2. 假设当前的Activity为A，如果用户这个时候打开一个新的Activity B，那么B的onResume()和A的onPause()哪一个先执行？
简单理解，启动Activty的请求会由Instrumentation来处理，然后它通过Binder向AMS（ActivityManagerService）发送请求，AMS内部维护者一个ActivityStack并负责栈内的Activity的状态同步，AMS通过ActivityThread去同步Activity的状态从而完成生命周期方法的调用。在ActivityStack中的ResumeTopActivityInnerLocker方法中的代码看出需要栈顶的Activity先onPause()后，新的Activity才会启动。最终在ActivityStackSupervisor中的realStartActivityLocked方法中调用scheduelLaunchActivity方法实现了新的Activity的onCreate、onStart、onResume的调用。
因此得出结论是旧的Activity先onPause，新的Activity再启动。
下面是实现 新的Activity的onCreate等的的源码
打印日志显示：
官方文档规定我们在onPasue中尽量不要做重量级的耗时的回收操作，onStop亦然。所以在onStop中做一些稍微重量级的耗时操作而不是在onPause里。
<异常情况下的生命周期分析>
3. 资源相关的系统配置发生改变导致Activity被杀死并重新创建。
屏幕突然从竖屏旋转到横屏，Activity的生命周期会被销毁并且重新创建。下图为默认情况的生命周期图。
可知，当发生异常终止，则在onDestory()之前调用onSaveInstanceState()来保存当前状态，在下个Activity创建onCreate()之后用传来的Bundle的SavaInStacneState调用onRestoreInstanceState()来加载之前的状态。Actvity重启后为我们来恢复这些数据，比如文本框的用户输入的数据，ListView的滚动位置等，每个View都有onSaveInstanceState和onRestoreInstanceState这两个方法。
恢复流程：Activty首先保存了数据，然后委托Window去保存数据，Window再委托它上面的顶级容器去保存数据。顶级容器是是ViewGroup或者DecorView，通知它们的子View来保存。
总之，当onRestoreInstanceState被调用时，系统一定出现了异常终止的Activity，参数 Bundle SaveInstanceState一定是有值的。onCreate中也可以去通过额外判断SaveInstanceState是否非空（因为正常启动一定是null）来恢复信息。但官方文档建议我们还是在onRestoreInstanceState()方法中进行恢复！
4. 资源内存不足导致低优先级的Activity被杀死
数据恢复情况和过程和情况3完全一致，Activity的优先级分为三种
（1）前台Activity——正在和用户交互的Activity，优先级最高
（2）可见但非前台的Activity——比如弹出了对话框，导致Activity可见但是位于后台无法和用户交互
（3）后台Activity——已经被暂停的Activity，比如执行了onStop(),优先级最低。
当系统内存不足的时候会通过优先级去杀死目标Activity所在的进程，后续通过onSaveInstanceState()和onRestoreInstanceState()来恢复数据。可以通过将后台工作放在Service中，这样保证了进程不会被轻易的杀死。
<其他>
当我们不想在翻转屏幕的时候销毁并重建Activity的时候，我们可以通过给ConfigChanges添加属性。
android:configChanges = "orientation"如果想指定多个值，可以用“|”来连接
android:configChanges = "orientation|keyboardHidden"下面给个configChanges的项目表
