Android 的 Activity 启动模式

Android的 Activity 启动模式是应用开发中极为关键的核心机制之一，它直接决定了 Activity 在任务栈中的创建、复用、调度与销毁行为，深刻影响着应用的导航逻辑、内存管理、用户体验以及多任务交互的健壮性。正确理解和运用不同的启动模式，不仅能够优化应用的性能表现，还能解决诸如重复实例化、返回栈混乱、内存泄漏等实际开发问题。本文将从基础概念到高级应用，全面剖析 Android 启动模式的技术原理、应用场景和最佳实践。

一、四种基础启动模式详解

Android 提供了五种主要的启动模式，其中四种为传统模式，第五种是 Android 12 新增的特性。每种模式都有其独特的实例化策略和任务栈管理机制。

1.1 Standard 模式（标准模式）

Standard 模式是系统的默认启动模式 ，当未在 AndroidManifest.xml 中指定 launchMode 属性时，所有 Activity 都会采用这种模式。其核心特征是每次启动 Activity 时都会创建一个新的实例，并将其压入当前任务栈的栈顶

这种模式遵循严格的 "后进先出" 栈结构原则。例如，当 Activity A 启动 Activity B 时，B 会被推送到栈顶并获得焦点，而 A 仍保留在堆栈中并停止运行。当用户按下返回键时，当前 Activity 从堆栈顶部弹出并销毁，之前的 Activity 恢复并显示其界面的前一状态。这种行为确保了导航历史的完整性，用户可以按照打开的顺序依次返回。

在多任务处理方面，Standard 模式表现出最大的灵活性。由于每次启动都会创建新实例，因此同一个 Activity 可以在不同的任务栈中存在多个实例。这种特性使得应用能够同时处理多个独立的任务流程，特别适合需要并行处理不同业务逻辑的场景。例如，在邮件应用中，用户可以同时查看多封邮件，每封邮件都在独立的 Activity 实例中显示。

1.2 SingleTop 模式（栈顶复用模式）

SingleTop 模式采用了栈顶复用机制，这是对 Standard 模式的一种优化。当启动具有 SingleTop 模式的 Activity 时，如果该 Activity 的实例已经存在于当前任务栈的栈顶，则不会创建新实例，而是直接调用其 onNewIntent () 方法复用该实例；如果不在栈顶，则创建新实例并压入栈顶.

这种模式的设计理念是避免在栈顶重复创建相同的 Activity 实例，从而节省系统资源并提高响应速度。举个例子，假设任务栈的返回堆栈由根 Activity A 和 Activity B、C、D 组成（栈结构为 A-B-C-D，D 在顶部），如果 D 具有 SingleTop 启动模式，再次启动 D 时，系统会通过 onNewIntent () 将新的 Intent 传递给 D 的现有实例，而不会创建新的 D 实例，栈结构保持为 A-B-C-D。

SingleTop 模式特别适用于以下场景：

通知栏点击事件处理：当用户点击通知栏跳转到某个已经在栈顶的界面时，可以避免重复创建
搜索结果页面：用户在搜索结果页面进行新的搜索时，可以直接更新现有页面而不创建新实例
新闻详情页：在新闻列表页点击同一新闻多次时，直接复用栈顶的详情页实例

需要注意的是，SingleTop 模式仅对栈顶位置有效。如果目标 Activity 在栈中但不在顶部（如 A→B→A 的情况），第二次启动 A 仍会创建第二个 A 实例，造成栈冗余

1.3 SingleTask 模式（任务栈内单例模式）

SingleTask 模式确保整个任务栈中仅存在一个该 Activity 的实例，是一种更为严格的实例化控制机制.其核心行为包括两个方面：

当系统检测到要启动的 Activity 在当前任务栈中已存在时，会执行以下操作：

将该实例上方的所有 Activity 出栈（销毁）
使该实例成为栈顶
调用其 onNewIntent () 方法处理新的 Intent

如果栈中不存在该实例，则创建新实例并放入新任务栈中. 这种机制保证了 Activity 在其所属任务栈中的唯一性。

SingleTask 模式的实现依赖于taskAffinity 属性，该属性指定了 Activity 希望归属的任务栈，默认与应用包名一致. 系统会根据 taskAffinity 寻找匹配的任务栈：

如果存在匹配的任务栈且其中已包含该 Activity 实例，则复用该实例并清除栈顶其他 Activity
如果存在匹配的任务栈但其中没有该 Activity 实例，则创建新实例并放入该栈
如果不存在匹配的任务栈，则创建新的任务栈并放入该实例.

SingleTask 模式的典型应用场景包括：

应用主界面：如微信首页、银行应用主页等需要确保全局唯一入口的场景.
深度链接处理：当通过 URL 链接跳转到应用内特定页面时，可以直接定位到目标页面并清理无关的历史栈
跨应用调用：当一个应用需要调用另一个应用的特定功能页面时，可以确保直接到达目标页面

1.4 SingleInstance 模式（全局单例模式）

SingleInstance 模式是 Android 启动模式中最严格的一种，它具有两个核心特征：

该 Activity 会单独占用一个新的任务栈
整个系统中只存在一个该 Activity 的实例

与 SingleTask 模式相比，SingleInstance 模式的限制更为严格。SingleTask 模式允许其他 Activity 加入到同一个任务栈中，而SingleInstance 模式不允许任何其他 Activity 存在于其任务栈中。当 SingleInstance 模式的 Activity 启动另一个 Activity 时，新启动的 Activity 会被分配到不同的任务栈中，就好像在 Intent 中设置了 FLAG_ACTIVITY_NEW_TASK 标志一样。

