接手过一个老项目测试提了一个非常经典的bug从通知栏点进“订单详情”连续点十次返回键要按十次才能回到桌面有时候从订单详情按返回居然跳到了首页漏掉了中间一系列页面。当时第一反应是哪里把launchMode写错了结果翻代码发现订单详情页在Manifest里根本没写launchMode默认standard通知栏每次点击都在堆实例。这个bug让我把Activity启动模式从头到尾梳理了一遍发现大多数人——包括当时的我——对启动模式的理解都停留在“四种模式分别叫什么”的层面一旦涉及Intent Flag、taskAffinity、外部拉起、onNewIntent整个行为就开始失控。这篇文章把我整理的完整思路写出来适合那些对启动模式有基础认知但想彻底搞懂“什么场景该用什么模式、为什么”的Android开发。不管你是刚入职的新人、还在准备面试还是维护老项目的同学启动模式相关的Bug早晚都会来找你。我会先从任务栈讲起把基础补上然后逐个模式拆解再穿插Flag和taskAffinity这些运行时变量最后给你一套用adb验证和线上选型的实操方法。1. 先看懂返回栈才知道四种launchMode在调什么Activity的启动模式本质上就是在定义“一个Activity实例放进任务栈时是新建、复用还是清理”。所以不理解任务栈四种模式的名字背得再熟也只是名词堆砌。1.1 任务栈Task是什么Android系统把一组按顺序打开的Activity放进一个后进先出的栈里这个栈就叫Task。每次startActivity新页面就被压到栈顶每按一次返回键栈顶Activity出栈并销毁。这样讲比较抽象你可以把Task想象成一摞盘子startActivity是把一个新盘子放到最上面finish是按返回键拿走最上面的盘子。这里有两个特别容易被误解的点必须先说清楚。第一Task和进程不是一回事。同一个Task里可以放不同App的Activity同一个App的Activity也可以分布在多个Task里。比如你用系统的URL Scheme打开另一个应用的某个页面那个页面完全可能被放进你自己的Task栈里栈里同时存在两个应用的不同页面这在dumpsys里非常常见。第二按Home键不会清空Task。Task只是被打到后台里面的Activity都还在从桌面图标重新点进App系统会尽量恢复原来的Task而不是每次新建一个。很多“返回栈错乱”的问题根源就在这里——开发者以为按Home键等于销毁了页面于是没有处理再次进入时的去重逻辑。1.2 用一个三页跳转实测观察返回栈变化为了直观感受Task我建了一个测试demo三个页面A、B、C每页一个按钮跳下一页分别在onCreate、onNewIntent、onDestroy里打日志。A - B - C之后执行adb shell dumpsys activity activities输出里找到当前Task部分会看到taskId下面有A、B、C三个ActivityRecord按顺序排列。这时候按返回键C先destroy然后B再A完全符合“栈顶先出”的规则。这个实测很有价值因为很多开发者没亲眼看过多Task长什么样。你再试一下从A跳B然后按Home键回桌面再从桌面图标点进来再次执行dumpsys会发现原来的Task还在里面躺着的还是A和B并没有重新创建一份A。如果这个过程中你从最近任务列表里把App划掉整个Task才会被销毁。下次从图标进入时系统才重新创建Task和根Activity。理解了“用户按Home键只是切后台”这个事实后面讲singleTask和singleInstance时你才能理解为什么“任务栈复用”对某些页面那么重要。2. 四种模式逐个拆解它们各自解决什么问题、又埋了什么坑2.1 standard默认行为也是最容易“栈爆炸”的模式如果不给Activity配置launchMode默认就是standard。特征是每次startActivity都创建一个全新的实例不管栈里是否已经存在相同的页面然后把这个新实例压入当前Task栈顶。standard适合什么场景适合那些“内容天然不同”的页面比如文章详情、商品详情、订单详情。用户可能同时打开了好几篇不同的文章每一篇都应该是一个独立实例按返回键时能一篇一篇地回退。这种情况下standard天然就是最合理的选择。但standard最容易被坑的地方在入口页面。举个例子MainActivity用的是默认standard用户进入App后按Home键挂在后台再从桌面图标点进来由于Launcher启动应用时通常会给Intent加上FLAG_ACTIVITY_NEW_TASK而系统又找不到可以复用的Task就可能直接新建一个Task并重新创建MainActivity实例。最终最近任务列表里出现同一个App的多个任务每个任务里各有一个MainActivity用户切来切去会发现返回栈完全是乱的。我用一个小项目实测过App里只有一个MainActivity不配launchMode进入后按Home再从桌面图标反复进出三次dumpsys里能看到两个甚至三个taskId每个taskId下都有MainActivityRecord。手机厂商的ROM可能还会把MainActivity的affinity和包名绑定导致行为更加隐蔽。我的经验是涉及“App主入口”“首页”“同页面唯一”的页面最好不要用standard裸奔。standard作为一个兜底模式当然没问题但你要清楚它兜底的结果是“每次都是新页面”这往往不是入口页面想要的效果。2.2 singleTop适合通知栏和扫码入口但不是所有“防止重复”场景都该用它singleTop的特性是如果目标Activity已经处于当前Task栈顶则不创建新实例而是直接复用栈顶实例并回调onNewIntent如果目标Activity不在栈顶行为跟standard一样照样创建新实例。这个“只在栈顶复用”的限定条件经常被忽略。我看到很多人给页面配了singleTop以为就能全局防抖结果发现在“列表页 - 详情页 - 再次打开另一个详情页”的场景下详情页依旧被创建了多个实例因为详情页根本不在栈顶它上面压着列表页。singleTop真正适合的是这类场景通知栏不断推送同一条消息用户点进推送落地页或者扫码应用连续扫出同一个结果页。落地页刚好在栈顶时点击通知栏只是把新Intent交给当前页面刷新而不会在栈顶再叠一层。注意singleTop页面复用时会走onNewIntent而不是onCreate。如果你在singleTop页面里依赖onCreate重新拉取数据会发现第二次从通知栏进入时页面数据没有刷新因为onCreate根本没被再次调用。这个坑我在后面“onNewIntent的正确姿势”里专门展开。2.3 singleTask最常用的复用模式但它的清栈行为经常把开发者吓一跳singleTask的逻辑比singleTop复杂它分三步走系统按目标Activity的taskAffinity寻找对应的Task如果没有找到就新建一个Task并把这个Activity作为根Activity压入。如果找到了Task并且Task里已经有该Activity的实例就把这个实例之上的所有Activity全部出栈销毁默认行为。复用该实例回调onNewIntent。这个“把上面的Activity全部出栈”就是清栈行为也是最容易出问题的地方。举个例子页面栈是“首页 - 列表 - 详情 - 支付 - 支付成功页”支付成功页配置singleTask。如果用户从详情页再次发起支付并成功此时详情页把支付成功页又启动了一次系统发现支付成功页已经在栈里就会把它上面的所有Activity全部清掉。最终返回栈变成“首页 - 支付成功页”列表和详情没了。用户按返回键直接回首页甚至退出App感觉就像“跳过了一大段历史”。这不能怪系统是singleTask的工作机制就是这样。所以singleTask的使用场景必须很克制。它适合那些“希望始终作为Task的根节点”的页面比如App主页或者那些“进入后就不希望用户返回到来路”的页面比如收银台支付完成后不希望返回去修改商品。你要清楚设置singleTask等于跟系统说把这个页面变成整个栈的锚点它上面的历史都可以不要。另外还有一个小坑singleTask并不保证“系统里只有一个实例”。如果一个Activity设置了singleTask但taskAffinity跟当前Task不匹配系统会在另一个Task里创建一个新实例。这也是很多人被面试题坑的地方。所以讲singleTask必须同时讲taskAffinity这块放到第3节。2.4 singleInstance全局唯一且独立成栈用不对会让整个App体验割裂singleInstance比singleTask更极端拥有该Activity的Task里只允许存在这一个Activity不能有别的Activity压进来。系统一旦创建了这个Activity就会单独开一个Task给它后续再用到它时直接复用这个独立Task里的实例。这种模式典型用于系统级来电页面、闹钟响铃页面、语音通话界面这类“全局唯一、不希望被其他页面干扰”的场景。在普通业务App里我几乎不推荐使用singleInstance。原因很实际它会让最近任务列表里多出一个独立任务项用户从这个页面按返回键返回的是“上一个Task”而不是这个页面之前所在的某个子页面。很多用户会感觉“怎么按返回键跳到别的App了”体验很割裂。另外singleInstance页面的启动和切换往往伴随切换Task的动画视觉上就像在跳App产品经理大概率会问你“为什么这个页面跟整个App不在一个上下文里”。四种模式放到一起对比一张表就能看清模式新实例创建时机已存在实例时的行为是否回调onNewIntent适合场景standard每次启动都新建无复用逻辑否文章详情、商品详情等独立页singleTop目标不在栈顶时新建目标在栈顶则复用是通知栏落地页、扫码结果页singleTask栈中不存在实例时新建按affinity找Task清掉其上Activity并复用是App主框架页、根任务页singleInstance全局不存在实例时新建独立Task复用并切换整个Task是系统来电页、闹钟页等3. taskAffinity和Intent Flag能在运行时改写启动模式的隐藏开关很多人在Manifest里配好launchMode后就以为“这个页面的行为一定是我配的那样”。错了。实际线上绝大部分启动路径Intent上都带了各种Flag而这些Flag在系统判断里的优先级比Manifest里的launchMode更高。3.1 Intent Flag优先级高于Manifest配置先记住这条铁律系统在决定Activity如何启动时会先读Intent携带的Flag再参考Manifest里的launchMode。两者冲突时Flag往往能覆盖掉launchMode的默认行为。只需要把4个Flag记住就足够应对绝大多数场景Flag与launchMode的对应行为说明FLAG_ACTIVITY_NEW_TASK类似singleTask找Task的能力目标Task不存在则新建Task存在且affinity匹配则复用已有TaskFLAG_ACTIVITY_SINGLE_TOP等价singleTop栈顶存在目标Activity时复用否则新建FLAG_ACTIVITY_CLEAR_TOP清栈清掉目标Activity之上的所有Activity若目标Activity本身不在栈底也会被处理FLAG_ACTIVITY_CLEAR_TASK彻底清空启动前先把整个Task所有Activity销毁再创建目标ActivityFLAG_ACTIVITY_CLEAR_TOP是最容易踩坑的一个。比如标准栈“A - B - C”你想回到A并清空B和C最稳妥的写法是Intent intent new Intent(context, A.class); intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP); startActivity(intent);如果只设置FLAG_ACTIVITY_CLEAR_TOP而不加SINGLE_TOP系统会把A之上的B、C销毁同时把A本身也销毁重建。结果是用户明明想“回到已有页面”页面却闪烁一下重新走了onCreate状态全丢。这个反直觉行为我在线上真真切切碰到过最后排查时目瞪口呆。还有一个规则要记牢如果使用ApplicationContext、ServiceContext去startActivity必须给Intent加FLAG_ACTIVITY_NEW_TASK否则会直接抛“Calling startActivity() from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag”。很多推送SDK回调里跳页面崩溃就是这个原因。3.2 taskAffinity决定单例模式去哪里找栈taskAffinity可以理解成Activity的“栈归属倾向”。默认情况下一个App所有Activity的taskAffinity都是包名。singleTask和FLAG_ACTIVITY_NEW_TASK在寻找“已有Task”时依据的就是目标Activity的taskAffinity跟哪个Task的affinity匹配。打个比方Task就像一栋大楼每个Task有自己的门牌号affinity。singleTask要找的不是“哪个Task里有我”而是“哪个Task挂的牌子跟我一致或者里面已经有一个我的实例”。如果匹配不上它不会复用而是去新开一栋楼。跨App互跳时这个坑特别明显。比如你用浏览器打开一个自定义scheme链接浏览器在发出Intent时经常会带上FLAG_ACTIVITY_NEW_TASK如果目标Activity的taskAffinity跟浏览器Task不一致系统就会新建一个Task来放这个Activity。结果就是你从浏览器跳进App的某个页面按返回键直接回到浏览器而不是回到App原本的页面栈。普通业务App尽量不要改taskAffinity。你需要知道这个属性的存在但大概率不会用到它。真到了需要跨模块共享Task、或者希望多个App模块合并到同一个Task时再考虑调整affinity并且一定要在dumpsys里反复验证返回关系。3.3 外部拉起场景里的“意外栈”外部拉起是启动模式问题的高发地带主要是三个方向第一通知栏。很多开发者写PendingIntent时要么忘了加Flag要么盲目复制网上的代码。用户多次点击通知时如果目标页面是standard会在当前Task或新Task里各创建一份实例返回栈越堆越长。正确的做法是给目标页面设计好singleTop或singleTaskIntent的extra用FLAG_UPDATE_CURRENT保证最新数据能传进去。第二URL Scheme。浏览器、微信、扫码App拉起你的页面时和你自己App内startActivity完全不一样。外部进程发来的Intent往往带有各种不确定的Flag有时候还带着跨进程的ComponentName。这个时候你最不能做的就是让“每个业务页”直接暴露给外部。最好用一个专门的路由中转Activity集中接收外部Intent解析后再分发到真正的业务页。第三扫码。如果你的落地页是扫码结果页结果页在栈顶连续被扫码唤起时singleTop很合适但如果你希望扫码唤起后清掉之前的中间页面那就需要CLEAR_TOP或singleTask两者效果完全不同要先想清楚交互预期。4. 用adb“透视”任务栈排查启动行为混乱的实操路径前面讲了那么多理论你可能已经头晕了。真正有用的排查手法是把抽象概念落到adb命令上用实测结果倒推启动行为。4.1 dumpsys activity activities怎么读命令很简单adb shell dumpsys activity activities不同Android版本输出格式略有差异但核心去看三个信息就够了当前Resumed的Activity是哪个。一般会有一个topResumedActivity或mResumedActivity字样后面跟着ComponentName。当前有几个Task每个Task的taskId是多少。输出里会有Task{xxx #id typestandard A包名}这个A后面的值就是该Task的affinity。每个Task下面的ActivityRecord列表。通常Activities[...]里按从底到顶的顺序列出了这个Task中的所有Activity。排查启动模式问题时不要上来就盯着一大坨日志。记住一个原则在操作前先dump一次操作后再dump一次对比差异。差异不外乎三种情况多了一个新taskId说明这次启动被放进了新Task。原有taskId下多了一个ActivityRecord说明在既有Task里新增了页面实例。原有taskId下的ActivityRecord数量没变但某个Activity的状态从Hist变成了Resumed说明复用了已有实例。这三个差异足以判断大多数启动行为。4.2 用am start强制指定Flag复现“Manifest被覆盖”的场景光看不开不行还要能模拟。adb支持用命令行直接启动特定Activity并传Flagadb shell am start -n com.example.app/.DetailActivity --activity-single-top --activity-clear-top --activity-new-task这条命令等价于代码里给Intent设置FLAG_ACTIVITY_SINGLE_TOP、FLAG_ACTIVITY_CLEAR_TOP、FLAG_ACTIVITY_NEW_TASK。通过替换参数你可以快速验证“如果外部这样拉起页面的返回栈会变成什么样”。还可以加-W参数查看启动耗时adb shell am start -W -n com.example.app/.MainActivity有个小提醒你在网上搜“chrome如何调试模式启动”时搜出来的是Chrome浏览器的启动参数调试方法跟Android am start不是一回事。要复现浏览器通过scheme拉起App的场景用的是adb shell am start -a android.intent.action.VIEW -d yourApp://page/detail?id100 --activity-new-task4.3 用adb定位一个单例模式Bug的完整链路我拿一个实际Bug复盘整个排查过程。现象用户从桌面图标进入App后再跳到B页面按Home再从图标进入发现回到了B页面但按返回键却要按很多次。第一步B页面在Manifest里配置的是singleTask。我先执行adb shell dumpsys activity activities发现有两个taskId其中一个taskId里是MainActivity另一个taskId里是B页面。问题定位到一半B页面没有和MainActivity待在同一个Task里。第二步检查B页面的taskAffinity发现有人把它改成了com.example.other和App默认包名不一致。singleTask找Task时按affinity匹配因此它找到了一个新的空任务或别的任务自然就和MainActivity分家了。第三步把taskAffinity改回默认包名重新dump验证两个页面的taskId终于变成了同一个。整个链路就是这样现象 - dump看Task - 发现affinity不匹配 - 修复 - 重新dump确认。这类问题如果靠肉眼看代码很难发现但dumpsys能直接给你答案。5. 启动模式之外的隐藏变量Activity重建与onNewIntent的配合问题有时候用户反馈“页面闪一下表单数据没了”不一定跟launchMode有关系很可能是Activity被系统重建了。这一节把Activity重建的原因和onNewIntent的正确处理方式放一起讲是因为它们经常在同一个Bug里同时出现。5.1 哪些配置会导致Activity重建Activity重建最常见的原因是系统配置Configuration变化。默认情况下以下变化都会让当前Activity先destroy再重新create屏幕旋转系统语言或地区切换深色模式切换字体大小、显示大小调整分屏或屏幕尺寸变化每次重建都会走onSaveInstanceState - onStop - onDestroy - onCreate - onRestoreInstanceState。如果你在页面里持有比较重的运行时状态比如表单输入、视频播放进度、拍照预览重建就很容易造成状态丢失。一个常见的应对方式是在Manifest里配置configChanges告诉系统部分变化不需要销毁重建activity android:name.PlayerActivity android:configChangesorientation|screenSize|uiMode|fontScale|density /这样配置后产生这些变化时Activity不会重建而是回调onConfigurationChanged。但注意这不等于“永久解决问题”多窗口、分屏场景下有些尺寸变化不会被完整覆盖。所以我更建议重要状态用onSaveInstanceState保存稳定数据用ViewModel持有而configChanges只在特定场景比如视频播放、拍照里作为兜底。另外进程被系统回收后用户重新回到页面也会触发Activity重建。这时候重建走的是“状态恢复”路径如果你没有处理好onSaveInstanceState页面就真的“什么都没了”。5.2 onNewIntent的正确姿势当singleTop栈顶复用、singleTask和singleInstance复用已有实例时系统不会调用onCreate而是调用onNewIntent。这时候最容易犯的错是只处理onCreate里的Intent没处理onNewIntent里的Intent导致第二次带参数进入时页面不刷新。正确做法有两个核心点。第一一定要setIntent。override fun onNewIntent(intent: Intent?) { super.onNewIntent(intent) setIntent(intent) handleIntent(intent, isNew false) }不调setIntent的话后续调用getIntent()取到的还是旧的Intent页面只能拿到第一次的extra排查时很难发现。第二onCreate和onNewIntent要共用同一个处理入口。override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) handleIntent(intent, isNew true) }这样无论页面是被创建还是被复用Intent里的参数都能被处理到不会出现“第一次进有数据第二次进数据还是老的”的诡异现象。还有一个很容易被忽略的细节如果用户用某个singleTask页面系统发现实例存在但进程已经被杀掉这次进入会先重建整个Activity走onCreate而不是onNewIntent。所以不能在onNewIntent里假设“onCreate一定已经执行过某些成员变量一定还在”。谨慎的做法是在handleIntent里对关键资源做空判断或者把关键数据放到ViewModel里。5.3 被CLEAR_TOP“坑到重建”的经典场景前面讲过FLAG_ACTIVITY_CLEAR_TOP不搭配FLAG_ACTIVITY_SINGLE_TOP时即使目标Activity已在栈中也会被销毁重建。这导致的直接结果是用户点“回到上一页”看到的却是页面重新加载表单数据全丢。如果你确实希望“回退到已有页面并保留状态”一定要把SINGLE_TOP加上如果你希望“到达目标页时强制刷新数据”那反而可以利用这种重建行为。关键在于想清楚交互预期再选方案不要模棱两可。6. 项目实战选型把启动模式落实到功能页面而不是停留在学理6.1 常见功能页面的启动模式选择参考表每接到一个页面先给页面定性它是根节点、跳转中间页、还是落地页。然后按这个表来选页面类型推荐模式理由App首页/MainActivitysingleTask或standard手动去重配合桌面图标NewTask行为避免多Task多实例登录页standard登录页通常需要保留来源页singleTask清栈会把来路断掉文章/商品/订单详情standard每次打开的内容不同需要独立实例支付/收银台standard支付页需要保留完整返回链不希望在支付中途被清栈WebView容器standard每个WebView页独立返回栈要保留来源推送/扫码落地页singleTask或singleTop需要复用并处理新Intent根据页面是否常见于栈中决定系统级提醒/通话浮层singleInstance全局唯一且独立栈业务App不要轻易用这里有个高频问题“要不要给所有页面都加singleTop来防重复”不要。详情类页面天然允许开多个实例加了singleTop之后栈里会出现“同一个类但不是同一个实例”的多个页面反而更难处理。singleTop只解决“栈顶重复”的问题不解决“全局唯一”的问题。6.2 落地方案通知栏、扫码和URL Scheme通知栏落地页推荐用singleTask。每次点通知栏都复用同一个Activity实例配合PendingIntent的FLAG_UPDATE_CURRENT能保证extra里的数据是最新的。注意targetSdk 31以上PendingIntent需要显式指定FLAG_IMMUTABLE或FLAG_MUTABLE否则运行时直接崩溃。扫码结果页推荐用singleTop前提是结果页大概率位于栈顶。用户连续扫两个码后一个扫码会触发前一个结果页的onNewIntent页面刷新成新的内容。如果业务上要求“扫码后回到结果页时清掉中间页面”那就得用singleTask或者显式加CLEAR_TOP。URL Scheme入口我强烈建议收敛到一个RouterActivity。不要每个业务页都对外配scheme而是让RouterActivity统一接收外部Intent解析后再跳真正的业务页。RouterActivity设成singleTask处理完立刻finish这样外部无论带什么奇怪的Flag内部栈始终只有一条清晰路径。6.3 我踩过的一个真实坑收银台的singleTask事故有个项目里页面栈原本是“首页 - 详情 - WebView - 收银台”。收银台这个页面产品经理要求“同一时间只能出现一个”于是同事把收银台配成了singleTask。上线后用户反馈从收银台按返回键直接回到首页中间的WebView和详情全被清掉了用户想回WebView再看一眼商品说明都不行。排查后发现收银台作为singleTask进入时它上方的WebView和详情确实会被系统清栈这是设计如此不是bug。后来我们改成standard在业务代码里控制收银台的finish时机来解决“同时只能存在一个”的问题。这个坑给我的启发是singleTask的真正适用面是“根节点”不是“唯一节点”。想控制页面唯一用单例路由或在页面内自行去重都可以不一定要靠模式硬解。我更愿意把启动模式理解为“栈上页面的调度策略”而不是四行配置项。遇到任何返回栈异常不要先急着改launchMode先用dumpsys看一眼Task再确认是谁发起的启动、带了哪些Flag最后再决定是改Manifest、改Intent还是改路由。曾经有段时间我把每个需要去重的页面都收进了统一的路由层在入口集中处理去重和Intent效果反而比硬调launchMode靠谱得多。如果项目里还没有统一路由层建议至少把外部入口通知栏、URL Scheme、推送收敛到一个中转Activity再谈launchMode怎么配。