Android的开发水平那是杠杠的。有一次想跳槽，面试一家公司时就被问了Activity启动模式的问题，微胖的面试官问我怎么看待四种启动模式，我吧嗒吧嗒后，面试官接着问我Launcher这个应用的Home界面（一般是指Launcher.java）用的是哪种模试。
我自信的回答用singleInstance，要不是面试官早有准备，估计他都要被我的自信弄得要开始怀疑人生。我的相法很简单，认为它全局只有一个实例而且应该只有一个实例，用singleInstance最好。
当我回来查询Launcher的源代码时发现使用的是SingleTask模式。之后虽然拿到了offer，但我仍然为这个问题耿耿于怀。当我后来到MTK公司工作时，才对Android的四种模式有了更深入的理解。
面试题：Activity的启动模式（launchMode）有哪些，有什么区别？
这应该是一道很虐人的面试题，很多人都答不上来，很多人根本就没有用过。当我发现在被我面试的人中有80%的比例对它不了解时，我找过一些同事讨论是否还有在面试中考查这个问题的必要，得到的回答是“程序员何苦为难程序员”！
因为很多程序员都认为这个启动模式没有多大用处。好吧，我用一个实际中很容易遇到的问题来引出它有多么有用。
很多人在使用startActivityForResult启动一个Activity时，会发现还没有开始界面跳转本身的onActivityResult马上就被执行了，这是为什么呢？
遇到过吧，我见过很多人为了这个问题抓耳挠腮的。在Activity.java的startActivityForResult方法上看一下官方的说明吧：
* <p>Note that this method should only be used with Intent protocols
* that are defined to return a result. In other protocols (such as
* {@link Intent#ACTION_MAIN} or {@link Intent#ACTION_VIEW}), you may
* not get the result when you expect. For example, if the activity you
* are launching uses the singleTask launch mode, it will not run in your
* task and thus you will immediately receive a cancel result.
很多人出现这个问题，确实是因为startActivityForResult启动的Activity设置了singleTask的启动模式。但是，除了这种情况还有可能会马上执行吗？
有，而且很多。如下面表格，左边第1列代表MainActivity的启动模式，第一行代表SecondActivity（即要startActivityForResult启动的Activity）的启动模式，打叉代表在这种组合下onActivityResult会被马上调用。
standsingleTopsingleTasksingleInstance
stand√√xx
singleTop√√xx
singleTask√√xx
singleInstancexxxx
好在幸运的是，Android在5.0及以后的版本修改了这个限制。也就是说上面x的地方全部变成了√。
那么在Android 5.0后，还会有这个问题吗？
还是会的。如在Intent中设置了FLAG_ACTIVITY_NEW_TASK再startActivityForResult，即使是标准的启动模式仍然会有这个问题。
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
Log如下：
07-12 14:21:14.849 20774-20774/net.goeasyway.test I/MainActivity: onCreate
07-12 14:21:14.875 20774-20774/net.goeasyway.test I/MainActivity: onResume
07-12 14:21:19.995 20774-20774/net.goeasyway.test I/MainActivity: onPause
07-12 14:21:19.995 20774-20774/net.goeasyway.test I/MainActivity: onActivityResult requestCode=1 resultCode=0
07-12 14:21:19.996 20774-20774/net.goeasyway.test I/MainActivity: onResume
07-12 14:21:19.996 20774-20774/net.goeasyway.test I/MainActivity: onPause
07-12 14:21:20.005 20774-20774/net.goeasyway.test I/SecondActivity: onCreate
07-12 14:21:20.018 20774-20774/net.goeasyway.test I/SecondActivity: onResume
注意：MainActivity的onResume也会被触发。因为onActivityResult被执行时，它会重新获得焦点。很多人也会遇到onResume被无故调用，也许就是这种情况。
所以，最终我们发现只要是不和原来的Activity在同一个Task就会产生这种立即执行onActivityResult的情况，从原代码也可以得到验证，详情查看ActivityStackSupervisor.java(http://androidxref.com/6.0.1_r10/xref/frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java#1882)。
if (r.resultTo != null && (launchFlags & Intent.FLAG_ACTIVITY_NEW_TASK) != 0
&& r.resultTo.task.stack != null) {
// For whatever reason this activity is being launched into a new
// task... yet the caller has requested a result back. Well, that
// is pretty messed up, so instead immediately send back a cancel
// and let the new task continue launched as normal without a
// dependency on its originator.
Slog.w(TAG, "Activity is launching as a new task, so cancelling activity result.");
r.resultTo.task.stack.sendActivityResultLocked(-1,
r.resultTo, r.resultWho, r.requestCode,
Activity.RESULT_CANCELED, null);
r.resultTo = null;
}
原因
其实上面代码中的英文注解也说得很清楚了，Android认为不同的Task之间对这种要求返回结果的启动方式会产生一些依赖（对Task），所以干脆简单粗暴在跳转前直接返回RESULT_CANCELED结果。
我们还是用一个例子简单解释一下，如下图，有两个任务栈（stack），处于前可视状态的是“Back Stack”也叫返回栈，处理后台的是“Background Task”。
当“Activity 2”通过startActivityForResult启动“Activity Y”时，“Background Task”中的Activity会被压入返回栈的栈顶。这种情况下，如果没有在跳转前直接返回RESULT_CANCELED给“Activity 2”，那么按Back键，应该要跳转到“Activity X”，而按Back键“Activity Y”就会调用finish会发送Result给启动它的“Activity 2”。这时就很难搞清楚，到底是“Activity 2”还是“Activity X”应该获得焦点了，会产生一些混乱或是违反的原有的一些约定。
小结
关于启动模式的问题，其实我开始写这个系统的文章时就想介绍它的，不过发现它的水实现太深了，需要用比较长的篇幅才能说明清楚。今天也只是通过一个实际中容易碰到的问题引起大家的关注，也同时引出了“任务”和“返回栈”。
所以，就让程序员多为难程序员一次，进一步的说明请听下回分解