这种模式的应用场景相对有限，主要用于需要完全独立运行环境的特殊页面：

系统级应用界面：如电话拨号界面、锁屏界面等需要全局唯一且独立运行的场景
跨应用共享页面：如闹钟提醒界面、系统设置界面等需要在不同应用中保持一致状态的页面
安全性要求极高的场景：由于 SingleInstance 模式的 Activity 独占一个任务栈，无法被其他 Activity 插入，因此可以有效防止任务劫持攻击

1.5 SingleInstancePerTask 模式（Android 12 新增）

SingleInstancePerTask 是 Android 12（API 级别 31）新增的第五种启动模式,它提供了一种介于 SingleTask 和 SingleInstance 之间的灵活机制。

该模式的核心特性包括：

每个任务栈中仅能存在一个该 Activity 的实例
不同任务栈中可以存在多个该 Activity 的实例
该 Activity 只能作为任务栈的根 Activity 存在

与其他模式的区别在于：

与 SingleInstance 的区别：SingleInstance 确保整个系统中只有一个实例且独占任务栈，而 SingleInstancePerTask 允许多个任务栈中存在多个实例
与 SingleTask 的区别：SingleTask 限制该 Activity 只存在于一个任务栈中，而 SingleInstancePerTask 可以在不同任务栈中创建多个实例

SingleInstancePerTask 模式特别适合多窗口环境下的应用场景，如文档编辑器等。当配合 FLAG_ACTIVITY_MULTIPLE_TASK 或 FLAG_ACTIVITY_NEW_DOCUMENT 标志使用时，可以为每个文档或标签创建独立的任务栈，每个任务栈中都有独立的 Activity 实例。

二、启动模式在特定场景下的应用分析

2.1 多任务处理场景

在现代 Android 设备中，多任务处理已成为用户的基本需求。不同的启动模式在多任务场景中表现出截然不同的行为特征。

Standard 和 SingleTop 模式在多任务处理中表现出良好的适应性，它们允许多个 Activity 实例共存于不同的任务栈中。这种特性使得应用能够同时处理多个独立的任务流程。例如，在浏览器应用中，用户可以同时打开多个网页，每个网页都在独立的 Activity 实例中显示。当用户在任务切换界面切换不同的网页任务时，每个任务都能保持其独立的状态和历史记录。

SingleTask 模式在多任务处理中提供了一种集中化的管理方式。通过 taskAffinity 属性，具有相同亲和性的 Activity 可以被组织到同一个任务栈中.这种机制特别适合以下场景：

应用间协作：当应用 A 需要调用应用 B 的某个功能页面时，可以通过设置相同的 taskAffinity 将该页面整合到应用 A 的任务栈中，实现无缝的跨应用协作
任务栈迁移：allowTaskReparenting 属性配合 SingleTask 模式，可以实现 Activity 在不同任务栈间的动态迁移。例如，当应用 A 的 Activity 被应用 B 启动后，若用户返回应用 A，该 Activity 可以自动迁移到应用 A 的任务栈中

SingleInstance 模式 在多任务处理中表现出最强的隔离性。由于该模式的 Activity 独占一个任务栈且全局唯一，因此特别适合需要独立运行环境的系统级应用。例如：

电话应用的拨号界面：无论从哪个应用启动，都使用同一个全局唯一的拨号界面，确保用户体验的一致性
系统闹钟提醒：闹钟提醒界面需要在任何时候都能独立弹出，不受其他应用任务栈的影响

2.2 内存优化场景

内存优化是移动应用开发中的关键考量因素，不同的启动模式在内存管理方面表现出显著差异。

Standard 模式的内存特征是每次启动都会创建新实例，这在某些场景下可能导致内存占用过高。当频繁启动同一个 Activity 时，会产生大量的实例驻留在内存中，造成资源浪费.例如，在一个新闻应用中，如果用户快速滑动浏览新闻列表并频繁点击查看详情，使用 Standard 模式会导致大量新闻详情页实例同时存在于内存中。

为了优化这种情况，可以采用以下策略：

合理使用 SingleTop 模式：对于经常被重复启动且位于栈顶概率较高的页面，使用 SingleTop 模式可以避免重复创建实例
配合 Activity 的生命周期管理：通过 onTrimMemory 等回调方法，在系统内存紧张时主动释放不必要的 Activity 实例
使用弱引用避免内存泄漏：在需要长期持有 Activity 引用的场景中，使用弱引用可以防止内存泄漏

SingleTask 和 SingleInstance 模式在内存优化方面具有天然优势，它们通过限制实例数量来减少内存占用.特别是在以下场景中效果显著：

全局唯一页面：应用的主界面、设置界面等全局唯一的页面，使用 SingleTask 模式可以确保内存中只有一个实例
高频使用页面：对于经常被不同页面调用的公共功能页面，如登录界面、支付界面等，使用 SingleTask 模式可以避免重复创建
系统级服务页面：如文件选择器、图片浏览器等系统提供的公共服务页面，使用 SingleInstance 模式可以实现全局共享

然而，需要注意的是，过度使用 SingleTask 和 SingleInstance 模式也会带来系统开销.因为这些模式需要系统进行更复杂的任务栈管理和实例查找操作，在某些情况下可能反而影响性能。因此，在选择启动模式时需要综合考虑内存节省和性能开销的平衡。

2.3 安全相关场景

启动模式在应用安全性方面也发挥着重要作用，特别是在防止恶意攻击和保护用户隐私方面。

