1.Activity生命周期与启动模式

1.1 生命周期

1.1.1 正常生命周期

有用户参与的activity生命周期

两个问题:
1. onResume/onStart 和 onPause/onStop.的区别
onStart和onStop 从是否可见的角度,
onResume和onPause 是从是否在前台的角度

2. 两个Activity, a和b, 当前为a来启动b的时候, 是先走了a的onPause再调用b的onResume吗
是的, 可以研究下Activity启动流程这块.

onPause和onStop都不能执行太耗时的操作, 尤其是onPause.
尽量在onStop里做操作.

Activity启动流程

Todo:
这是一个相当复杂的过程, 涉及到Instrumentation, ActivityThread和 ActivityManagerService(简称AMS).
启动Activity的请求由Instrumentation来处理, 通过Binder向AMS发请求. AMS内部维护一个ActivityStack, 并同步Activity的状态同步, AMS通过ActivityThread去同步Activity的状态从而完成生命周期方法的调用.

Activity生命周期

1.1.2 异常生命周期

被系统回收或设备configuration改变导致销毁重建

情况1: 资源相关的系统配置发生改变导致Activity被杀死并重新创建.
资源加载机制:
举例一张图片, 放在drawable目录下, 就可以通过Resource去获取, 为了兼容不同分辨率可以在一些目录下放置不同的图片.(各种dpi).
默认状况下, 当前Activity处于竖屏状态, 突然旋转屏幕, 就会被销毁且重新创建(因为系统配置发生了变化).
当然也可以阻止系统重新创建该activity.

系统配置发生改变后, activity会被销毁, onPause, onStop, onDestroy方法都会被调用. (仅当)异常终止时, 会调用onSaveInstanceState. 这个会在onStop之前调用. 但是和onPause没有既定的时序关系. 可能之前也可能之后.
然后重新创建时, 把onSaveInstanceState保存的Bundle, 调用onRestoreInstanceState来取他. onRestoreInstanceState的时序在onStart之后.

可以在onCreate/onRestoreInstanceState的时候来取Bundle, 但是需要区分, onCreate正常启动的时候Bundle是为null的, 所以要做下判断, onRestoreInstanceState这个没有问题.

onSaveInstanceState和 onRestoreInstanceState中, 系统自动为我们做了一定的恢复工作: 保存当前activity的视图结构. 例如文本框的输入内容/ listView的滚动位置, 每个view都有这个两个方法,具体恢复什么需要看源码的具体实现.

保存恢复/view层次结构流程:

1. 意外终止,调用onSave..()保存数据
2. Activity委托Window去保存数据
3. Window再委托上面的顶级容器去保存数据.
4. 顶层容器是个ViewGroup, 一般来说可能是DecorView, 顶层容器再去一一通知它的子元素来保存.

例如TextView, 可保存文本框输入内容, 以及选中状态.

委托思想:
上层委托下层, 父容器委托子元素去处理一件事情. 相关例子:View的绘制, 事件分发.

情况2: 资源内存不足导致低优先级的activity被杀死

同样按照上一种情况来存储/恢复数据

优先级排序:

1. 前台activity
2. 可见但非前台activity
3. 后台activity

如果一个进程中没有四大组件在运行, 那么这个进程将很快被系统杀死, 所以一些后台工作最好放入Service中, 保证一定的优先级, 这样就不会被轻易杀死了.

不让activity重新创建:

//配configChanges属性, 有很多值, 可以加“|”连接起来.
android:configChanges = "orientation"