明修"栈"道——越过Android启动栈陷阱( 六 ) _Android

而场景0中，来源Task和目标Task相同， differentTopTask为false ， mMovedToFront保持初始的false 。
由此，我们就能解释【场景0】中， Task不会发生切换的现象。
（5）通过对比flag、Intent、Component等确认是否要将Activity加入到Task中
还是在【场景0123】中， recycleTask()会继续执行complyActivityFlags() ，用来确认是否要将Activity加入到Task中，使用mAddingToTask作为标识。
该方法会对FLAG_ACTIVITY_NEW_TASK、
FLAG_ACTIVITY_CLEAR_TASK、
FLAG_ACTIVITY_CLEAR_TOP等诸多flag、Intent信息进行一系列判断。

文章插图

上图（标注1）中，会先判断后续是否需要重置Task ， resetTask ，判断条件则是FLAG_ACTIVITY_RESET_TASK_IF_NEEDED ，显然，场景0123的resetTask都为false 。继续执行。
接着，会有多种条件判断按顺序执行。
在【场景3】中，目标Component（mactivityComponent）是B-3 ，目标Task的realActivity则是B-2 ，两者不相同，进入了resetTask相关的判断（标注2）。
之前resetTask已经是false ，故【场景3】的mAddingToTask脱离原始值，被置为true 。
在【场景012】中，相对比的两个Activity都是B-2（标注3），可以进入下一级判断——isSameIntentFilter() 。

文章插图

文章插图

这一步判断的内容就很明显了，目标Activity2的已有Intent 与新的Intent做对比。很显然，场景2中由于改为了setClassName跳转， Intent自然不一样了。
故【场景2】的mAddingToTask脱离原始值，被置为true 。
总结看一下：
【场景123】的mMovedToFront最先被置为true ，而【场景0】经历重重考验，保持初始值为false 。
——这意味着当有可复用Task时，【场景0】不需要把Task切换到前列；【场景123】需要切换到目标Task 。
【场景234】的mAddingToTask分别在不同阶段被置为true ，而【场景01】，始终保持初始值false 。
——这意味着，【场景234】需要将Activity加入到Task中，而【场景01】不再需要。
（6）实际启动Activity或直接返回结果
被启动的各个Activity会通过resumeFocusedTasksTopActivities()等一系列操作，开始真正的启动与生命周期的调用。
我们关于上述各个场景的探索已经得到答案，后续流程便不再关注。
四、问题修复及遗留问题解答4.1 问题修复既然前面总结了这么多必要条件，我们只需要破坏其中的某些条件，就可以修复业务中遇到的问题了，简单列举几个的方案。

方案一：修改flag 。B-3跳转B-2时，增加FLAG_ACTIVITY_CLEAR_TASK或FLAG_ACTIVITY_CLEAR_TOP ，或者直接不设置flag 。经验证可行。
方案二：修改intent属性，即【场景2】。A-1通过action方式隐式跳转B-2 ，则B-3可以通过setClassName方式，或修改action内属性的方式跳转B-2 。经验证可行。
方案三：提前移除B-2 。B-2跳转B-3时， finish掉B-2 。需要注意的是， finish()要在startActivity()之前执行，以避免遗留的ActivityRecord和Intent信息对后续跳转的影响。尤其是当你把B-2作为自己应用的deeplink分发Activity时，更值得警惕。

4.2 遗留问题还记得我们在文章开端的某个疑惑吗，为什么没有回调onNewIntent()？
onNewIntent() 会通过deliverNewIntent()触发，而deliverNewIntent()仅通过以下两个方法调用。