SingleInstance 模式具有最强的安全防护能力 。由于该模式的 Activity 独占一个任务栈，任何其他 Activity 都无法插入到其任务栈中，因此可以有效防止任务劫持攻击.任务劫持是一种常见的安全攻击手段，攻击者通过在目标应用的任务栈中插入恶意 Activity，欺骗用户执行危险操作。SingleInstance 模式通过其严格的任务栈隔离机制，从根本上杜绝了这种攻击的可能性。

SingleInstance 模式的安全应用场景包括：

金融交易界面：银行应用的转账、支付等关键操作界面，使用 SingleInstance 模式可以确保用户操作环境的纯净性
密码输入界面：应用的登录密码、支付密码等敏感信息输入界面，通过独占任务栈防止恶意程序窃取输入内容
系统权限请求界面：如摄像头权限、位置权限等系统级权限请求界面，使用 SingleInstance 模式可以确保用户明确知晓权限请求的来源

除了 SingleInstance 模式，其他启动模式也可以通过合理配置来增强安全性：

exported 属性配合启动模式：将敏感 Activity 设置为 exported="false"，并配合 SingleTask 模式，可以防止外部应用恶意调用
taskAffinity 的安全使用：避免跨应用共享相同的 taskAffinity，防止恶意应用通过设置相同的亲和性来注入到目标应用的任务栈中
Intent 过滤机制：通过设置严格的 Intent 过滤条件，配合适当的启动模式，可以精确控制 Activity 的启动来源

三、开发中不同启动模式解决的具体问题

3.1 防止重复创建 Activity

在实际开发中，重复创建 Activity 是一个常见的性能问题，不仅会增加内存占用，还可能导致界面状态丢失和用户体验下降。不同的启动模式提供了针对性的解决方案。

SingleTop 模式是解决栈顶重复创建问题的首选方案。例如，在新闻应用中，用户可能在新闻列表页多次点击同一新闻标题。如果新闻详情页使用 Standard 模式，每次点击都会创建一个新的详情页实例，导致栈中存在多个相同新闻的详情页。而使用 SingleTop 模式后，当新闻详情页已经在栈顶时，再次点击会直接调用 onNewIntent () 方法更新新闻内容，避免了重复实例的创建。

SingleTask 模式则提供了更强大的全局去重能力。在电商应用中，购物车页面通常需要在全局范围内保持唯一。当用户从商品详情页、订单确认页等多个入口跳转到购物车时，SingleTask 模式可以确保无论从哪个路径进入，都直接复用已有的购物车实例，并清理掉路径上的无关页面.

需要特别注意的是，忘记重写 onNewIntent () 方法是一个常见的开发陷阱.当使用 SingleTop 或 SingleTask 模式时，如果新的 Intent 携带了不同的数据，必须在 onNewIntent () 中处理这些数据，否则会导致数据更新失败。例如，在搜索功能中，如果搜索结果页使用 SingleTop 模式，当用户进行新的搜索时，必须在 onNewIntent () 中获取新的搜索关键词并更新界面显示。

3.2 深度链接处理

深度链接（Deep Linking）是现代应用的重要特性，它允许外部链接直接跳转到应用内的特定页面。不同的启动模式在深度链接处理中扮演着关键角色。

SingleTask 模式配合适当的 Intent 标志，是处理深度链接的理想选择。当用户点击一个深度链接时，系统会根据链接的内容寻找匹配的 Activity：

如果该 Activity 已经存在于某个任务栈中，系统会将该任务栈移动到前台，并清理掉该 Activity 之上的所有 Activity，确保用户直接看到目标页面
如果该 Activity 不存在，则创建新的实例并放入新的任务栈中

这种机制特别适合以下深度链接场景：

商品详情页链接：电商应用的商品推广链接需要直接跳转到指定商品的详情页
文章内容链接：新闻应用的分享链接需要直接显示指定文章的完整内容
订单状态页面：用户通过邮件或短信中的链接查看订单状态时，需要直接跳转到对应的订单详情页

Intent 标志与启动模式的协同使用可以实现更灵活的深度链接处理。例如，配合 FLAG_ACTIVITY_CLEAR_TOP 标志，可以确保在启动目标 Activity 时，其上方的所有 Activity 都被清理，从而实现 "一键直达" 的效果。

需要注意的是，深度链接处理不当可能导致栈管理混乱。例如，如果深度链接的目标 Activity 使用 Standard 模式，每次点击链接都会创建新实例，可能导致返回栈中积累大量重复的页面。因此，对于需要处理深度链接的 Activity，建议使用 SingleTask 或 SingleTop 模式，并在 onNewIntent () 中正确处理链接参数。

3.3 返回栈管理问题

返回栈的正确管理直接影响用户的导航体验。许多应用在返回栈管理上存在问题，导致用户在使用返回键时出现意外的界面跳转。

启动模式对返回栈的影响主要体现在以下几个方面：

Standard 模式的返回栈行为最为直观，遵循严格的 "后进先出" 原则。用户按下返回键时，当前 Activity 出栈销毁，前一个 Activity 恢复。这种模式适合大多数常规页面，如列表页到详情页的导航流程.

SingleTop 模式在返回栈管理上与 Standard 模式基本相同，唯一的区别是栈顶复用机制。当栈顶的 Activity 被复用时，返回栈的结构保持不变，用户按返回键时仍会回到之前的页面.

SingleTask 模式会对返回栈产生较大影响。当复用已有实例时，该实例上方的所有 Activity 都会被销毁，这意味着用户按返回键时会跳过这些被清理的页面，直接回到该实例之前的页面.这种行为在某些场景下是合理的，如从购物车页面返回商品列表页，但在其他场景下可能导致用户困惑。

