Android 基础知识

一个Activty的生命周期

 

Activty的生命周期的也就是它所在进程的生命周期。

 

每一个活动（ Activity ）都处于某一个状态，对于开发者来说，是无法控制其应用程序处于某一个状态的，这些均由系统来完成。 
但是当一个活动的状态发生改变的时候，开发者可以通过调用 onXX() 的方法获取到相关的通知信息。

 

在实现 Activity 类的时候，通过覆盖（ override ）这些方法即可在你需要处理的时候来调用。

• onCreate ：当活动第一次启动的时候，触发该方法，可以在此时完成活动的初始化工作。 
  onCreate 方法有一个参数，该参数可以为空（ null ），也可以是之前调用 onSaveInstanceState （）方法保存的状态信息。
• onStart ：该方法的触发表示所属活动将被展现给用户。
• onResume ：当一个活动和用户发生交互的时候，触发该方法。
• onPause ：当一个正在前台运行的活动因为其他的活动需要前台运行而转入后台运行的时候，触发该方法。这时候需要将活动的状态持久化，比如正在编辑的数据库记录等。
• onStop ：当一个活动不再需要展示给用户的时候，触发该方法。如果内存紧张，系统会直接结束这个活动，而不会触发 onStop 方法。 所以保存状态信息是应该在onPause时做，而不是onStop时做。活动如果没有在前台运行，都将被停止或者Linux管理进程为了给新的活动预留足够的存储空间而随时结束这些活动。因此对于开发者来说，在设计应用程序的时候，必须时刻牢记这一原则。在一些情况下，onPause方法或许是活动触发的最后的方法，因此开发者需要在这个时候保存需要保存的信息。
• onRestart ：当处于停止状态的活动需要再次展现给用户的时候，触发该方法。
• onDestroy ：当活动销毁的时候，触发该方法。和 onStop 方法一样，如果内存紧张，系统会直接结束这个活动而不会触发该方法。
• onSaveInstanceState ：系统调用该方法，允许活动保存之前的状态，比如说在一串字符串中的光标所处的位置等。 
  通常情况下，开发者不需要重写覆盖该方法，在默认的实现中，已经提供了自动保存活动所涉及到的用户界面组件的所有状态信息。 

Activity栈

上面提到开发者是无法控制Activity的状态的，那Activity的状态又是按照何种逻辑来运作的呢？这就要知道 Activity 栈。

 

每个Activity的状态是由它在Activity栈（是一个后进先出LIFO，包含所有正在运行Activity的队列）中的位置决定的。

当一个新的Activity启动时，当前的活动的Activity将会移到Activity栈的顶部。

如果用户使用后退按钮返回的话，或者前台的Activity结束，在栈上的Activity将会移上来并变为活动状态。如下图所示：

一个应用程序的优先级是受最高优先级的Activity影响的。当决定某个应用程序是否要终结去释放资源，Android内存管理使用栈来决定基于Activity的应用程序的优先级。

Activity状态 
一般认为Activity有以下四种状态：

活动的：当一个Activity在栈顶，它是可视的、有焦点、可接受用户输入的。Android试图尽最大可能保持它活动状态，杀死其它Activity来确保当前活动Activity有足够的资源可使用。当另外一个Activity被激活，这个将会被暂停。 
暂停：在很多情况下，你的Activity可视但是它没有焦点，换句话说它被暂停了。有可能原因是一个透明或者非全屏的Activity被激活。 
当被暂停，一个Activity仍会当成活动状态，只不过是不可以接受用户输入。在极特殊的情况下，Android将会杀死一个暂停的Activity来为活动的Activity提供充足的资源。当一个Activity变为完全隐藏，它将会变成停止。 
停止：当一个Activity不是可视的，它“停止”了。这个Activity将仍然在内存中保存它所有的状态和会员信息。尽管如此，当其它地方需要内存时，它将是最有可能被释放资源的。当一个Activity停止后，一个很重要的步骤是要保存数据和当前UI状态。一旦一个Activity退出或关闭了，它将变为待用状态。 
待用： 在一个Activity被杀死后和被装在前，它是待用状态的。待用Acitivity被移除Activity栈，并且需要在显示和可用之前重新启动它。

 

activity的四种加载模式

