一、PendingIntent和Intent的區(qū)別

從結構上來說，PendingIntent 是 Intent 的包裝類，其內部持有一個代表最終意圖操作的 Intent（事實上，內部是通過 IIntentSender 間接持有）。它們的區(qū)別我認為可以概括為 3 個維度：

1、執(zhí)行進程不同 —— PendingIntent 在其他進程執(zhí)行： Intent 通常會在創(chuàng)建進程中執(zhí)行，而 PendingIntent 通常不會在創(chuàng)建進程中執(zhí)行；2、執(zhí)行時間不同 —— PendingIntent 會延遲執(zhí)行： Intent 通常會立即執(zhí)行，而 PendingIntent 通常會延遲執(zhí)行，延遲到其他進程完成任務后再執(zhí)行，甚至延遲到創(chuàng)建進程消亡后。例如，在 場景 1 – 系統(tǒng)通知消息的點擊操作 中，即使發(fā)送系統(tǒng)通知消息的進程已經消亡了，依然不妨礙二級 Intent 的跳轉；3、執(zhí)行身份不同 —— PendingIntent 支持授權： PendingIntent 內部持有授權信息，支持其他應用以當前應用的身份執(zhí)行，這有利于避免嵌套 Intent 存在的安全隱患。而直接使用 Intent 的話，一般只能以當前應用的身份執(zhí)行（為什么說一般？因為有 Activity#startActivityAsUser() 這個 API，但一般你拿不到所需的參數）。

為什么要使用 PendingIntent

PendingIntent 的應用場景關鍵在于間接的 Intent 跳轉需求， 即先通過一級 Intent 跳轉到某個組件，在該組件完成任務后再間接地跳轉到二級的 Intent。PendingIntent 中的單詞 “pending” 指延遲或掛起，就是指它是延遲的或掛起的。例如，你在以下場景中就可以使用 PendingIntent：

場景 1 – 系統(tǒng)通知消息的點擊操作場景 2 – 桌面微件的點擊操作場景 3 – 系統(tǒng)鬧鐘操作場景 4 – 第三方應用回調操作

可以看到，在這些場景中，我們真正感興趣的操作是掛起的，并且該操作并不是由當前應用執(zhí)行，而是由某個外部應用來 “間接” 執(zhí)行的。例如，我們在發(fā)送系統(tǒng)通知消息時，會通過 PendingIntent 構造一個系統(tǒng)通知 Notification ，并調用 NotificationManagerCompat.notify(…) 發(fā)送通知，此時并不會直接執(zhí)行 PendingIntent。而是當系統(tǒng)顯示通知，并且用戶點擊通知時，才會由系統(tǒng)通知這個系統(tǒng)應用間接執(zhí)行 PendingIntent#send() ，而不是通過當前應用執(zhí)行。

延伸閱讀：

二、嵌套 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 機制失效了，也存在很大的安全隱患。