从结构上来说，PendingIntent 是 Intent 的包装类，其内部持有一个代表最终意图操作的 Intent（事实上，内部是通过 IIntentSender 间接持有）。它们的区别我认为可以概括为 3 个维度：1、执行进程不同 —— PendingIntent 在其他进程执行： Intent 通常会在创建进程中执行。
一、PendingIntent和Intent的区别
从结构上来说，PendingIntent 是 Intent 的包装类，其内部持有一个代表最终意图操作的 Intent（事实上，内部是通过 IIntentSender 间接持有）。它们的区别我认为可以概括为 3 个维度：
- 1、执行进程不同 —— PendingIntent 在其他进程执行： Intent 通常会在创建进程中执行，而 PendingIntent 通常不会在创建进程中执行；
- 2、执行时间不同 —— PendingIntent 会延迟执行： Intent 通常会立即执行，而 PendingIntent 通常会延迟执行，延迟到其他进程完成任务后再执行，甚至延迟到创建进程消亡后。例如，在 场景 1 – 系统通知消息的点击操作 中，即使发送系统通知消息的进程已经消亡了，依然不妨碍二级 Intent 的跳转；
- 3、执行身份不同 —— PendingIntent 支持授权： PendingIntent 内部持有授权信息，支持其他应用以当前应用的身份执行，这有利于避免嵌套 Intent 存在的安全隐患。而直接使用 Intent 的话，一般只能以当前应用的身份执行（为什么说一般？因为有 Activity#startActivityAsUser() 这个 API，但一般你拿不到所需的参数）。
为什么要使用 PendingIntent
PendingIntent 的应用场景关键在于间接的 Intent 跳转需求， 即先通过一级 Intent 跳转到某个组件，在该组件完成任务后再间接地跳转到二级的 Intent。PendingIntent 中的单词 “pending” 指延迟或挂起，就是指它是延迟的或挂起的。例如，你在以下场景中就可以使用 PendingIntent：
- 场景 1 – 系统通知消息的点击操作
- 场景 2 – 桌面微件的点击操作
- 场景 3 – 系统闹钟操作
- 场景 4 – 第三方应用回调操作
可以看到，在这些场景中，我们真正感兴趣的操作是挂起的，并且该操作并不是由当前应用执行，而是由某个外部应用来 “间接” 执行的。例如，我们在发送系统通知消息时，会通过 PendingIntent 构造一个系统通知 Notification ，并调用 NotificationManagerCompat.notify(…) 发送通知，此时并不会直接执行 PendingIntent。而是当系统显示通知，并且用户点击通知时，才会由系统通知这个系统应用间接执行 PendingIntent#send() ，而不是通过当前应用执行。
延伸阅读：
二、嵌套 Intent 存在的安全隐患
隐患 1 – Client App： 由于 ClientCallbackActivity 是从另一个应用 Provider App 启动的，因此该 Activity 必须暴露为 exported。这意味着除了 Provider App 可以启动该 Activity 外，同时也给了恶意应用启动该 Activity 的可能性。如果 ClientCallbackActivity 是一个普通的 Activity 还要说，要是 ClientCallbackActivity 是一个敏感或高风险的行为（例如支付回调），那么这就存在很大的安全隐患了；
隐患 2 – Provider App： 由于嵌套的 Intent 是在 Provider App 的上下文中启动的，那么二级 Intent 不仅可以正常启动 Client App 中的 ClientCallbackActivity（打开 exported 时），还可以启动 Provider App 中任意 Activity。这意味着给了恶意应用启动 Provider App 中敏感或高风险的 Activity 的可能性，即使这个敏感的 Activity 事先已经关闭 exported。这说明 exported 机制失效了，也存在很大的安全隐患。
