Android的生命周期

         Acticity作为Android四大组件之首，但是在使用过程中总有一些不容易搞清楚的概念，主要是他的生命周期和启动模式，以及IntentFilter的匹配规则分析。下面将结合底层揭开这几个问题的面纱。

 1.生命周期 

         Activity的生命周期包括典型情况下和异常情况下两部分内容，典型情况也可以认为用户参与下的正常的activity变化，而异常情况代表Activity被系统回收或者由于当前设备Configuration发生改变而导致Activity被销毁重建。

1.1 典型情况

  正常情况，Activity要经历下面几个生命周期;

(1) onCreate:

        Activity正在被创建，这是生命周期的第一个方法，主要做一些初始化的工作，比如调用setContentView加载界面资源等。

(2) onRestart:

        Activity正在重启，一般当Activity从不可见重新到可见时会调用它。比如用户按HOME键后，当前Activity被停止，用户又回到这个Activity时就调用了这个方法。

(3) onStart:

        Acivity正在被启动，这时Activity已经是可见（满足显示的所有条件），但还没出现在前台（还没显示出来）。

(4) onResume：

        Activity已经出现在前台了。注意onStart的时候Activiy还在手机的后台，onResume的时候才出现在前台。

(5) onPause:

        Activity正在停止，正常情况下紧接着就调用了onStop。但是如果几乎瞬间又回到这个Activity，onResume就会被调用，这种极端情况存在但还是很少发生的。这时可以做一些存储数据，停止动画(并未回收资源)等工作，但不能太耗时，否则会影响下一个Activity的现实。因为只有当前Activity的onPause先执行完，新Activity的onResume才会执行。

(6) onStop；

       Activity即将停止，可以做一些稍微又重量级的回收工作，同样注意别太耗时。

(7) onDestroy:

       Activity即将被销毁。这是Acticity的最后一个回调，这时一般做一些回收和资源的释放。

  下面针对具体情况分析一下Activity生命周期的变化：

·第一次启动一个Activity：onCreate-->onStart-->onResume.

·用户启动一个新的Activity或者回到了桌面，当前Activity：onPause->onStop,如果新的Activity的主题是透明的，当前Activity不会调用onStop。

·回到原Activity：onRestart-->onStart-->onResume.

·用户按下back键返回：onPause-->onStop-->onDestroy。

       由上面的几种情况可以看出，在Activity的生命周期中，onCreate和onDestroy是配对的；从Activity是否可见来看，onStart和onStop是配对的，当屏幕的点亮和熄灭，他们会被调用多次；针对Activiy是否出现在前台，onPause和onResume是配对的，同样因为屏幕的点亮和熄灭会多次调用。

  那么问题来了，设当前Activity是A，如果用户打开一个新的Activity B，那么A的onPause和B的onResume哪个先执行，底层是如何控制的呢？

  从系统的源码来看，Activity的启动相当复杂，涉及到ActivityThread、Instrumention和ActivityManagerService（AMS）。简而言之，Instrumention（中文指仪器，工具）负责处理启动Activity的请求，然后Instrumention通过Binder（进程间通讯机制，以后的博文会进行解释）向AMS发出请求，AMS内部有一个ActivityStack并且维护者这个stack，接着AMS就通过ActivityThread去同步stack中Activity的状态从而完成Activity生命周期方法的调用。在ActivtyStack中，栈顶的Activity必须先onPause后，新的Activity才会启动。最终完成新的Activity生命周期调用的是ActivityThread的scheduleLaunchActivty方法。

   有兴趣的朋友可以编写代码验证上述结论，理清了生命周期的各个过程和调用机制，就可以在生命周期的各部分编写出更针对性和健壮的代码。Actiivty的生命周期作为Android运行过程的基本机制，随着版本的不同并不会有太大的改变，毕竟Android系统也需要兼容性和延续性。

1.2 异常情况

1.资源相关的系统配置发生改变导致Activity被杀死，重建：

   我们把一张图片放入drawable目录后，通过Resource去获取，为了兼容不同的设备，我们会在-mdpi、-hdpi、-land放入不同的图片.比如手机横屏和竖屏就会拿到两张不同的图片。在默认情况下，横屏和竖屏的切换回导致Activity的销毁重建，当然我们也可以阻止系统重建Activity。

  如图所示是Activity异常情况下被销毁核重建的过程：

 

  可见Activtiy异常情况下销毁时，onPause，onStop，onDestroy均被调用。由于是异常情况下终止的，所以系统会在执行onStop之前调用Activity的onSaveInstanceState保存当前Activity的状态和视图结构，但和onPause没有时序关系。但注意一点，正常情况下Activity的终止，onSaveInstanceState不会被调用。当Activity被重建后，系统会把onSaveInstanceState保存的Bundle对象作为参数返回给Activity的onRestoreInstanceState和onCreate方法。所以我们就可以在这两个方法中判断Activity是否被重建了，如果被重建了，就可以取出之前保存的数据恢复状态。onRestoreInstanceState在onStart之前调用，从逻辑关系和各方法的功能上分析也应该是这样。

        Activity中针对每一个View是怎样保存和恢复的呢？

  和Activity一样，View中都有onSaveInstanceState和onRestoreInstanceState两个方法。保存和恢复View的系统流程如下;

       Activity被意外终止时，Activity会调用onSaveInstanceState，接着委托Window去保存数据，而Window又委托它上面的的顶级容器去保存数据。顶层容器的一个ViewGroup，然后ViewGroup再去通知它的子元素去保存数据。这个过程和View的绘制过程，事件分发过程采用的上层委托下层，父容器委托子元素的思想是类似的。数据恢复的话也是如此，不再赘述。

    

2.系统内存不足导致低优先级的Activity被杀死

         Activity的优先级从高到低可分为下面的几种：

        (1) 前台的Activity，正在和用户交互。优先级最高。

        (2) 可见但非前台的Activity。比如弹出了一个对话框，导致Activity可见但没有位于前台，不能和用户交互。优先级次。

        (3) 后台Activity，已经被暂停的，执行了onStop，优先级最低。

   当系统内存不足时，系统会根据优先级由低到高杀死目标Activty所在的进程，因为是异常情况，也会调用onSaveInstanceState和onRestoreInstanceState来保存和恢复数据。要知道脱离了四大组件运行的进程将很快被系统杀死，因此后台工作最好放入Service保证工作有一定优先级，才不会被系统轻易杀死。

   但是如果我们希望系统配置发生改变后Activity不被杀死重建该怎么办呢？

   我们可以在AndroidMenifest.xml中的Activity中加入几句声明即可。比如不想旋转屏幕时Activity被重建，可以声明：

android:configChanges=”oritation”多个值之间可以使用 |连接起来。这时当系统配置发生改变，就可以在Activity的onConfiguretionChaged方法中进行自己的特殊处理了。