SingleInstance 模式的返回栈管理最为特殊。由于该模式的 Activity 独占一个任务栈，当用户按返回键时，会直接销毁该 Activity 并回到之前的任务栈。如果该 Activity 是通过其他应用启动的，则会回到启动它的应用界面.

为了避免返回栈管理问题，开发中需要注意以下几点：

明确返回路径预期：在设计 Activity 的启动模式时，必须明确用户按返回键时的预期行为，并通过实际测试验证.
合理使用 Intent 标志：通过设置 FLAG_ACTIVITY_CLEAR_TOP、FLAG_ACTIVITY_SINGLE_TOP 等标志，可以在启动时动态调整返回栈结构
避免过度使用 SingleTask 和 SingleInstance：这些模式会改变默认的返回栈行为，使用不当会导致用户体验问题

3.4 跨应用调用场景

跨应用调用是 Android 系统开放性的重要体现，不同的启动模式在支持跨应用协作方面提供了灵活的解决方案。

SingleTask 和 SingleInstance 模式特别适合跨应用调用场景，因为它们可以确保被调用的 Activity 在不同应用间保持一致的实例状态.例如：

系统相机调用：当应用需要调用系统相机拍照时，无论从哪个应用启动，都会使用同一个相机界面实例，确保拍照结果的一致性
文件选择器：多个应用共享同一个系统文件选择器，用户可以在不同应用间无缝选择和分享文件
社交媒体分享：应用的分享功能调用系统或第三方的分享界面时，需要确保分享界面的独立性和一致性

taskAffinity 属性在跨应用调用中发挥着关键作用。通过设置不同的 taskAffinity，可以实现 Activity 在不同任务栈间的灵活分配:

当调用系统应用时，被调用的 Activity 通常会进入系统应用的任务栈
当调用其他第三方应用时，可以通过设置相同的 taskAffinity 将 Activity 整合到调用者的任务栈中
通过 allowTaskReparenting 属性，可以实现 Activity 在任务栈间的动态迁移，提升用户体验

在跨应用调用的实现中，还需要注意以下技术细节：

权限管理：确保被调用的 Activity 具有适当的 exported 属性设置，既要保证安全性，又要支持跨应用调用
Intent 过滤：通过设置精确的 Intent 过滤条件，确保只有预期的应用能够调用特定的 Activity
数据传递安全：在跨应用传递数据时，需要注意数据的安全性和完整性，避免敏感信息泄露

四、Android 各版本中启动模式的特性和差异

Android 系统的不断演进带来了启动模式机制的持续优化和改进。从早期版本到最新的 Android 14/15，启动模式在功能、性能和安全性方面都发生了重要变化。

4.1 早期版本（Android 1.0 - Android 9）

在 Android 的早期版本中，启动模式的基本框架已经确立，但在具体实现和行为上与现代版本存在一些差异。

Android 1.0 到 Android 3.0期间，启动模式的概念已经引入，但主要用于基本的任务栈管理。这一时期的特点包括：

四种基本启动模式（standard、singleTop、singleTask、singleInstance）已经全部存在
taskAffinity 的作用相对简单，主要用于决定 Activity 的默认任务栈归属
缺乏对多窗口环境的支持，所有 Activity 都在单窗口模式下运行

Android 4.0 到 Android 9期间，随着硬件性能的提升和用户需求的增长，启动模式机制得到了进一步完善：

引入了更多的 Intent 标志，如 FLAG_ACTIVITY_NEW_DOCUMENT、FLAG_ACTIVITY_MULTIPLE_TASK 等，提供了更灵活的启动控制
增强了任务栈管理功能，允许开发者更精细地控制 Activity 在任务栈中的行为
开始支持多窗口模式，特别是在 Android 7.0 中引入了分屏多任务功能

在这一时期，启动模式的行为相对稳定，但也存在一些已知问题：

后台启动 Activity 的限制较少，应用可以较自由地在后台启动界面
安全性考虑不够完善，存在任务劫持等安全风险
内存管理机制相对简单，缺乏对后台任务的有效管理

4.2 现代版本（Android 10 - Android 13）

从 Android 10 开始，Google 对系统的后台管理和安全性进行了重大改革，这些变化直接影响了启动模式的使用方式。

Android 10 的重要变化包括：

严格的后台启动限制：从 Android 10 开始，对后台应用启动 Activity 施加了更严格的限制。应用在后台时，不能随意启动新的 Activity，必须通过特定的方式（如通知、PendingIntent 等）来启动.
分区存储的影响：分区存储机制改变了应用访问文件的方式，这对使用 SingleInstance 模式的系统级应用产生了影响
增强的隐私保护：应用在后台时，对用户位置、传感器等敏感信息的访问受到限制，这可能影响某些启动模式的使用场景

Android 11 的进一步优化：

改进的任务管理：引入了 "最近使用的应用" 界面的新设计，对任务栈的展示方式进行了优化
增强的多任务功能：支持更多的多窗口布局方式，对启动模式的多窗口适配提出了新要求
后台服务限制加强：进一步收紧了后台服务启动 Activity 的能力，要求必须明确指定启动类型

Android 12 的重大更新：

新增 SingleInstancePerTask 模式：这是 Android 12 引入的第五种启动模式，专门为多窗口环境设计.
新的启动动画系统：所有应用都将拥有启动动画，这对启动模式的视觉效果产生了影响.
增强的安全性：对隐式 Intent 的使用进行了更严格的限制，要求必须使用显式 Intent 来启动特定的 Activity

Android 13 的持续改进：

