Android 开发艺术探索笔记（1）

<正常情况下的生命周期分析>

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”