taskAffinity 属性详解

Posted 2023-04-02

参考技术A

本篇文章的目的是为了 搞清楚， 哪些情况下开启一个 Activity 会在新的 task 运行，哪些情况下会继续在原来的task 运行。

每个 Activity 运行时都有一个其归属的 task栈，我们可以用 activity.getTaskId() 的方法得到当前 activity 的taskId。 如果两个 activity 的 taskId 不同，则他们肯定不会属于同一个 task。

为了方便，我们在 Application 中注册生命周期回调，类似这样，我们打印出当前 activity 和其归属的 taskid。

taskAffinity 的使用方式如下，

如上图所示，taskaffinity 可以单独对一个 activity 使用，代表该 activity 所想归属的 task；
也能对application 使用，代表该 application 内声明的所有 activity 都归属于这个task。

如果 activity 组件没有声明 taskAffinity 的话，该 activity 的 taskAffinity 属性也是有默认值的。如果 application 指定了 taskAffinity 值，默认值就是 application 指定的 taskAffinity 值；如果 application 未指定的话，默认值就是 manifest 中声明的包名（package 对应的字符串）。

android 手机的任务列表就是根据不同 task 弹出的，我们可以根据任务管理器有几个 item 图标，来知道我们开启了几个 task。

是不是我指定了一个 Activity 的 taskAffinity 值（跟包名不同），运行该 Activity 时，是否就会新开这个 task栈呢？

答案是否定的， 一个 Activity 运行时所归属的task，默认是启动它 的那个Activity 所在的 task （下文将会验证）。

taskAffinity 单独使用并不会生效。
要想其生效，需要配合其他属性使用，或者配合 Intent.FLAG_ACTIVITY_NEW_TASK，或者配合
allowTaskReparenting 。使用时用其中的一个就行，下面将详细介绍这两个属性。

Intent.FLAG_ACTIVITY_NEW_TASK 使用方式如下，

首先说下这个规则是根据测试结果反推出来的，不对之处还还请指出（捂脸。。。）

==当 AMS 发现启动了一个带有 FLAG_ACTIVITY_NEW_TASK 标签的 Activity 时，会先去寻找当前是否存在这个 Activity 的 task 值（这个值具体是什么可看 知识点2），如果不存在的话，就会创建该task，如果存在就省去了创建 task 这个步骤。然后在把要启动的 Activity 添加到 task 中。

下面开始我们的测试，测试结果为过滤后的log日志，并给出相应分析。

我们假定都是 Activity A 跳转到 Activity B 中，A没有指定 taskAffinity 属性,B 的launchMode 为standard。

可以验证：一个Activity 归属的task 是由 启动它的 Activity 所决定的。

可以验证，一个 Activity 的默认 task 值就是 manifest 定义的包名。

可以验证：不指定 FLAG_ACTIVITY_NEW_TASK的话， 即使 taskAffinity 不同，一个Activity 归属的task 仍然是由 启动它的 Activity 所决定的。

可以验证：即使 使用了 FLAG_ACTIVITY_NEW_TASK，但由于两者的 taskAffinity 相同，所以仍然不会开启一个新的task。

可以验证：开启一个新task 的条件是 FLAG_ACTIVITY_NEW_TASK 和 taskAffinity 不同 缺一不可。

可以得出：未指定 FLAG_ACTIVITY_NEW_TASK 和 新的 taskAffinity 时，这两种启动模式对task 没有影响

可以得出：
singleinstance 启动模式本身就是会开启一个新的task 装载 这个Activity，且task 中只有这一个 Activity。
经判断得知，AMS 是先对 launchMode 做判断 再处理 FLAG_ACTIVITY_NEW_TASK 的，如果是 singleinstance ，则会直接开启一个task。

上面七个 case 均是在同一个app 内的，现在考虑跨进程调用的情况，A在 app1，B在app2， 此时 B 的默认 task 肯定是和 A 不同的 。
我们可以通过隐式启动的方式启动B，B 仍然是标准启动模式。
类似这样

++下文 所有的 App1的log标识为 MyApplication，App2 的标识为 MyApplication2。++

