标签：
今天想来说说Android的启动模式。首先来看一个实际的业务场景。我之前在公司实习的时候，我所在的部门只负责一个品类（国际机票），那用户从机票首页开始搜索机票到最终完成订单并支付大致分为以下几个流程（实际流程因为考虑的问题比较多，所以要比这稍微复杂些）：
1. 用户在机票首页确认好出发、到达目的地、日期及人数后，就可以点击“搜索”进入到搜索结果页
2. 用户根据意愿选择相应航班并点击进入确认订单页
3. 用户确认好订单内容点击下单，开始支付，支付完成跳支付完成页
4. 用户可以选择回到首页，或者去公共订单系统查看订单详情（这属于公共部分，不在我们讨论的范围内了）
经过上面4个步骤整个购票流程就算结束了。但是，这里有个问题，就是用户从首页到最后的支付完成页之间经历了这么多的Activity，那用户完成了支付后想回到首页是不是要一层一层的往回退才行？如果是这样的话，那就太不人性化了，那怎样才能在完成支付后一键回到首页呢？有人可能会说，那就直接从支付完成页跳转到首页不就可以了吗？这样当然是可以的，但是这样做那之前打开的那么多Activity怎么办呢？难道就让它们待在Activity任务栈中吗？这样岂不是太浪费内存了！请看我画的示意图：
如上图所示，如果我们在支付完成之后启动首页Activity那页面1-页面5之间的所有Activity对用户来说都是无用的，并且占用的内存，极大地浪费这本来可能就很紧张的Android内存资源。那有没有一些优雅的方式来解决这个问题呢？ 我们可以想象一下，有没有可能在从页面4跳转首页的时候把原来处于首页之上的所有Activity全部干掉呢？这样不就刚好解决了我们刚刚所说浪费资源的问题了吗？就像下图一样：
很显然，无论从用户体验的角度还是从内存优化的角度来看第二种方式都是最为优雅的。那怎么实现这种需求呢？有人可能会说，可以将任务栈中页面1之上的所有Activity一层一层地执行finish()方法销毁掉，这样就可以回退到页面1。这样确实是可行的，但是有个问题：如果希望从页面4跳转到页面1时传递一些数据回去，比如说订单号、支付完成等信息，还需要在finish()执行前执行setResult(int resultCode, Intent intent)将要往回传递的数据放在Intent里面，这样做其实是有风险的，因为Android系统并不保证Activity任务栈中那些不可见的Activity的状态是一直被保存着的，如果出现系统内存不足的情况，Android系统是可以回收那些处于不可见状态的Activity的。也就是说，一旦中间有一Activity被销毁了，那这个传递链就失去功效了。那应该怎么办呢？别着急，Google的Android工程师早就已经为我们想到这种需求了。那应该怎么做呢？其实就是通过设置Activity的启动模式来实现。好，问题抛出了，下面让我们一步一步来看。
Activity一共有4中启动模式，分别是：
下面我来分别做介绍。
顾名思义，Standard英文意思就是“标准的”。
也就是说这种启动模式是默认的，我们平时在开发中使用最多的就是Standard模式的。
如果一个Activity的启动模式被设置成Standard，那么它可以无限制的创建。你每一次通过Intent去启动这种模式的Activity都会重新创建一个。大家可以想象一下邮箱里的收件箱（假设我们将打开邮件的Activity的启动模式设置为Standard，当然这也是默认的模式）里有10封邮件。我们给查看邮件的Activity起名为CheckEmailActivity,我点击第一封邮件将会打开一个CheckEmailActivity，当我看完之后点击下一封邮件，另一个CheckEmailActivity又会被创建，这样如果我们将10封邮件全部看完，那在Activity任务栈中将会有10个CheckEmailActivity，而且如果我想回到收件箱页面还必须点10次返回键！想想是不是很可怕？所以说Standard模式虽然很常用，但也不是适用于任何场合。
另外说一点，Standard模式在Android 5.0（Lollipop）之前和之后是有区别的。
Standard模式的Activity总是会被创建在启动它的Activity同一个任务栈中顶端（任务栈是一个栈结构，先进后出 First In Last Out），就算他们来自不同的应用。
想象一个场景，如果你在A应用中要分享一个本地图片，这样会打开系统的图片查看应用中的图片选择器Activity，虽然这两个Activity来自不同的应用，但Android系统仍将会把他们放在同一个任务栈中，即A应用的任务栈中。
Android Lollipop之后
如果将要启动的Activity和启动它的Activity来自同一个应用，那没话说，和Lollipop之前一样，新的Activity会被创建在当前任务栈中的顶端。
但是如果它们来自不同的应用，那就会创建一个新的任务栈，再把要启动的Activity放在新的任务栈中，这时这个新启动的Activity就是新创建的任务站点的根Activity。如下图所示：
顾名思义，SingleTop的意思就是“在顶部只能有一个”。
这种启动模式非常类似于Standard，但是也有一些区别：
如果在启动这种模式的Activity的时候，当前任务栈的顶端已经存在了相同的Activity，那系统就不会再创建新的，而是回调任务栈中已经存在的该Activity的onNewIntent()方法。请看下面的示意图：
也正因为SingleTop启动模式的特殊性，所以在开发时，如果指定了一个Activity的启动模式是SingleTop的那就应该既要重写onCreated()方法用于应对第一次创建的情况，也要重写onNewIntent()方法来应对重复创建的情况。其实大家可以想象一下，这种启动模式的应用场景。Android既然提供了这种启动模式，说明肯定有应有场景需要这样的方式。其实最常用的场景就是搜索，比方说我们在搜索框中输入想要搜索的内容点击搜索进入SearchResultActivty(搜索结果页)查看搜索的结果（一般我们也会在搜索结果页提供搜索框，这样用户无需点击返回键回到上一个页面再在搜索框中输入搜索内容点击搜索），如果此时用户还想搜点别的东西，就可以直接在当前的搜索结果页SearchResultActivty中的搜索框输入搜索内容继续搜索。大家想象一下，如果我们把SearchResultActivty的启动模式设置为Standard的话会是什么样的景象。比如我们连着搜了10个内容，那就会启动10个不同的SearchResultActivty，然而这些SearchResultActivty功能完全一样，完全没有必要创建这么多，而且还有一个和上一节中的邮箱一样的问题，就是用户搜索结束想回到首页，那就还得按10次返回键才能回到首页，- -！这时，SingleTop启动模式就派上用场了，我们首先把SearchResultActivty的启动模式设置为SingleTop，这样用户在SearchResultActivty页面中继续搜索的时候，我们只需把用户要搜索的内容放在Intent里面然后启动SearchResultActivty，这时系统并不会重新创建新的SearchResultActivty，而是回调当前任务栈栈顶的SearchResultActivty的onNewIntent()方法来接收带有用户搜索内容信息的Intent，然后我们拿到用户搜索内容后调搜索接口，并根据接口返回内容重新刷新布局即可，似不似很神奇？其实我们在上一节提到的邮箱的问题，也是用这种方式来解决的，原理和搜索一样的。
今天有点累了，明天接着写吧。。。 哈哈
参考文献：https://inthecheesefactory.com/blog/understand-android-activity-launchmode/en
标签：
原文地址：http://www.cnblogs.com/jimmyoung/p/5774146.html
