網站首頁 編程語言 正文
引言
近期在分析問題過程中,需要反編譯 Google 的一些庫,在看源碼的時候,發現使用廣播的場景都會手動調用 goAsync()
方法。
goAsync()
是一個冷門但是非常有用的知識點,很少有文章會去分析 goAsync()
方法,因此這個方法在實際項目中使用的人也非常的少,我之前對這個方法也只是有一點了解,帶著我的好奇心,研究了一下。
通過這篇文章你將學習到以下內容:
-
goAsync()
是什么,它的作用是什么 - BroadcastReceiver 如何處理靜態接受者和動態接受者
- 為什么
goAsync
方法,可以保證廣播處于活躍狀態 - 在什么場景下使用
goAsync()
- 對進程的影響
goAsync 是什么
根據 BroadcastReceiver 源碼中的介紹,goAsync()
方法返回 PendingResult
,可以在 BroadcastReceiver.onReceive()
中使用,如果調用了這個方法,當 onReceive()
方法執行完返回時,并不會終止當前的廣播,廣播依然處于活躍狀態,直到調用 PendingResult.finish()
方法,才會結束掉當前的廣播。
goAsync()
方法并不會影響廣播超時的策略,從調用 goAsync()
方法開始,一直到調用 finish()
方法結束,如果超過了源碼中設置的廣播超時時間(10s/60s),依然會產生 ANR。
為什么 goAsync()
方法,可以保證廣播處于活躍狀態,我們需要先了解一下 BroadcastReceiver
調度流程,以 android-11.0.0_r3
源碼為例。
BroadcastReceiver 的調度流程
AMS 和應用進程之間的通信是通過 ApplicationThread
進行的,而廣播處理的方式分為靜態處理和動態處理,在 ApplicationThread
中分別對這兩種方式做了處理。
動態處理
動態處理流程,如下所示:
首先會調用 ActivityThread#ApplicationThread
類中 scheduleRegisteredReceiver
方法,最終會調用 LoadedApk#ReceiverDispatcher
類中的 performReceive
方法。
frameworks/base/core/java/android/app/LoadedApk #ReceiverDispatcher . java
public void performReceive(Intent intent, ...) { final Args args = new Args(intent, resultCode, ...); if (intent == null || !mActivityThread.post(args.getRunnable())) { .... } }
通過 mActivityThread. post ()
發送一個 Runnable, 我看一下 Args 中的 Runnable 實現。
frameworks/base/core/java/android/app/LoadedApk #ReceiverDispatcher #Args . java
public void Runnable getRunnable() { return () -> { // 這個是我們注冊的 BroadcastReceiver final BroadcastReceiver receiver = mReceiver; try { ...... // 為注冊的廣播接受者設置 PendingResult receiver.setPendingResult(this); // 執行 BroadcastReceiver#onReceive 方法 receiver.onReceive(mContext, intent); } catch (Exception e) { } // 判斷 PendingResult 是否為空,如果為空,就不會結束掉當前注冊的 Receiver // 應用層可以調用 BroadcastReceiver.goAsync,將 PendingResult 設置為null,從而打斷廣播后續處理流程 if (receiver.getPendingResult() != null) { finish(); } }; }
Runnable 方法實現分為兩個部分:
- 執行
BroadcastReceiver.onReceive()
方法之前會設置PendingResult
- 在
BroadcastReceiver.onReceive()
方法執行完后,檢查PendingResult
是否為空,如果為空,就不會結束掉當前注冊的BroadcastReceiver
靜態處理
首先會調用 ActivityThread#ApplicationThread
類中 scheduleReceiver
方法。
frameworks/base/core/java/android/app/ActivityThread #ApplicationThread . java
public final void scheduleReceiver(Intent intent, ...) { sendMessage(H.RECEIVER, r); }
通過 sendMessage(H.RECEIVER, r)
方法往主線程拋一個 RECEIVER
消息,發送 RECEIVER
消息的同時會攜帶 ReceiverData
實例,其中 r
是 ReceiverData
實例, ReceiverData
是 BroadcastReceiver.PendingResult
的子類。
在主線程消息隊列中接受 RECEIVER
消息,最后會調用 ActivityThread
中的 handleMessage
方法。
frameworks/base/core/java/android/app/ActivityThread. java
private void handleReceiver(ReceiverData data) { BroadcastReceiver receiver; try { // 通過反射構造一個 BroadcastReceiver 實例 receiver = packageInfo.getAppFactory() .instantiateReceiver(cl, data.info.name, data.intent); } catch (Exception e) { } ...... try { // 為注冊的廣播接受者設置 PendingResult // data 是 ReceiverData 實例, ReceiverData 是 BroadcastReceiver.PendingResult 的子類 receiver.setPendingResult(data); // 執行 BroadcastReceiver#onReceive 方法 receiver.onReceive(context.getReceiverRestrictedContext(), data.intent); } catch (Exception e) { ...... } // 判斷 PendingResult 是否為空,如果為空,就不會結束掉當前注冊的 Receiver // 應用層可以調用 BroadcastReceiver.goAsync,將 PendingResult 設置為 null,從而打斷廣播后續處理流程 if (receiver.getPendingResult() != null) { data.finish(); } }
handleMessage
方法實現分為兩個部分:
- 通過反射構造一個 BroadcastReceiver 實例
- 執行
BroadcastReceiver.onReceive()
方法之前會設置PendingResult
- 在
BroadcastReceiver.onReceive()
方法執行完后,檢查PendingResult
是否為空,如果為空,就不會結束掉當前注冊的BroadcastReceiver
靜態處理和動態處理,最終的處理流程都是一樣的,唯一的區別靜態處理是通過反射構造一個 BroadcastReceiver 實例。
為什么 goAsync 方法,可以保證廣播處于活躍狀態
通過上面的源碼分析,我們可以知道只需要將 PendingResult
設置為 null,不會馬上結束掉當前的廣播,相當于 "延長了廣播的生命周期",因此 Google 提供了 goAsync()
方法給開發者調用,當調用 goAsync()
時,不會結束掉當前的廣播,讓廣播依然處于活躍狀態。goAsync()
方法的實現很簡單。
public final PendingResult goAsync() { PendingResult res = mPendingResult; mPendingResult = null; return res; }
goAsync()
方法主要將 PendingResult
設置為 null,當 BroadcastReceiver.onReceive()
方法執行結束,會檢查 PendingResult
是否為 null,如果為 null 不會結束掉當前的 BroadcastReceiver
,需要開發者在合適的時機主動調用 PendingResult.finish()
方法,手動結束掉當前 BroadcastReceiver
,否則會觸發廣播的超時機制(10s/60s) 發生 ANR。
對進程的影響
BroadcastReceiver 的狀態會影響其所在進程的狀態,而進程的狀態又會影響它被系統回收的可能性。因為前臺進程和后臺進程,系統對它們的影響是不同的。
如何區分前臺進程
如果滿足以下任一條件,則進程會被認為位于前臺。
- 它正在用戶的互動屏幕上運行一個 Activity(其
onResume()
方法已被調用)。 - 它有一個 BroadcastReceiver 目前正在運行(其
BroadcastReceiver.onReceive()
方法正在執行) - 它有一個 Service 目前正在執行其某個回調(
Service.onCreate()
、Service.onStart()
或Service.onDestroy()
)中的代碼。
所以你不應該在 onReceive()
中啟動一個長時間運行的子線程,當 onReceive()
方法執行完返回時,BroadcastReceiver
就不再活躍,系統會將其進程視為低優先級進程,系統會根據內存情況來回收,在此過程中,也會終止進程中運行的派生線程。
所以如果你要在子線程中運行一個長時間的任務,我們可以使用 goAsync()
方法,它會中斷廣播后續處理流程,讓 BroadcastReceiver
處于活躍狀態,即使 onReceive()
方法執行完,也不會結束掉當前 BroadcastReceiver,除非主動調用 PendingResult.finish()
方法。
在什么場景下使用 goAsync
BroadcastReceiver. onReceive ()
方法運行在主線程中,如果我們在主線程做耗時任務就會出現 ANR。
PS:關于廣播 ANR 發生的場景、解決方案、源碼分析,將會在后面穩定性系列文章中分析
如果有耗時任務,大部分同學的做法是,直接在 onReceive ()
方法中起子線程處理耗時任務,當 onReceive () 方法返回時,BroadcastReceiver
不會在處于活躍狀態,那么廣播所在的進程也會受到影響,如果當前 BroadcastReceiver
所在的進程被系統回收了,那么子線程中的任務也會受到影響。
一般的處理方式會通過 IntentService、JobService 方式,保證任務能夠正常的執行完,但是使用 Service 的方式會帶來很多的問題,因為 Service 是通過 AMS 進行跨進程調度,AMS 調度也會有超時機制,如果因為系統原因,或者未知原因,導致 AMS 調度延遲了,ANR 的概率會增大,而且代碼的復雜度也變高了。
Google 也注意到這一點,所以在 BroadcastReceiver
調度流程中留出來一個入口。增加了一個靜態內部類 PendingResult,并且提供了 goAsync ()
方法給開發者調用,如果你需要運行一個長時間的任務,在切換到子線程之前,需要調用 goAsync ()
方法,讓廣播處于活躍狀態,在系統限制的時間內,處理完任務之后,主動調用 PendingResult. finish ()
方法,結束掉當前的廣播。
如何使用 goAsync
這里我以 Google play services cloud messaging 中的源碼為例。
public abstract class CloudMessagingReceiver extends BroadcastReceiver { public final void onReceive(final Context context, final Intent intent) { // 調用 goAsync() 返回新的 PendingResult,并將原 PendingResult 設置為 null final BroadcastReceiver.PendingResult goAsync = goAsync(); // 開啟線程處理接受的消息,并將 goAsync 傳遞到子線程 getBroadcastExecutor().execute(new Runnable() { @Override public final void run() { parseIntent(intent, , goAsync); } }); } public final void parseIntent(Intent intent, BroadcastReceiver.PendingResult goAsync) { try { /** * 處理耗時任務,如果任務在限定時間內處理完所有消息,主動調用 goAsync.finish() 方法結束當前的 Receiver **/ } finally { goAsync.finish(); } } }
原文鏈接:https://juejin.cn/post/7179800784904093755
相關推薦
- 2024-03-22 springboot報錯Error creating bean with name ‘dataSou
- 2023-01-01 MongoDB?Shell常用基本操作命令詳解_MongoDB
- 2022-11-26 React?數據獲取與性能優化詳解_React
- 2022-01-17 如何實現 input 和 textarea 自動聚焦
- 2022-06-30 Oracle對PL/SQL中的異常處理_oracle
- 2023-04-07 React?Fiber構建源碼解析_React
- 2022-06-22 Git配置用戶簽名方式及原因說明_其它綜合
- 2022-05-25 <C++>搞明白構造函數和析構函數有這一篇就夠了
- 最近更新
-
- window11 系統安裝 yarn
- 超詳細win安裝深度學習環境2025年最新版(
- Linux 中運行的top命令 怎么退出?
- MySQL 中decimal 的用法? 存儲小
- get 、set 、toString 方法的使
- @Resource和 @Autowired注解
- Java基礎操作-- 運算符,流程控制 Flo
- 1. Int 和Integer 的區別,Jav
- spring @retryable不生效的一種
- Spring Security之認證信息的處理
- Spring Security之認證過濾器
- Spring Security概述快速入門
- Spring Security之配置體系
- 【SpringBoot】SpringCache
- Spring Security之基于方法配置權
- redisson分布式鎖中waittime的設
- maven:解決release錯誤:Artif
- restTemplate使用總結
- Spring Security之安全異常處理
- MybatisPlus優雅實現加密?
- Spring ioc容器與Bean的生命周期。
- 【探索SpringCloud】服務發現-Nac
- Spring Security之基于HttpR
- Redis 底層數據結構-簡單動態字符串(SD
- arthas操作spring被代理目標對象命令
- Spring中的單例模式應用詳解
- 聊聊消息隊列,發送消息的4種方式
- bootspring第三方資源配置管理
- GIT同步修改后的遠程分支