后台启动几乎被封死：从 Android 13 开始，后台启动 Activity 的能力被极大限制，系统原则变为 "后台不应该打断用户当前行为"
多窗口支持的完善：进一步完善了对折叠屏、双屏等特殊屏幕形态的支持，要求启动模式更好地适配这些场景
新的权限模型：引入了运行时权限的新分类，对某些敏感权限的申请界面启动方式产生了影响

4.3 最新版本（Android 14 及以上）

Android 14 及更高版本在启动模式方面继续进行优化，主要集中在安全性和性能方面。

Android 14 的重要变化：

更严格的 Intent 验证：对 Intent 和 PendingIntent 的验证更加严格，隐式 Intent 的使用受到更多限制
后台启动的进一步限制：引入了更多的后台启动限制，特别是对使用 PendingIntent 启动 Activity 的场景
增强的安全检查：对应用间的数据传递进行了更严格的安全检查，这对跨应用调用的启动模式产生了影响
内存锁定限制：将每个进程使用 mlock () 锁定的最大内存从 64MB 降低到 64KB

Android 15 的新特性：

后台服务的超时机制：引入了后台服务的超时机制，数据同步服务在 24 小时内最多只能运行 6 小时
更安全的启动方式：进一步加强了对后台启动 Activity 的限制，推荐使用 WorkManager 等方式来处理后台任务
兼容性框架的改进：对兼容性框架进行了更新，确保应用能够更好地适配不同版本的系统.

4.4 版本兼容性考虑

在开发跨版本兼容的应用时，需要特别注意启动模式在不同版本间的行为差异：

向后兼容性问题：

低版本系统不支持 Android 12 引入的 SingleInstancePerTask 模式，在使用时需要进行版本检查
某些在高版本中被限制的后台启动方式，在低版本中仍然可用，需要在代码中进行条件判断
权限申请界面的启动方式在不同版本间存在差异，需要适配不同的系统版本

向前兼容性考虑：

新的启动模式特性（如 SingleInstancePerTask）只能在支持的系统版本上使用
随着系统版本的更新，某些传统的启动方式可能被标记为 deprecated，需要及时更新代码
安全性增强可能导致某些原有的功能无法正常工作，需要寻找替代方案

为了确保应用在不同 Android 版本上的兼容性，建议采用以下策略：

使用版本检查机制：在代码中使用 Build.VERSION.SDK_INT 来判断当前系统版本，根据不同版本执行不同的逻辑
渐进式增强：在低版本系统上使用基本功能，在高版本系统上使用新特性
测试多版本环境：在开发过程中，需要在多个 Android 版本的设备或模拟器上进行测试，确保功能的一致性

五、技术实现细节

5.1 任务栈（Task Stack）的工作原理

理解任务栈的工作原理是掌握启动模式机制的基础。任务栈是 Android 系统管理 Activity 的核心数据结构，它决定了 Activity 的显示顺序和返回行为。

任务栈的基本结构：

任务栈是一种 **"后进先出"（Last In First Out, LIFO）的栈结构 **，每个 Activity 按照打开的顺序被压入栈中.当用户按下返回键时，当前 Activity 从栈顶弹出并销毁，前一个 Activity 恢复显示。这种结构确保了导航历史的正确性，用户可以按照操作顺序依次返回。

任务栈的创建和管理：

大多数任务从设备主屏幕启动。当用户点击应用启动器或主屏幕上的应用图标时，如果该应用不存在任务，则系统创建一个新任务，主 Activity 作为堆栈中的根 Activity.
当 Activity A 启动 Activity B 时，B 被推送到栈顶并获得焦点，A 保留在堆栈中并停止运行。系统会保留 A 的界面状态，包括滚动位置、输入的文本等.
任务栈可以包含来自同一个应用或不同应用的 Activity，这取决于 Activity 的启动方式和配置

任务栈与启动模式的关系：

不同的启动模式决定了新的 Activity 实例如何与任务栈关联：

Standard 模式：每次创建新实例并压入调用者的任务栈
SingleTop 模式：如果栈顶是该 Activity 则复用，否则创建新实例压入栈顶
SingleTask 模式：寻找匹配 affinity 的任务栈，存在则复用并清理栈顶，不存在则创建新栈
SingleInstance 模式：创建全新的任务栈，该 Activity 独占此栈
SingleInstancePerTask 模式：创建新任务栈或复用已有栈，但每个栈中只能有一个该 Activity 实例

任务栈的生命周期：

任务栈的生命周期与其中的 Activity 密切相关：

当所有 Activity 从堆栈中移除后，任务栈将不复存在.
任务可以进入后台和前台。当用户使用主屏幕按钮离开应用时，任务进入后台，所有 Activity 停止但状态保留。当用户再次启动应用时，任务回到前台，恢复之前的状态.
系统可能在内存不足时销毁后台任务中的 Activity，但任务栈的结构信息会被保留，当任务再次进入前台时会重新创建这些 Activity

5.2 Intent 标志与启动模式的协同作用

Intent 标志可以在运行时动态修改 Activity 的启动行为，与在 AndroidManifest.xml 中声明的启动模式形成互补关系。

主要 Intent 标志及其作用：

FLAG_ACTIVITY_NEW_TASK：在新任务中启动 Activity。如果已经存在与该 Activity 具有相同亲和性的任务栈，则将该任务栈移动到前台。这与在清单文件中设置 launchMode="singleTask" 的效果类似。
FLAG_ACTIVITY_SINGLE_TOP：如果要启动的 Activity 已经位于当前任务栈的顶部，则复用该实例并调用 onNewIntent () 方法，不创建新实例。这与设置 launchMode="singleTop" 的效果相同。
FLAG_ACTIVITY_CLEAR_TOP：如果要启动的 Activity 已经在当前任务中运行，则销毁其上面的所有其他 Activity，将意图传递给已恢复的实例（现在位于顶层）的 onNewIntent () 方法。需要注意的是，如果指定 Activity 的启动模式为 standard，该模式也会从堆栈中移除，并在相应位置启动一个新实例来处理传入的 Intent。
FLAG_ACTIVITY_CLEAR_TASK：清除与该 Activity 相关的整个任务栈，然后在新任务中启动该 Activity。通常与 FLAG_ACTIVITY_NEW_TASK 一起使用。
FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS：防止 Activity 出现在 "最近使用的应用" 列表中。