可以得出：case 8 与 case 3 的本质是相同的，仅仅是 A 和 B 的taskA 属性不同，所以没有开启新的task。
我们还可以看出，task 是可以跨进程的，即一个 task 中的 Activities 是可以运行在不同的进程中的。（关于 A 和 B 不在同一个进程读者可自行验证）

可以得出：case 9 与 case 5 的本质是相同的。

至此，Intent 的 FLAG_ACTIVITY_NEW_TASK 属性 应该算是讲解清楚了。

我们还可以得出一个有意思结论，那就是 AMS 分配的taskid 是线性递增的，每次开启一个新的task ，taskid 永远都是 +1 的操作。

测试该属性的话，应该先把 FLAG_ACTIVITY_NEW_TASK 属性去掉。

allowTaskReparenting 这个属性指的是一个 Activity 运行时，可以重新选择自己所属的task。基本是在跨app 间调用时，我们在上面的case 8 的基础上，对 Activity 做如下修改

当 A 启动 B 时，这时虽然是在两个进程中的，但其归属的task 是同一个，这时我们回到后台，在桌面点击 B 的应用图标，我们会发现 log 日志如下：
其中 MyApplication 代表 app1，MyApplication2代表 app2。

log 日志如下：

此 case 正好验证之前的解析规则，若 Activity taskAffinity指定的task 已经存在，是会复用之前的task，而不会再重新创建一个新的task。

Activity之taskAffinity属性allowTaskReparenting属性和Android退出整个应用解决方案

singleInstance：

　当ActivityX使用了singleInstance之后：

　会重建一个单独的Task栈用来放置ActivityX。

　该Task栈只能放置ActivityX，即使其他的Activity使用了和ActivityX同样的taskAffinity也不行。

　和singleTask一样，ActivityX不会重复创建

taskAffinity：

　ActivityY使用了taskAffinity之后：

　会重建一个单独的Task栈用来放置ActivityY，和其他Activity分开。但是也有特殊情况，如果第一个Activity就设置了taskAffinity，那么其他的Activitiy就不会创建新的Task栈，而是在第一个Activity的Task栈运行，所以这时候不会和其他Activity分开。

　该Task栈可以放置使用相同的taskAffinity的Activity，即使是跨程序也可以共享同一个Task栈

　当跨程序使用同一个taskAffinity的时候，在哪个Task栈和程序先后启动顺序有关。

Activity官方文档：

　Activity 的亲和关系由 taskAffinity 属性定义。 任务的亲和关系通过读取其根 Activity 的亲和关系来确定。因此，按照定义，根 Activity 始终位于具有相同亲和关系的任务之中。 由于具有“singleTask”或“singleInstance”启动模式的 Activity 只能位于任务的根，因此更改父项仅限于“standard”和“singleTop”模式。

跳转其他应用的activity代码：

//Demo2
//ActivityB.java
Intent intent = new Intent();
intent.setClassName("com.android.demo","com.android.demo.activity.ActivityC");
ActivityB.this.startActivity(intent);

allowTaskReparenting属性

属性：

android:allowTaskReparenting

　除了launchMode可以用来调配Task，的另一属性taskAffinity，也是常常被使用。taskAffinity，是一种物以类聚的思想，它倾向于将taskAffinity属性相同的Activity，扔进同一个Task中。不过，它的约束力，较之launchMode而言，弱了许多。只有当中的allowTaskReparen ting设置为true，抑或是调用方将Intent的flag添加FLAG_ACTIVITY_NEW_TASK属性时才会生效。如果有机会用到Android的Notification机制就能够知道，每一个由notification进行触发的Activity，都必须是一个设成FLAG_ACTIVITY_NEW_TASK的Intent来调用。这时候，开发者很可能需要妥善配置taskAffinity属性，使得调用起来的Activity，能够找到组织，在同一taskAffinity的Task中进行运行。

　当某个拥有相同 affinity 的任务即将返回前台时，Activity 是否能从启动时的任务转移至此任务中去 —“true”表示可以移动，“false”表示它必须留在启动时的任务中。

