下文转自https://blog.csdn.net/shangming150/article/details/78343103
今天测试MM偶尔发现了这么个神奇的现象：给测试MM发了个应用安装包，MM安装后打开应用，进入主界面后，点击home键返回了桌面，然后从桌面再点击应用图标再次打开应用，这时候神奇的事情发生了~~~竟然打开了应用的登录界面（MAIN_action的Activity）！这不科学啊，这不是应该之前停留的界面么！~
我自测了一遍，按照测试MM的操作就出现问题，但我自己用adb命令安装后启动app就没有问题！这真吭啊~~ 赶紧分析分析找找解决办法吧~
现象分析：
大致说一下项目结构，MAIN-Activity是登录界面（普通的Activity，启动模式为standard），然后根据一堆初始化操作和判断，一般是接着进入【主页Activity】（Activity的启动模式为singleTask）；点击home键不做任何拦截处理，按照系统默认逻辑返回Lanuch桌面。
也就是说，app的整体交互逻辑并没有特殊之处，并非业务逻辑导致的bug。那么回顾下不同的地方，也就是启动App的入口的区别了，一者是平常的桌面Icon图标启动，一者是安装程序启动入口。我们都知道，桌面启动的话也是通过startActivity这个api通过特定的Intent向ActivityManagerServer发起启动任务；所以我们可以推导出安装程序中的【打开】，也是通过Intent启动对应的App。
再往下分析的话，可能需要一些前置知识需要了解才能更好的理解。
前置知识
1、Activity的Task管理
一般来说，整个Android系统的App启动与切换管理依赖于相关Activity的Task的管理。一个Task之中可能含有若干个Activity，为了简便起见，我们这里记录【Task A】的Activity分别为 【A1】 、【A2】等，【Task B】的Activity分别为 【B1】 、【B2】。
那么我们来分析下App之间是怎么切换的。
假设应用都是单Task应用（相对于大部分的普通App来说，都是采用单一Task来管理的）
桌面程序App：【TaskA】 —- 存在Activity有【A1】 —- 其栈的结构为 A1
应用程序B：【TaskB】 —- 存在Activity有【B1】【B2】 —- 其栈的结构为 B1B2
应用程序C: 【TaskC】 —- 存在Activity有【C1】【C2】 —- 其栈的结构为 C1C2
a、那么我们进入桌面时：Task之间的结构是 A1 —- 也就是只有一个【TaskA】栈（桌面Task），并且位于最前端（这里表现为最后添加的末端）
b、然后我们点击应用程序B的图标，启动B ：Task之间的结构是 A1B1B2 —- 添加了一个【TaskB】，而且【TaskB】也是位于最前端，现在显示的是【TaskB】的B2的Activity的界面
c、接着点击home键： Android对于home做了特殊默认处理，就是会把桌面Task挪到所以Task最前端，Task结构应该变成 B1B2A1 —- 【TaskA】挪到队列最前端，现在显示的是【TaskA】的A1的Activity的界面，也就是桌面
d、我们再在桌面点击应用程序C的图标，启动C : Task之间的结构变成 B1B2A1C1C2 —- 添加了一个【TaskC】，而且【TaskC】也是位于最前端，现在显示的是【TaskC】的C2的Activity的界面
从上面的例子，我们可以大致了解到Android是怎么管理不同app之间切换的逻辑：
我们编写任何一个Activity的时候，都可以在AndroidManifest里面显式指定一个taskAffinity的属性，也就是说该Activity归属于对应taskAffinity的栈；如果没有指定任何taskAffinity，那么该Activity将会直接归属于包名所在的Task之下。而我们启动一个Activity时（这里只讨论standard启动模式），那么回去先搜寻对应的Task是否存在，如果不存在，新建一个Task并将Activity入栈，如果已经存在对应的Task，那么直接在对应Task入栈即可。
那么问题来了：如果我们在上面第d步点击的图片并不是程序C的图标，而是重新点击了程序B的图标，此时【TaskB】是已经存在的了，那么为了不会讲B的入口activity（B1）直接在【TaskB】入栈，而是将【TaskB】挪到前台并不做任何Activity启动的操作呢？
2、桌面的启动管理
回头研究下AndroidManifest这个文件，我们轻而易举发现，但凡是App入口Activity，那么一定会包含
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>这几行代码。这里到底有什么玄机呢？其实这个就是跟桌面约定好的启动拦截过滤器。因为桌面有一个很明显的需求就是，如果我们再次点击已经在后台的App图标时，是应该将该后台任务挪到前台而不是再次启动该App程序。
而从柯元旦所著的《android内核剖析》一书中有记录如下规则：
每次启动Intent导致新创建Task的时候，该Task会记录导致其创建的Intent；而如果后续需要有一个新的与创建Intent完全一致（完全一致定位为：启动类，action、category等等全部一样，不可多项也不可缺少），那么该Intent并不会触发Activity的新建启动，而只会将已经存在的对应Task移到前台；这也就是为什么桌面会在再次点击图标时将后台任务挪到前台而不是重新启动App的实现。
那么为啥要指定入口Activity特定的action和category呢，有一个原因我们可以确定，就是为了让桌面启动app所用的Intent具有特殊性，也就是添加了特别的拦截器，避免其他应用内或者应用间的Intent对于这个启动方式的干扰。
说了这么多，我们可以着手分析上续bug的产生原因了。
原理剖析
从以上的前置知识分析，我们大致得到这样的结论：安装程序直接打开APP，它的启动Intent和我们从桌面启动APP时用到的Intent不一致！
我们将桌面的Task记为【TaskL】，安装程序的Task记为【TaskQ】，我们应用的Task记为【TaskA】，那么分析如下：
进入桌面： L1 —- L1是单纯的桌面
安装程序，进入app安装： L1Q1Q2 —- Q2是安装完毕后询问是否启动对应安装程序的Activity
点击打开： L1Q1Q2A1A2 —- A1是入口登录界面，A2是主页Activity
返回桌面： Q1Q2A1A2L1 —- 回到桌面页，也就是L1前置
点击A的图标： Q1Q2L1A1A2A1 —- 找到【TaskA】，挪到前台；但此时该TaskA判断启动它的Intent和之前启动它的Intent不一致，所以重新启动了一个Activity到TaskA中；
bug出现了!!! 再次启动了登录界面，问题定位成功！
PS：如果主界面的launchMode为singleTask模式，那么在【点击打开】这一步时，task中存在的Activity为：L1Q1Q2A1A2，因为A1会被finish掉！
解决办法
让那些安装程序修正其启动Intent的设置，使其与原声桌面启动Intent保持完全一致。（PS:基本不可能）
自身业务代码规避：如果是多余的入口Activity，其基本不可能位于Task的根部，而正常启动的入口Activity必定在对应的Task的根部。所以我们可以从这个地方对于这个bug进行规避，方法就是在入口Activity的onCreate代码加入如下一段代码：
// 避免从桌面启动程序后，会重新实例化入口类的activity
if (!this.isTaskRoot()) { // 当前类不是该Task的根部，那么之前启动
Intent intent = getIntent();
if (intent != null) {
String action = intent.getAction();
if (intent.hasCategory(Intent.CATEGORY_LAUNCHER) && Intent.ACTION_MAIN.equals(action)) { // 当前类是从桌面启动的
finish(); // finish掉该类，直接打开该Task中现存的Activity
return;
}
}
}