Intent 标志的优先级：

当在 Intent 中设置标志时，这些标志会覆盖在清单文件中声明的启动模式。例如，如果在清单文件中将 Activity 设置为 standard 模式，但在启动时设置了 FLAG_ACTIVITY_SINGLE_TOP 标志，则该 Activity 会按照 singleTop 模式的行为运行。

标志组合的高级用法：

FLAG_ACTIVITY_NEW_TASK + FLAG_ACTIVITY_CLEAR_TOP：这是一种常见的组合，用于实现 "深度链接" 效果。它会先清除目标 Activity 之上的所有 Activity，然后将该 Activity 置于栈顶
FLAG_ACTIVITY_MULTIPLE_TASK + FLAG_ACTIVITY_NEW_DOCUMENT：配合 SingleInstancePerTask 模式使用，可以为每个文档创建独立的任务栈
FLAG_ACTIVITY_REORDER_TO_FRONT：如果要启动的 Activity 已经在任务栈中存在，则将其移动到栈顶，不会创建新实例

5.3 Activity 生命周期在不同启动模式下的表现

不同的启动模式会影响 Activity 的生命周期回调方法的调用时机和顺序。

Standard 和 SingleTop 模式下的生命周期：

在这两种模式下，Activity 的生命周期表现基本相同，主要区别在于是否创建新实例：

当创建新实例时（Standard 模式总是创建，SingleTop 模式在非栈顶时创建）：

onCreate () → onStart () → onResume () 正常调用
当用户按下返回键或调用 finish () 时：onPause () → onStop () → onDestroy ()

当复用已有实例时（仅 SingleTop 模式在栈顶时）：

不会调用 onCreate ()、onStart () 等初始化方法
直接调用 onNewIntent (Intent intent) 方法，传递新的 Intent
可以在 onNewIntent () 中处理新的 Intent 数据，并通过调用 setIntent (intent) 来更新 Activity 的 Intent

SingleTask 和 SingleInstance 模式下的生命周期：

这两种模式在复用实例时会产生更复杂的生命周期行为：

当复用已有实例时：

首先会调用 onPause () 方法暂停当前栈顶的 Activity
然后销毁该实例上方的所有 Activity，每个被销毁的 Activity 都会调用完整的生命周期方法（onPause () → onStop () → onDestroy ()）
最后调用目标 Activity 的 onNewIntent () 方法

这种行为可能导致以下问题：

状态丢失：被销毁的 Activity 的数据和状态会丢失，除非在 onSaveInstanceState () 中进行了保存
性能影响：频繁销毁和重建 Activity 会影响应用性能
用户体验问题：用户可能看到界面的快速闪烁或跳转

SingleInstancePerTask 模式的特殊行为：

作为 Android 12 新增的模式，SingleInstancePerTask 在生命周期方面有其独特之处：

当在新任务栈中创建实例时，遵循标准的生命周期流程
当在已有任务栈中复用实例时，行为类似 SingleTask 模式，会清理栈顶并调用 onNewIntent ()
配合多窗口使用时，不同任务栈中的实例可以独立管理自己的生命周期

5.4 PendingIntent 与启动模式

PendingIntent 是一种特殊的 Intent，它允许应用在未来某个时刻执行 Intent 操作。在使用 PendingIntent 启动 Activity 时，启动模式的行为会受到一些特殊规则的影响。

PendingIntent 的基本概念：

PendingIntent 代表一个延迟执行的 Intent 操作，通常用于通知、闹钟、短消息等场景。与普通 Intent 不同，PendingIntent 具有以下特点：

可以在不同的应用组件间传递
即使创建它的应用已经停止运行，仍然可以执行
具有不同的 FLAG 标志来控制其行为

PendingIntent 与启动模式的交互：

当使用 PendingIntent 启动 Activity 时，需要注意以下规则：

PendingIntent 的 FLAG 影响：

FLAG_CANCEL_CURRENT：如果已有相同的 PendingIntent，则取消并创建新的
FLAG_UPDATE_CURRENT：更新已有 PendingIntent 的内容，但不改变其身份
FLAG_ONE_SHOT：只执行一次，执行后自动取消

启动模式的优先级：

PendingIntent 中设置的 Intent 标志会覆盖 Activity 在清单文件中声明的启动模式
如果 PendingIntent 的 Intent 中没有设置特殊标志，则使用 Activity 默认的启动模式

安全限制：

从 Android 14 开始，PendingIntent 的安全模型变得更加严格
需要确保 PendingIntent 的创建和使用都经过适当的权限检查
对于敏感操作（如启动具有特定权限的 Activity），需要使用更安全的方式

实际应用场景：

通知点击启动 Activity：在通知中使用 PendingIntent 启动 Activity 时，需要考虑启动模式对用户体验的影响。例如，使用 SingleTop 模式可以避免在用户快速多次点击通知时创建多个 Activity 实例
闹钟提醒启动界面：闹钟应用使用 PendingIntent 在指定时间启动提醒界面，通常使用 SingleInstance 模式确保提醒界面的独立性
快捷方式启动：桌面快捷方式使用 PendingIntent 启动特定 Activity，需要根据快捷方式的功能选择合适的启动模式

