Android 四大核心组件之Activity[生命周期篇]

        转载请注明出处：http://blog.csdn.net/zigui14/article/details/39366925

        从本文开始，将对android的核心内容进行学习，对于Android而言，其有最核心的四大基本组件，它们分别是：Activity、Service、Broadcast以及ContentProvider，我们将在接下来的一系列文章中，深入地了解android核心组件的使用以及其内部的动作。

        本文主要内容：探究Android最常用也是核心中的核心——Activity，一个与用户直接进行交互的组件，是应用于用户之间的直接窗口，我们可以认为，Activity就是Android的门面，因此，深入地学习并了解其内部原理是极其必要的。

        Activity作为一个程序入口，类似于main入口函数的作用，其有自己的生命周期，而Android凭借内部Activity Manager的管理机制，掌握着应用程序的“生”与“死”，首先我们引入一个Activity的生命周期结构图：

Activity的生命周期

        在Android Activity的完整生存期里，可以划分为四个状态，分别是：

• 活动或正在运行状态(Running or active)，可视
• 暂停状态(Pause)，部分可视并且可以被强制销毁
• 停止状态(Stop)，不可视，会被强制销毁
• 即将销毁状态(Destroy)，不可视

        以上四个状态，是按照当前Activity的可视程度以及系统的管理区分的，当一个Activity被创建后并完全地呈现在屏幕上时，那么它就是出于活动状态的；当一个Activity被另外一个视图部分遮挡（包括局部完全遮挡、被另外一个透明Activity遮挡），也就是Activity已经失去了焦点，但是它仍然可以被用户看到，此时就是处于暂停状态的；当一个Activity被完全遮挡，用户无法看到时，出于停止状态。

        需要知道的是，不管Activity是处于Pause状态还是Stop状态，当系统内存不足时，将会将处于暂停或停止状态的Activity强制销毁，释放持有的系统资源，只有当系统资源充裕时，Pause的状态才能够维持，但是不管怎样，处于Stop的Activity最终将会进入下一个状态，即Destroy。

        同时，还有七个生命周期方法，我们能够通过实现这些方法，对生命周期中因状态改变而产生的变化做出相应的反应：