　通常在启动时，Activity 与启动时的任务相关联，并在整个生命周期都位于此任务中。 利用本属性可以强行让 Activity 在当前任务不再显示时归属于另一个与其 affinity 相同的任务。 典型应用是让一个应用程序的 Activity 转移到另一个应用程序关联的主任务中去。
　
　例如，如果某条 e-mail 信息包含了一个 Web 页的链接，点击此链接将启动一个 Activity 显示此 Web 页。 这个 Activity 是由浏览器程序定义的，但却作为 e-mail 任务的一部分被启动。 如果它重新归属于浏览器的任务，那么在下次浏览器进入前台时就会显示出来，并且会在 e-mail 任务再次回到前台时消失。
　
　Activity 的 affinity 由 taskAffinity 属性定义。 任务的 affinity 由根 Activity 的 affinity 确定。 然而，根据规定，根 Activity 总是位于 affinity 同名的任务中。 因为以“singleTask”和“singleInstance” 模式启动的 Activity 只能位于任务的根部， 所以 Activity 的重新归属仅限于“standard”和“singleTop”启动模式。 （请参阅 launchMode 属性。）

经典理解：

　就是说，一个activity1原来属于task1，但是如果task2启动起来的话，activity1可能不再属于task1了，转而投奔task2去了。
当然前提条件是allowTaskReparenting，还有affinity设置

有点像，你捡到一条狗，在家里喂养几天觉得不错，当自己家的了；但是突然有一天他的主人找上门来了，小狗还是乖乖和主人走了。。。

用法

　是否允许activity更换从属的任务，比如从短信息任务 切换到浏览器任务。

　用来标记Activity能否从启动的Task移动到有着affinity的Task（当这个Task进入到前台时）——“true”，表示能移动，“false”，表示它必须呆在启动时呆在的那个Task里。

　如果这个特性没有被设定，设定到元素上的allowTaskReparenting特性的值会应用到Activity上。默认值为“false”。

　一般来说，当Activity启动后，它就与启动它的Task关联，并且在那里耗尽它的整个生命周期。当当前的Task不再显示时，你可以使用这个特性来强制Activity移动到有着affinity的Task中。典型用法是：把一个应用程序的Activity移到另一个应用程序的主Task中。
　
　例如，如果e－mail中包含一个web页的链接，点击它就会启动一个Activity来显示这个页面。这个Activity是由Browser应用程序定义的，但是，现在它作为e－mail Task的一部分。如果它重新宿主到Browser Task里，当Browser下一次进入到前台时，它就能被看见，并且，当e－mail Task再次进入前台时，就看不到它了。
　
　Actvity的affinity是由taskAffinity特性定义的。Task的affinity是通过读取根Activity的affinity 决定。因此，根据定义，根Activity总是位于相同affinity的Task里。由于启动模式为“singleTask”和 “singleInstance”的Activity只能位于Task的底部，因此，重新宿主只能限于“standard”和“singleTop”模式。

taskAffinity属性

Affinity：密切关系，姻亲关系; （男女之间的） 吸引力，吸引人的异性; 类同; 类似，近似;

He has a close affinity with the landscape he knew when he was growing
up 他对这片从小就了解的土地有着一种归属感。

android:taskAffinity

　带有 affinity 的 Activity 所处的任务。 拥有相同 affinity 的 Activity 在概念上属于同一个任务（从用户的角度来看被视为同一个应用程序）。 任务的 affinity 取决于其根 Activity 的 affinity。

　affinity决定两件事情 — Activity 要重新归属于的任务（参阅 allowTaskReparenting 属性）和通过 FLAG_ACTIVITY_NEW_TASK 标志启动的 Activity 所处的任务。

　默认情况下，同一个应用程序中的所有 Activity 都拥有相同的 affinity。 通过设置本属性，可以把 Activity 分为不同的组，甚至可以把不同应用程序的 Activity 放入同一个任务里。 要把 Activity 设置为不带 affinity ，也即不属于任何任务，只要将本属性设为空字符串即可。

　如果未设置本属性，那么 Activity 将会继承应用程序的 affinity 设置（请参阅 < application > 元素的 taskAffinity 属性）。应用程序默认的 affinity 名称是由 < manifest > 元素设置的包名称。

　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并入栈。

singleInstance下防止返回没有完全退出

　这个模式非常接近于singleTask，系统中只允许一个Activity的实例存在。区别在于持有这个Activity的任务中只能有一个Activity：即这个单例本身。如果从这种活动中调用另一个活动，将自动创建一个新任务来放置该新的活动。 同样，如果调用了singleInstance Activity，将创建新的Task来放置Activity。