在android的多activity开发中，activity之间的跳转可能需要有多种方式，有时是普通的生成一个新实例，有时希望跳转到原来某个activity实例，而不是生成大量的重复的activity。加载模式便是决定以哪种方式启动一个跳转到原来某个Activity实例。

在android里，有4种activity的启动模式，分别为： 

• standard: 标准模式，一调用startActivity()方法就会产生一个新的实例。
• singleTop: 如果已经有一个实例位于Activity栈的顶部时，就不产生新的实例，而只是调用Activity中的newInstance()方法。如果不位于栈顶，会产生一个新的实例。
• singleTask: 会在一个新的task中产生这个实例，以后每次调用都会使用这个，不会去产生新的实例了。
• singleInstance: 这个跟singleTask基本上是一样，只有一个区别：在这个模式下的Activity实例所处的task中，只能有这个activity实例，不能有其他的实例。

这些启动模式可以在功能清单文件AndroidManifest.xml中进行设置，<activity>中的launchMode属性。

相关的代码中也有一些标志可以使用,比如我们想只启用一个实例,则可以使用 Intent.FLAG_ACTIVITY_REORDER_TO_FRONT 标志，这个标志表示：如果这个activity已经启动了，就不产生新的activity，而只是把这个activity实例加到栈顶来就可以了。

Intent intent = new Intent(ReorderFour.this, ReorderTwo.class);  
intent.addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT);  
startActivity(intent);  

Activity的加载模式受启动Activity的Intent对象中设置的Flag和manifest文件中Activity的<activity>元素的特性值交互控制。

下面是影响加载模式的一些特性

核心的Intent Flag有： 
FLAG_ACTIVITY_NEW_TASK 
FLAG_ACTIVITY_CLEAR_TOP 
FLAG_ACTIVITY_RESET_TASK_IF_NEEDED 
FLAG_ACTIVITY_SINGLE_TOP 
核心的<activity>特性有： 
taskAffinity 
launchMode 
allowTaskReparenting 
clearTaskOnLaunch 
alwaysRetainTaskState 
finishOnTaskLaunch

 

Activity的taskAffinity属性

Activity的归属，也就是Activity应该在哪个Task中，Activity与Task的吸附关系。我们知道，一般情况下在同一个应用中，启动的Activity都在同一个Task中，它们在该Task中度过自己的生命周期，这些Activity是从一而终的好榜样。 

    那么为什么我们创建的Activity会进入这个Task中？它们会转到其它的Task中吗？如果转到其它的Task中，它们会到什么样的Task中去？ 

    解决这些问题的关键，在于每个Activity的taskAffinity属性。 

    每个Activity都有taskAffinity属性，这个属性指出了它希望进入的Task。如果一个Activity没有显式的指明该Activity的taskAffinity，那么它的这个属性就等于Application指明的taskAffinity，如果Application也没有指明，那么该taskAffinity的值就等于包名。而Task也有自己的affinity属性，它的值等于它的根Activity的taskAffinity的值。 

    一开始，创建的Activity都会在创建它的Task中，并且大部分都在这里度过了它的整个生命。然而有一些情况，创建的Activity会被分配其它的Task中去，有的甚至，本来在一个Task中，之后出现了转移。我们首先分析一下android文档给我们介绍的两种情况。 

    第一种情况。如果该Activity的allowTaskReparenting设置为true，它进入后台，当一个和它有相同affinity的Task进入前台时，它会重新宿主，进入到该前台的task中。 

    我们验证一下这种情况。 