public class FirstActivity extends Activity {    private static final String TAG = "FirstActivity+";    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_first);        // 一个新的Activity被创建，Activity生命周期开始        Log.i(TAG, "onCreate()");        // 下一个方法将会进入onStart()    }    @Override    protected void onStart() {        super.onStart();        // 当一个Activity的所有所需资源准备完成之后，将会显示给用户，处于Activity的栈顶位置        Log.i(TAG, "onStart()");        // 下一个方法将会进入onResume()，如果不可见，将会进入onStop()    }    @Override    protected void onRestart() {        super.onRestart();        // 由于用户进入下一个Activity或者是按了HOME键导致Activity不可见（即进入onStop），再次使其        // 成为可视状态时，将会进入该方法        Log.i(TAG, "onRestart()");        // 下一个方法将会进入onStart()，如过不可视，将会进入onStop()    }    @Override    protected void onResume() {        super.onResume();        // 从Pause状态转变        Log.i(TAG, "onResume()");        // 下一个方法将会进入onPause()    }    @Override    protected void onPause() {        super.onPause();        // 当被部分遮挡时，进入此方法        Log.i(TAG, "onPause()");        // 下一个进入的生命周期方法为onResume()，如果变为不可视状态，将会进入onStop()    }    @Override    protected void onStop() {        super.onStop();        // 当一个Activity完全不可视时，将会处于Stop状态，但是系统不会立即进入onDestroy        Log.i(TAG, "onStop()");        // 系统将会按照当前资源的使用情况，进入onDestroy()    }    @Override    protected void onDestroy() {        super.onDestroy();        Log.i(TAG, "onDestroy()");        // 该Activity的生命结束    }}

        对应Activity的每一个生命周期函数，我们都必须对一些必要的资源进行配置或回收、对状态进行保存或恢复等工作，每一个生命周期函数中一般有固定的工作，物尽其用将会事半功倍，同时也能将要完成的工作流程控制得很好，针对每一个生命周期函数，我们来浅析每一个方法内应该做哪些工作。

        1、onCreate()：这是一个Activity的入口，在这里，我们需要对一些全局资源进行初始化工作，如控件的绑定、控件监听器的绑定以及其它必要对象的初始化工作，onCreate()函数在整个完整的Activity生命周期中，只会被调用一次。

        2、onDestroy()：当一个Activity被系统销毁时，将会进入这个生命周期函数，在这里面，主要是对在运行过程中，释放从系统中索取的资源，包括一些全局资源以及一些网络、数据库连接等资源。

        3、onStart()：当UI可见时，可以重新启动一些更新UI的工作，同时包括一些Broadcast Receiver的注册。
        4、onStop()：用于暂停或停止动画、线程、Service、传感器监听器、线程、定时器等于更新UI有关的事务，在这里也能对Broadcase Receiver进行注销，因为当UI不可见的时候，这些动作往往是没有意义的，同时还会伴随着系统资源的消耗。

        5、onRestart()：除了在onStart第一次被调用时，onRestart()不被调用之外，在重新进入onStart()之前都会被立即调用，能够在这里实现一些在activity完整生命周期内重启的特殊处理。

        5、onResume()：当从onPause中重新被唤醒时，在这里继续进行一些轻量级的操作，太过复杂的工作将会降低用户交互。
        6、onPause()：当设备休眠、Activity被部分遮挡时，就会进入onPause()在这之前，一般都会现对onSaveInstanceState()进行处理，用于保存未来得及更改的事务，当下一次执行onResume之前，进行一些恢复性工作。

        接下来我们通过实际运行，打印出日志，看Activity的实际生命周期的表现：

        当我们第一次运行这个Activity时，依次执行的是：onCreate()->onStart()->onResume()

        为了验证整个UI是在onResume()完成之后才进行显示的，我们不妨在onResume()中做一些稍微耗时的操作（注意，一般我们不会在这里做一些耗时操作，相反，这里面的工作应该是越少越好）。

    @Override    protected void onResume() {        super.onResume();        // 从Pause状态转变        Log.i(TAG, "onResume()");        // 下一个方法将会进入onPause()        for (int i = 0; i < 10; i++) {            try {                Log.i(TAG,"睡眠200ms");                Thread.sleep(200);            } catch (InterruptedException e) {                e.printStackTrace();            }        }        Log.i(TAG,"离开onResume()");    }

        

        我们观察日志打印情况，同时观察UI的绘制，可以发现整个UI的呈现是在离开onResume之后发生的。

        现在，我们进行这样的操作，观察UI的表现以及日志的输出情况：点击HOME键，日志输出如下：

        我们看到，实际运行情况与Activity的生命周期图所描述的一致，刚才的Activity已经出于不可视状态，执行了onStop()这个方法，当我们再次点击运行这个应用时，我们观察到这样的情况：

        首先，抛开第1、2行的日志（刚刚按HOME时打印的），在重新点击我们的应用时，依次执行的是：onRestart()->onStart()->onResume()方法，接下来发生的事就是为什么我们一般在onResume()方法内应该做一些轻量级工作的原因了：只要该Activity没有被系统销毁，处在Activity栈中，用户每次重新点击要求该Activity，都会卡顿，这对用户而言是非常反感的！同样，大家也可以尝试着在onPause()中做一些稍微耗时的操作，观察UI的变化以及日志的输出。

        接下来我们点击返回键，观察日志的输出情况：

        此时执行的就是一个Activity走向'死亡'的过程，依次会执行onPause()->onStop()->onDestroy()，如果重新打开运行应用，那么将会开启另外一个新的生命周期。

        我们试着尝试使设备休眠：

        此时，我们确实已经无法看到任何UI了，即当Activity不可视时，将会进入onStop中，而当我们解除锁屏时，依次又会执行onRestart()->onStart()->onResume()方法，与Activity的情况非常吻合。

        此时我们又会考虑了，Activity的状态转换其实是各种状态下UI的改变，那么我将屏幕旋转呢？又会有什么变化？看日志输出：

        大家发现了吧？当我们旋转屏幕后，这个Activity居然被系统回收销毁了（onDestroy），然后又重新创建了一个新的Activity，从onCreate()这个方法开始，也就是说我们当前的Activity已经不是我们之前的那个了，而是一个全新的内容，这样就需要我们考虑一个问题了，既然是重新创建的一个Activity，那么我怎么样知道我之前的UI是如何的，又应该如何恢复之前UI的状态呢？