　不过结果却很怪异，从dumpsys提供的信息来看，似乎系统中有两个任务但任务管理器中只显示一个,即最后被移到顶部的那个。导致虽然后台有一个任务在运行，我们却无法切换回去，这一点也不科学。

　本来有两个任务，但是任务管理器中却只显示一个任务：

　由于此任务只能有一个活动，所以我们无法再切换回任务＃1。 只有这样做的方法是重新启动应用程序从启动器，但似乎单个任务将隐藏在背景中。

　因为这个任务只有一个Activity，我们再也无法切回到任务#1了。唯一的办法是重新在launcher中启动这个应用。 but之后的没有翻译，因为我也不明白作者的意思。

　不过这个问题也有解决方案，就像我们在singleTask Acvity中做的，只要为singleInstance Activity设置taskAffinity属性就可以了。

<activity
            android:name=".SingleInstanceActivity"
            android:label="singleInstance launchMode"
            android:launchMode="singleInstance"
            android:taskAffinity="">

　现在科学多了。

　这种模式很少被使用。实际使用的案例如Launcher的Activity或者100%确定只有一个Activity的应用。总之除非完全有必要，不然我不建议使用这种模式。

Android退出整个应用解决方案

1、利用SingTask

　将主Activity设为SingTask模式，然后在要退出的Activity中转到主Activity，然后重写主Activity的onNewIntent函数，并在函数中加上一句finish

2、利用历史栈和SingleTop

　我们知道Android的窗口类提供了历史栈，我们可以通过stack的原理来巧妙的实现，这里我们在D窗口打开A窗口时在Intent中直接加入标志Intent.FLAG_ACTIVITY_CLEAR_TOP，再次开启A时将会清除该进程空间的所有Activity。

　在D中使用下面的代码:
　

Intent intent = new Intent(); intent.setClass(D.this, A.class); intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);  //注意本行的FLAG设置 
startActivity(intent); finish();关掉自己 

　在A中加入代码：

Override

protected void onNewIntent(Intent intent) { // TODO Auto-generated method stub

super.onNewIntent(intent);

//退出

        if ((Intent.FLAG_ACTIVITY_CLEAR_TOP & intent.getFlags()) != 0) {

               finish();

        }

}

　A的Manifest.xml配置成

android:launchMode="singleTop"

　原理总结： 一般A是程序的入口点，从D起一个A的activity，加入标识Intent.FLAG_ACTIVITY_CLEAR_TOP这个过程中会把栈中B，C，都清理掉。因为A是android:launchMode=”singleTop” 不会调用oncreate(),而是响应onNewIntent（）这时候判断Intent.FLAG_ACTIVITY_CLEAR_TOP，然后把A finish（）掉。 栈中A,B,C,D全部被清理。所以整个程序退出了。

3、通过广播来完成退出功能

　具体实现过程是这样的：在每个Activity创建时（onCreate时）给Activity注册一个广播接收器，当退出时发送该广播即可。大概的代码如下：

@Override

protected void onCreate(Bundle savedInstanceState) {

       super.onCreate(savedInstanceState);

       IntentFilter filter = new IntentFilter();

       filter.addAction("finish");

       registerReceiver(mFinishReceiver, filter);

       ……

}

private BroadcastReceiver mFinishReceiver = new BroadcastReceiver() {

    @Override

    public void onReceive(Context context, Intent intent) {

           if("finish".equals(intent.getAction())) {

              Log.e("#########", "I am " + getLocalClassName()

                     + ",now finishing myself...");

              finish();

       }

    }

};

　相信聪明的大家会把上面的代码写在一个基类里面，因为如果你的项目中Activity很多的话，写起来很麻烦，而且也不符合代码规范。

　在退出时执行以下代码即可关闭所有界面完全退出程序：

getApplicationContext().sendBroadcast(new Intent("finish"));

4、使用退出类

　现下最流行的方式是定义一个栈，写一个自定义的MyApplication类，利用单例模式去单独对Activity进行管理，在每个Activity的onCreate()方法中调用MyApplication.getInstance().addActivity(this)将当前的Activity添加到栈中统一管理，如果需要退出应用程序时再调用MyApplication.getInstance().exit()方法直接就完全退出了应用程序。
　
　实现方案：统一管理的好处就是如果需要退出时，直接将add进栈的Activity进行同意finish就行。exit方法的实现原理就是将栈中所有的Activity实例循环然后finish的。
　
方式1：

