1 概述
在上述的多种状态中,只有三个状态是持久的,其余都是瞬时状态:
resumed,paused,stopped.这三种状态也分别对应了三种不同的可见性:
- Resumed：在这个状态，activity是在最前端的，用户可以与它进行交互。(通常也被理解为”running” 状态).这种状态下的Activity是完全可见的.
- Paused：在这个状态，activity被另外一个activity所遮盖：另外的activity来到最前面，但是半透明的，不会覆盖整个屏幕。被暂停的activity不会再接受用户的输入且不会执行任何代码。(这里的不会执行任何代码并不代表了任何后台线程都不会工作).此时的Activity是部分可见的.
- Stopped：在这个状态, activity完全被隐藏，不被用户可见。可以认为是在后台。当stopped, activity实例与它的所有状态信息都会被保留，但是activity不能执行任何代码。此时的Activity是完全不可见的.
而除了上述三种状态以外的所有状态,都是瞬时状态.系统快速的执行那些回调函数并通过执行下一阶段的回调函数移动到下一个状态。也就是说，在系统调用onCreate(), 之后会迅速调用onStart(), 之后再迅速执行onResume()。
1.1 Created状态
created状态是在Activity被创建时执行onCreate函数时的状态,如我们前面所说,这是一个瞬时的状态.
因为created状态只是一个瞬时的状态,而且onCreate执行时Activity是没有显示的,因此我们应该尽量减少在onCreate里面尽量少做事情，避免程序启动太久都看不到界面.更严谨的说,是在onCreate函数执行的过程中,用户只能看到程序的actionbar.
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
getActionBar().setDisplayHomeAsUpEnabled(true);
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Log.e("lee", "onCreate");
}
举例说明,上面的这段代码,在程序执行的五秒时间里,用户只能看到一个没有返回键,只有标题的actionbar.
因此,我们尽量只在onCreate中做和初始化UI相关的工作.
1.3 Started状态
started状态是Activity在执行onStart函数时所处的状态,在概述中我们说过,
在Activity从完全不可见转到可见过程中的一个瞬时状态.
从生命周期图中我们可以看到有两条路径可以调用onStart函数:分别是Activity创建和从不可见的stop状态转变为start状态.
和created状态一样,started状态执行时界面依然没有被显示.
- 在从stop状态转变为start状态时,在onStart函数执行时,手机不会显示任何和这个Activity相关的界面,而是停留在之前的页面;
- 锁屏解锁时略有不同,解锁后无论onStart函数执行多久时间,都会立即显示被start的这个Activity.
当然如果我们从更深层的角度看上面两种状态,其实他们属于完全不同的两种情况:
- 第一种情况,Activity发生了跳转,之前的Activity变为stop状态,而且Activity拥有的surface已经被SurfaceFlinger移除;当Activity转入前台的时候,这个Activity的的surface直到onResume函数被执行完后才会被重新创建,
- 而第二种情况,锁屏时,变为stop状态的Activity所用于的surface根本没有被SurfaceFlinger移除,这样当解锁后,相当于surface直接转入前台显示,因此会立即显示,但是同样在onResume执行完之前是不会响应按键的.
当然上面的内容涉及到更深层面Graphic的知识,和主题无关,本文不再展开.
1.4 Resumed状态
onResume函数是Activity转为可显示,进入持久状态前调用的最后一个函数.
onResume函数还会从部分可见转化为可见时调用.
1.5 Paused状态
paused状态也是一个持久状态,如我们前面所说,当Activity被部分遮盖时会被调用.
但是,需要注意的是,当Activity弹出对话框AlertDialog,或者状态栏下拉时,尽管Activity被部分遮挡,但是并不会是Activity转化为paused状态.
当我们使用一个部分透明的,或者dialog样式的(android:theme="@android:style/Theme.Dialog")Activity显示在前的话,后面的Activity会进入paused状态.
1.6 Stop状态
当Activity完全不可见时,Activity转入stop状态.一旦你的activity停止了，系统会在不再需要这个activity时摧毁它的实例(和栈结构有关，通常back操作会导致前一个activity被销毁)。在极端情况下，系统会直接杀死你的app进程，并且不执行activity的onDestroy()回调方法, 因此你需要使用onStop()来释放资源，从而避免内存泄漏。(这点需要注意)
1.7 Destroy
当系统Destory你的activity，它会为你的activity调用onDestroy()方法。因为我们会在onStop方法里面做释放资源的操作，那么onDestory方法则是你最后去清除那些可能导致内存泄漏的地方。因此你需要确保那些线程都被destroyed并且所有的操作都被停止。
注意,屏幕转屏时,系统会先destroy Activity然后重新创建.
也就是说系统会完整的走一次 onPause-onStop-onDestory-onCreate-onStart-onResume.
1.8 onSaveInstanceState
在资源紧张的情况下，系统会选择杀死一些处于非栈顶的Activity来回收资源。 为了能够让这些可能被杀死的Activity能够在恢复显示的时候状态不丢失，所以需要在Activity从栈顶往下压的时候提供onSaveInstanceState的回调用来提前保存状态信息。
而onRestoreInstanceState则是在这个Activity真的回收掉之后的恢复显示阶段用来恢复之前保存的数据。
只要某个Activity是做入栈并且非栈顶时（启动跳转其他Activity或者点击Home按钮），此Activity是需要调用onSaveInstanceState的， 如果Activity是做出栈的动作（点击back或者执行finish），是不会调用onSaveInstanceState的。
onSaveInstanceState存入的数据,可以通过onCreate方法的savedInstanceState参数来重新获得(只有在Activity是被系统杀死的情况下).
在屏幕转屏时,系统会先destroy Activity然后重新创建.
也就是说系统会完整的走一次 onPause-onStop-onDestory-onCreate-onStart-onResume.
系统会在onPause方法后调用onSaveInstanceState方法,在onStart方法后调用onRestoreInstanceState方法.
1.9 一些额外的,关于转屏
Activity每次横竖屏切换都会重新调用onPause->onStop-> onDestory->onCreate->onStart->onResume（为此内容和数据要保存和读取，否则转屏之前的内容就会消失了）
很多时候这样的结果让程序繁琐，为此Android提供了在manifest中设置android:configChanges属性，从而让Activity不延续上述的重建流程；
在Android工程的Mainfest.xml中配置Activity：android:configChanges="keyboardHidden|orientation ，横竖屏切换之后就不会去执行OnCreat函数了，而是会去调用onConfigurationChanged（）这样就能控制横竖屏的切换了。
<Android横竖屏切换不重新调用onCreate()>但是，有一点请注意：Android2.3之前使用上面的android:configChanges="keyboardHidden|orientation就能行。但是，在4.0之后。必须就要使用这个属性android:configChanges="orientation|keyboardHidden|screenSize才能避免Activity重新加载该类不延续上述的重建流程！
如果我们需要处理转屏的事件,可以在Activity或View的：onConfigurationChanged(Configurationnew Config) ，函数中获取当前横竖屏参数。至于其调用顺序跟touch时间的传递顺序相似，不过他没有消费事件的概念，会顺次调用到每一个onConfigurationChanged函数。