六、实战建议与最佳实践

6.1 如何选择合适的启动模式

选择合适的启动模式需要综合考虑应用的功能需求、用户体验和性能要求。以下是一些实用的选择准则：

根据页面特性选择：

列表详情类页面：如新闻列表、商品列表等，通常使用 Standard 模式。因为用户可能需要同时查看多个不同的详情页，每个详情页都应该是独立的实例
顶部操作栏页面：如搜索结果页、筛选条件页等，推荐使用 SingleTop 模式。当用户在同一页面进行多次操作（如多次搜索）时，可以避免重复创建实例
全局唯一页面：如应用主界面、设置界面、购物车等，适合使用 SingleTask 模式。确保在全局范围内只有一个实例，避免状态混乱
系统级功能页面：如相机、文件选择器等，使用 SingleInstance 模式。保证这些页面的独立性和全局唯一性
多窗口文档页面：如文档编辑器、网页浏览器等，配合 Android 12 + 使用 SingleInstancePerTask 模式，为每个文档创建独立的任务栈

根据使用场景选择：

频繁跳转场景：如果某个页面会被多个不同页面频繁调用，且每次调用都需要独立状态，使用 Standard 模式
结果返回场景：如果启动某个 Activity 是为了获取结果（如选择图片、选择日期等），通常使用 Standard 模式，并通过 startActivityForResult () 方法处理结果
深度链接场景：需要处理外部链接直接跳转的页面，推荐使用 SingleTask 模式，确保能够直接定位到目标页面并清理无关栈
跨应用调用场景：当 Activity 需要被其他应用调用时，根据功能特性选择 SingleTask 或 SingleInstance 模式

性能和内存考虑：

避免在内存敏感的设备上过度使用 Standard 模式，特别是频繁启动的页面
SingleTask 和 SingleInstance 模式虽然能减少实例数量，但会增加系统的任务栈管理开销
对于内存占用较大的页面（如包含大量图片或复杂布局的页面），更应该考虑使用复用模式

6.2 常见配置错误及解决方案

在实际开发中，启动模式的配置错误是导致应用出现各种异常行为的常见原因。以下是一些典型的错误及其解决方案：

错误 1：忘记重写 onNewIntent () 方法

现象：使用 SingleTop 或 SingleTask 模式时，Activity 复用了已有实例，但新的 Intent 数据没有更新到界面上
原因：当 Activity 被复用时，系统不会调用 onCreate () 等初始化方法，而是直接调用 onNewIntent ()。如果没有重写该方法，就无法处理新的 Intent 数据
解决方案：在所有使用了 SingleTop 或 SingleTask 模式的 Activity 中，必须重写 onNewIntent () 方法，并在其中处理新的 Intent 数据。通常需要调用 setIntent (intent) 来更新 Activity 的 Intent，然后根据新数据更新界面显示

错误 2：返回键行为不符合预期

现象：用户按下返回键时，跳转的页面与预期不符，可能跳过了某些页面或直接回到了桌面
原因：使用 SingleTask 或 SingleInstance 模式时，会改变默认的返回栈行为。特别是 SingleTask 模式在复用实例时会清理栈顶，导致返回路径发生变化
解决方案：
- 在设计启动模式时，必须明确每个页面的返回路径预期，并通过测试验证
- 可以通过设置 Intent 标志（如 FLAG_ACTIVITY_CLEAR_TOP）来控制返回栈的清理行为
- 使用 Android 提供的导航组件（如 Navigation Component）可以更好地管理返回栈，避免手动管理的复杂性

错误 3：跨应用调用权限问题

现象：其他应用无法正常调用本应用的 Activity，出现权限错误或找不到 Activity 的异常
原因：
- Activity 的 exported 属性设置不正确。从 Android 12 开始，exported 属性的自动推导规则发生了变化
- 缺少适当的 Intent 过滤条件，导致无法匹配外部调用的 Intent
- 目标 Activity 没有声明在 AndroidManifest.xml 中
解决方案：
- 正确设置 exported 属性。如果 Activity 需要被外部调用，设置为 true；否则设置为 false
- 添加适当的 Intent 过滤条件，包括 action、category、data 等
- 确保所有需要被外部调用的 Activity 都在清单文件中正确声明
- 对于敏感的 Activity，可以通过权限机制进行保护

错误 4：多窗口适配问题

现象：在分屏、自由窗口等多窗口环境下，应用的界面显示异常，或者启动模式的行为与单窗口环境不一致
原因：没有正确适配多窗口环境，特别是在使用 SingleInstancePerTask 等新特性时
解决方案：
- 针对不同的窗口模式进行测试，确保启动模式的行为符合预期
- 对于 Android 12 + 的设备，充分利用 SingleInstancePerTask 模式来支持多窗口
- 在多窗口环境下，注意 Activity 的 resizeableActivity 属性的设置
- 测试在窗口大小变化时 Activity 的状态保存和恢复

6.3 性能优化技巧

合理使用启动模式可以显著提升应用的性能表现，以下是一些实用的优化技巧：

内存优化策略：

减少不必要的实例创建：

对于频繁使用的页面，使用 SingleTop 或 SingleTask 模式避免重复创建
在内存紧张的设备上，优先考虑复用模式
配合 Activity 的 onTrimMemory 回调，在系统内存不足时主动释放不必要的实例

优化任务栈管理：

避免创建过多的任务栈，特别是使用 SingleInstance 模式时
合理使用 taskAffinity 属性，将相关的 Activity 组织到同一个任务栈中
使用 FLAG_ACTIVITY_CLEAR_TOP 等标志，在启动时清理不必要的历史栈

