(2)singleTop:栈顶复用模式

在该模式下，如果栈顶Activity是要新建的Activity,那么就不会重复创建新的Activity。通常适合多应用开启调用的Activity，通过这种设置可以避免已经创建过的Activity被重复创建。

(3)singleTask:栈内复用模式

与singleTop模式相似，只不过singleTop模式是只是针对栈顶的元素，而singleTask模式下，如果task栈内存在目标Activity实例，则：

a.将task内的对应Activity实例之上的所有Activity弹出栈。

b.将对应Activity置于栈顶，获得焦点。

应用场景：

程序主界面或者那些极其耗费系统资源的Activity，可以考虑将其设为singleTask模式，减少资源耗费。

 (4)singleInstance:全局唯一模式

在该模式下，我们会为目标Activity分配一个新的affinity，并创建一个新的Task栈，将目标Activity放入新的Task，并让目标Activity获得焦点。新的Task有且只有这一个Activity实例。如果已经创建过目标Activity实例，则不会创建新的Task，而是将以前创建过的Activity唤醒（对应Task设为Foreground状态）。

二、service

安卓service用于在后台完成用户的操作，通常无界面，适用于长期任务。

service分为两种：

（1）started（启动）service：是由其他组件调用startService()方法启动的，会调用到服务的onStartCommand()方法，服务会处于started状态。当服务是started状态时，其生命周期与启动它的组件无关，并且可以在后台无限期运行，即使启动服务的组件已经被销毁。因此，服务需要在完成任务后调用stopSelf()方法停止，或者由其他组件调用stopService()方法停止。

started  service的生命周期如下:

onCreate()‌：Service 第一次被创建时调用，只调用一次。

onStartCommand()‌：每次调用 startService() 时都会调用此方法。如果 Service 已经启动，再次调用 startService() 不会重新创建 Service，而是重复调用 onStartCommand() 方法。

onDestroy()‌：当调用 stopService() 或 stopSelf() 方法时，Service 被销毁，该方法会被调用。

（2）bound（绑定）service：当应用程序组件调用bindService()方法绑定到服务时，服务处于bound状态。使用bindService()方法启用服务，会调用到服务的onBind()方法，调用者与服务绑定在了一起，调用者一旦退出，服务也就终止。

bound service的生命周期如下： 

onCreate()‌：Service 第一次被创建时调用，只调用一次。

onBind()‌：当有组件通过 bindService() 绑定到 Service 时调用。该方法返回一个 IBinder 对象，供客户端与 Service 通信。

onUnbind()‌：当所有客户端都解绑（调用 unbindService()）后调用。

onDestroy()‌：当 Service 不再被任何组件绑定且不再需要时调用。

Started Service 适用于长时间运行的任务，而 Bound Service 更适合需要与组件进行交互的。

三、Content Provider

Content Provider用于实现跨应用的数据共享，是 Android 系统中实现进程间通信（IPC）的一种机制。它允许一个应用访问另一个应用的数据，而无需直接访问其文件或数据库。它管理对中央数据存储区的访问，协调许多不同的 API 和组件对应用数据存储层的访问‌。   

Content Provider通过URI(统一资源标识符)来标识数据，外部应用通过ContentResolver与ContentProvider进行交互。URI的格式通常为”content://<authority>/<path>/<id>”，其中：

content://  —— 固定前缀

<authority> ——  授权信息，通常为应用的包名或自定义名称，用于唯一标识 Content Provider

<path> —— 数据路径，表示要访问的数据集

<id> —— 可选，表示特定数据记录的唯一标识

Content Provider 类需要实现以下核心方法：

(1) onCreate()：Content Provider 被创建时调用，通常用于初始化数据库等操作。

(2) query()：用于查询数据，返回一个 Cursor 对象。

(3) insert()：用于插入数据。      (4) update()：用于更新数据。      (5) delete()：用于删除数据。      (6) getType()：返回指定 URI 对应的数据 MIME 类型‌。

Content Provider 本身不直接与外部应用交互，而是通过 ContentResolver 类进行交互。ContentResolver 是一个抽象类，提供与 Content Provider 相同签名的方法，例如 query()、insert()、update()、delete()。外部应用通过 Context 获取 ContentResolver，然后调用这些方法来访问 Content Provider‌。

Content Provider 主要用于以下场景：

（1）跨应用数据共享‌：如一个应用需要读取另一个应用的数据库或文件数据。

（2）访问系统数据‌：如读取联系人、短信、图片等系统预置的数据。

（3）封装复杂数据‌：当需要对外提供复杂的数据结构时，通过 Content Provider 统一管理访问逻辑。

（4）进程间通信‌：在不同进程之间共享数据。

四、Broadcast Receiver

Broadcast Receiver主要用于接收和响应来自系统或应用的广播消息。它允许应用程序在特定事件发生时收到通知并执行相应操作，是实现组件间通信的重要机制。

Broadcast有两种类型：普通广播和有序广播。

1.普通广播 (Normal Broadcast)‌：

(1)使用 sendBroadcast() 发送。      (2)完全异步，逻辑上可以在同一时刻被所有匹配的接收者接收到。      (3)传递效率高，但接收者不能将处理结果传递给下一个接收者，也无法终止广播传播。

2.‌有序广播 (Ordered Broadcast)‌：

(1)使用sendOrderedBroadcast(intent, receiverPermission)发送，第2个参数决定该广播的级别，级别数值是在 -1000 到 1000 之间 , 值越大 , 发送的优先级越高。

(2)同步顺序执行，接收器按优先级依次接收，同级别的接收的顺序是随机的。

(3)高级别的或同级别先接收到广播的可以通过abortBroadcast()方法截断广播使其他的接收者无法收到该广播。

Broadcast Receiver有两种注册方式：

1.静态注册‌：在 AndroidManifest.xml 文件中配置 <receiver> 标签。优点是即使应用未运行也能接收广播，缺点是不能动态控制注册与注销。

2.动态注册‌：在代码中调用 Context.registerReceiver() 方法。优点是注册和注销可以灵活控制，与组件生命周期绑定，缺点是应用必须运行才能接收广播。

主要应用场景:

(1)系统事件监听‌：如开机完成、网络状态变化、电池电量低、屏幕开关等。

(2)应用内通信‌：不同组件间的消息传递，实现解耦。

(3)应用间通信‌：一个应用可以发送广播，让其他应用（如果它们注册了相应的接收器）收到并处理。

(4)数据同步‌：应用间数据更新通知。

(5)网络状态监控‌：监听网络连接状态变化。