Application Activity taskAffinity allowTaskReparenting 
application1 Activity1 com.winuxxan.affinity true 
application2 Activity2 com.winuxxan.affinity false 

    我们创建两个工程，application1和application2，分别含有Activity1和Activity2，它们的taskAffinity相同，Activity1的allowTaskReparenting为true。 

    首先，我们启动application1,加载Activity1，然后按Home键，使该task（假设为task1）进入后台。然后启动application2，默认加载Activity2。 

    我们看到了什么现象？没错，本来应该是显示Activity2，但是我们却看到了Activity1。实际上Activity2也被加载了，只是Activity1重新宿主，所以看到了Activity1。 

    第二种情况。如果加载某个Activity的intent，Flag被设置成FLAG_ACTIVITY_NEW_TASK时，它会首先检查是否存在与自己taskAffinity相同的Task，如果存在，那么它会直接宿主到该Task中，如果不存在则重新创建Task。 

    我们来做一个测试。 

    我们首先写一个应用，它有两个Activity（Activity1和Activity2），AndroidManifest.xml如下： 

    <application android:icon="@drawable/icon" android:label="@string/app_name"> 
        <activity android:name=".Activity1" 
                  android:taskAffinity="com.winuxxan.task" 
                  android:label="@string/app_name"> 
        </activity> 
        <activity android:name=".Activity2"> 
            <intent-filter> 
                <action android:name="android.intent.action.MAIN" /> 
                <category android:name="android.intent.category.LAUNCHER" /> 
            </intent-filter> 
        </activity> 
    </application> 

    Activity2的代码如下： 

    public class Activity2 extends Activity {  
        private static final String TAG = "Activity2";  
        @Override 
        protected void onCreate(Bundle savedInstanceState) {  
            super.onCreate(savedInstanceState);  
            setContentView(R.layout.main2);    
        }  
               
        @Override 
        public boolean onTouchEvent(MotionEvent event) {  
            Intent intent = new Intent(this, Activity1.class);  
            intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);  
            startActivity(intent);  
            return super.onTouchEvent(event);  
        }  
    } 

    然后，我们再写一个应用MyActivity，它包含一个Activity（MyActivity），AndroidManifest.xml如下： 

    <application android:icon="@drawable/icon" android:label="@string/app_name"> 
        <activity android:name=".MyActivity" 
                  android:taskAffinity="com.winuxxan.task" 
                  android:label="@string/app_name"> 
            <intent-filter> 
                <action android:name="android.intent.action.MAIN"/> 
                <category android:name="android.intent.category.LAUNCHER"/> 
            </intent-filter> 
        </activity> 

    我们首先启动MyActivity，然后按Home键，返回到桌面，然后打开Activity2，点击Activity2，进入Activity1。然后按返回键。 

    我们发现，我们进入Activity的顺序为Activity2->Activity1，而返回时顺序为Activity1->MyActivity。这就说明了一个问题，Activity1在启动时，重新宿主到了MyActivity所在的Task中去了。 

    以上是验证了文档中提出的两种TaskAffinity的用法。 

    下面就是见证奇迹的时刻，同志们，不要眨眼！ 

    我们现在将上一文中的launchMode和本文讲的taskAffinity结合起来。 

    首先是singleTask加载模式与taskAffinity的结合。 

     我们还是用上一文中的singleTask的代码，这里就不在列出来了，请读者自己查阅上一文。唯一不同的就是，我们为MyActivity和Activity1设置成相同的taskAffinity，重新执行上文的测试。 

    我们发现测试结果令我们惊讶：从同一应用程序启动singleTask和不同应用程序启动的结果完全与上文讲的相反！ 

    我们经过思考，就可以把从同一应用程序执行和从不同应用程序执行另种方式同一起来，得到一个结论： 

    当一个应用程序加载一个singleTask模式的Activity时，首先该Activity会检查是否存在与它的taskAffinity相同的Task。 

    1、如果存在，那么检查是否实例化，如果已经实例化，那么销毁在该Activity以上的Activity并调用onNewIntent。如果没有实例化，那么该Activity实例化并入栈。 

    2、如果不存在，那么就重新创建Task，并入栈。 

    用一个流程来表示： 

   然后我们来检测singleInstance模式融入taskAffinity时的情况，我们也是用上文中测试singleInstance的例子，在此不列出，读者翻阅前文查阅。唯一不同的是，我们将MyActivity和Activity2设置成相同的taskAffinity。 

    我们发现测试结果也有一定的出入，就是，当从singleInstance中启动Activity时，并没用重新创建一个Task，而是进入了和它具有相同affinity的MyActivity所在的Task。 

    于是，我们也能得到以下结论： 

    1、当一个应用程序加载一个singleInstance模式的Activity时，如果该Activity没有被实例化，那么就重新创建一个Task，并入栈，如果已经被实例化，那么就调用该Activity的onNewIntent； 

    2、singleInstance的Activity所在的Task不允许存在其他Activity，任何从该Activity加载的其它Actiivty（假设为Activity2）都会被放入其它的Task中，如果存在与Activity2相同affinity的Task，则在该Task内创建Activity2。如果不存在，则重新生成新的Task并入栈。