延迟加载策略：

使用 ViewStub 等技术延迟加载启动时不需要的界面元素
在 onNewIntent () 中使用懒加载，只有在需要时才加载资源
对于大型图片或复杂布局，使用异步加载避免阻塞主线程

启动时间优化：

避免在 onCreate () 中进行耗时操作：

将复杂的初始化工作推迟到 onResume () 或使用异步方式处理
使用 Application 启动器库（App Startup Library）来优化组件初始化顺序
对于非关键的初始化，可以使用懒加载策略

合理使用启动模式减少重建：

使用 SingleTop 模式避免栈顶重复创建
使用 SingleTask 模式确保全局唯一实例，避免重复初始化
配合使用 android:configChanges 属性，避免因配置变更导致的重建

优化 Intent 传递的数据：

避免在 Intent 中传递过大的数据，特别是 Parcelable 或 Serializable 对象
如果需要传递大数据，可以考虑使用文件或 ContentProvider 的方式
使用 Bundle 的 putSparseParcelableArray () 等高效方法

电量优化：

减少后台 Activity 启动：

从 Android 10 开始，后台启动 Activity 受到严格限制，应尽量避免
使用 WorkManager 等机制处理后台任务，而不是直接启动 Activity
对于必须在后台启动的界面，使用通知或 PendingIntent 的方式

优化任务栈的保活策略：

使用 android:alwaysRetainTaskState 属性控制任务栈的保留策略
避免频繁创建和销毁任务栈，特别是使用 SingleInstance 模式时
合理使用 android:clearTaskOnLaunch 和 android:finishOnTaskLaunch 属性

6.4 调试和监控方法

在开发过程中，正确的调试和监控方法可以帮助快速定位和解决启动模式相关的问题。

使用系统工具监控任务栈：

adb shell dumpsys activity：

使用命令 adb shell dumpsys activity activities | grep <package_name> 可以查看指定应用的 Activity 和任务栈状态
输出结果包含每个任务栈的 ID、大小、可见性等信息
可以观察启动模式对任务栈结构的影响

开发者选项中的调试功能：

启用 "显示布局边界" 可以直观看到 Activity 的边界
启用 "显示 GPU 过度绘制" 可以优化界面性能
启用 "严格模式" 可以检测主线程的违规操作

代码调试技巧：

重写关键生命周期方法：

在 onCreate ()、onNewIntent ()、onResume () 等方法中添加日志输出
使用 Logcat 查看方法调用顺序，验证启动模式的行为是否符合预期
记录 Intent 的内容，特别是在使用 SingleTop 或 SingleTask 模式时

断点调试：

在关键方法（如 startActivity ()、onNewIntent ()）设置断点
观察 Intent 的内容和任务栈的状态变化
验证 Activity 实例是否被正确复用

性能分析工具：

Android Profiler：

使用 CPU 分析器监控 Activity 启动时的 CPU 使用情况
使用内存分析器查看 Activity 实例的创建和销毁
使用网络分析器监控数据加载对启动时间的影响

Systrace/Perfetto：

使用这些工具可以深入分析启动过程中的系统调用
找出启动过程中的性能瓶颈
分析不同启动模式对系统资源的影响

自动化测试建议：

编写 Espresso 测试用例：

测试返回键的行为是否符合预期
验证不同启动模式下 Activity 的显示顺序
测试深度链接的处理是否正确

使用 Monkey 测试：

模拟用户的随机操作，测试应用的稳定性
特别关注在频繁启动和销毁 Activity 时的表现
监控是否有内存泄漏或 ANR 发生

结语

Android 的 Activity 启动模式是一个功能强大且复杂的机制，正确理解和运用不同的启动模式对于开发高质量的应用至关重要。通过本文的全面分析，我们可以得出以下核心要点：

首先，四种传统启动模式（standard、singleTop、singleTask、singleInstance）各有其独特的应用场景。Standard 模式适合需要独立实例的常规页面，SingleTop 模式通过栈顶复用优化性能，SingleTask 模式确保全局唯一性，SingleInstance 模式提供最强的隔离性。而 Android 12 新增的 SingleInstancePerTask 模式则为多窗口环境提供了更好的支持。

其次，启动模式在多任务处理、内存优化和安全性方面都发挥着重要作用。在多任务场景中，需要根据任务间的关系选择合适的模式；在内存优化方面，应平衡实例复用与系统开销；在安全性方面，SingleInstance 模式的任务栈隔离机制能够有效防止攻击。

再次，不同的启动模式能够解决实际开发中的多种问题，包括防止重复创建、处理深度链接、管理返回栈和支持跨应用调用等。关键在于理解每种模式的行为特性，并根据具体需求进行选择。

最后，随着 Android 系统的不断更新，启动模式的行为也在持续演进。从早期的简单任务栈管理到现代的严格后台限制，开发者需要密切关注系统版本的变化，确保应用在不同版本上的兼容性。

在实际开发中，建议遵循以下最佳实践：根据页面特性和使用场景选择合适的启动模式；注意避免常见的配置错误，特别是忘记重写 onNewIntent () 方法；通过合理的性能优化策略提升应用表现；使用专业的调试工具监控和分析启动模式的行为。

掌握 Android 启动模式不仅需要理论知识，更需要通过大量的实践来加深理解。建议开发者在项目中逐步尝试不同的启动模式组合，观察其行为差异，并根据用户反馈不断优化。只有这样，才能真正发挥启动模式的强大功能，为用户提供流畅、高效、安全的应用体验。