public class CloseActivity
{
    private static LinkedList<Activity> acys = new LinkedList<Activity>();

    public static Activity curActivity;

    public static void add(Activity acy)
    {
        acys.add(acy);
    }

    public static void remove(Activity acy) {
        acys.remove(acy);
    }

    public static void close()
    {
        Activity acy;
        while (acys.size() != 0)
        {
            acy = acys.poll();
            if (!acy.isFinishing())
            {
                acy.finish();
            }
        }
//        android.os.Process.killProcess(android.os.Process.myPid());
    }
}

方式2：

　将下面SysApplication这个类复制到工程里面，然后在每个Acitivity的oncreate方法里面通过SysApplication.getInstance().addActivity(this); 添加当前Acitivity到ancivitylist里面去，最后在想退出的时候调用SysApplication.getInstance().exit();可直接关闭所有的Acitivity并退出应用程序。

附代码：

import java.util.LinkedList; 
import java.util.List; 
import android.app.Activity; 
import android.app.AlertDialog; 
import android.app.Application; 
import android.content.DialogInterface; 
import android.content.Intent; 

public class SysApplication extends Application { 
    private List<Activity> mList = new LinkedList<Activity>(); 
    private static SysApplication instance; 

    private SysApplication() {   
    } 
    public synchronized static SysApplication getInstance() { 
        if (null == instance) { 
            instance = new SysApplication(); 
        } 
        return instance; 
    } 
    // add Activity  
    public void addActivity(Activity activity) { 
        mList.add(activity); 
    } 

    public void exit() { 
        try { 
            for (Activity activity : mList) { 
                if (activity != null) 
                    activity.finish(); 
            } 
        } catch (Exception e) { 
            e.printStackTrace(); 
        } finally { 
            System.exit(0); 
        } 
    } 
    public void onLowMemory() { 
        super.onLowMemory();     
        System.gc(); 
    }  
}

　在应用程序里面 的activity的oncreate里面添加SysApplication.getInstance().addActivity(this)
　如：

public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
SysApplication.getInstance().addActivity(this); 
}

　总结：在程序内维护一个activity list，在响应应用程序退出的时候，遍历该list，调用每一个Activity的finish()方法，然

Android.os.Process.killProcess(android.os.Process.myPid())  

　或者

System.exit(0)  

　即可完全退出程序（进程也同时被杀死）。
　
　使用ActivityLifecycleCallbacks优化：
　
我一行代码都不写实现Toolbar!你却还在封装BaseActivity?

ActivityLifecycleCallbacks
这个接口有什么用呢?

Application 提供有一个 registerActivityLifecycleCallbacks() 的方法,需要传入的参数就是这个
ActivityLifecycleCallbacks 接口,作用和你猜的没错,就是在你调用这个方法传入这个接口实现类后,系统会在每个
Activity 执行完对应的生命周期后都调用这个实现类中对应的方法,请记住是每个!

这个时候我们就会想到一个需求实现,关闭所有 Activity !你还在通过继承 BaseActivity 在 BaseActivity 的
onCreate 中将这个 Activity 加入集合???

那我现在就告诉你这样的弊端,如果你 App 中打开有其他三方库的 Activity ,这个三方库肯定不可能继承你的 BaseActivity
,这时你怎么办?怎么办？

这时 ActivityLifecycleCallbacks 就派上用场了, App 中的所有 Activity
只要执行完生命周期就一定会调用这个接口实现类的对应方法, 那你就可以在 onActivityCreated 中将所有 Activity
加入集合,这样不管你是不是三方库的 Activity 我都可以遍历集合 finish 所有的 Activity

参考

• 任务、进程和线程

• Activity的LaunchMode和taskAffinity

• Android开发-API指南-[原创译文]

• android的taskAffinity和allowTaskReparenting的用途

• taskAffinity属性

• Activity启动模式图文详解：standard, singleTop, singleTask 以及 singleInstance

• 我一行代码都不写实现Toolbar!你却还在封装BaseActivity?