診斷及修正 ANR

如果 Android 應用程式的 UI 執行緒封鎖時間過長，系統會傳送「應用程式無回應」(ANR) 錯誤。本頁將說明各種 ANR 類型、診斷方法，以及問題修正建議。這裡列出的所有預設逾時時間範圍都適用於 Android 開放原始碼計畫和 Pixel 裝置；這些時間可能會因原始設備製造商 (OEM) 而異。

請注意，在判斷 ANR 原因時，建議您區分系統和應用程式問題。

如果系統處於不良狀態，以下問題可能會導致 ANR：

• 系統伺服器暫時性問題會導致繫結器呼叫速度變慢。
• 系統伺服器和高裝置負載的問題會導致應用程式執行緒無法排程。

如果可以，您可以使用 Perfetto 追蹤記錄來區分系統和應用程式問題：

• 請查看 Perfetto 中的執行緒狀態軌，確認應用程式的主要執行緒是否已執行中或可執行。
• 查看 system_server 執行緒以找出鎖定爭用等問題。
• 如果是繫結器呼叫速度緩慢，請查看回覆執行緒 (如果有的話)，瞭解導致速度緩慢的原因。

輸入分派逾時

如果應用程式的主要執行緒沒有即時回應輸入事件 (例如滑動或按下按鍵)，就會發生輸入分派 ANR。由於輸入作業分派逾時發生時，應用程式位於前景，因此使用者幾乎隨時都會看到這些作業，且必須緩解這類情況。

預設逾時期限：5 秒。

輸入分派 ANR 事件通常是主要執行緒的問題所造成。如果主要執行緒因等待取得鎖定而遭到封鎖，容器執行緒也可能涉及這個情況。

為避免輸入分派 ANR，請遵循下列最佳做法：

• 請勿在主執行緒上執行封鎖或長時間執行的作業。建議您使用 StrictMode 來擷取主執行緒上的意外活動。
• 盡量減少主要執行緒和其他執行緒之間的鎖定爭用情形。
• 盡量減少主要執行緒上的非 UI 工作，例如處理廣播或執行服務時。

常見原因

以下列出一些常見的輸入調度 ANR 原因和建議修正方式。

原因	會發生的情況	修正建議
Binder 呼叫速度緩慢	主執行緒進行長時間的同步繫結器呼叫。	請將呼叫移出主執行緒，或在擁有 API 的情況下嘗試最佳化呼叫。
連續多個繫結器呼叫	主執行緒會發出許多連續同步繫結呼叫。	請勿在緊密迴圈中執行繫結器呼叫。
封鎖 I/O	主執行緒會封鎖 I/O 呼叫，例如資料庫或網路存取權。	將所有封鎖的 IO 移至主執行緒。
鎖定爭用	主執行緒因等待取得鎖定而遭到封鎖。	減少主執行緒和其他執行緒之間的鎖定爭用。最佳化其他執行緒中的緩慢程式碼。
昂貴的影格	在單一影格中轉譯太多內容，導致發生嚴重卡頓。	減少延遲影格的工作。請勿使用 n^2 演算法。使用有效率的元件處理捲動或分頁等項目，例如 Jetpack Paging 程式庫。
遭到其他元件封鎖	廣播接收器等其他元件正在執行中，並封鎖主執行緒。	請盡可能將非 UI 工作移出主執行緒。在其他執行緒上執行廣播接收器。
GPU 停止運作	GPU 停止運作是系統或硬體問題，會導致轉譯遭到封鎖，並導致輸入分派 ANR。	很抱歉，應用程式端通常沒有任何修正程式。請盡可能與硬體團隊聯絡以進行疑難排解。

如何偵錯

如要開始偵錯，請查看 Google Play 管理中心或 Firebase Crashlytics 中的 ANR 叢集簽名。叢集通常會包含可能導致 ANR 的熱門影格。

注意： 請忽略顯示「nativePollOnce」或「主要執行緒閒置中」的輸入分派 ANR 叢集。這通常與發生堆疊傾印時間太晚的 ANR 有關。這類錯誤通常無法採取行動，因此可忽略。一般來說，實際 ANR 問題會出現在其他叢集內，因此不會隱藏真實問題。詳情請參閱 nativePollOnce。

以下流程圖說明如何判斷造成輸入逾時分派 ANR 的原因。

圖 1：如何對輸入分派 ANR 進行偵錯。

Play Vitals 可以偵測部分常見的 ANR 原因並進行偵錯。舉例來說，如果 Vitals 偵測到鎖定爭用導致 ANR 情形，便可在 ANR 的「深入分析」部分摘要列出問題並建議修正方式。

圖 2 Play Vitals ANR 偵測功能。

沒有聚焦的視窗

雖然觸控等事件會按照命中測試而直接傳送至相關視窗，但鍵等事件需要目標。這個目標稱為「聚焦視窗」。每個螢幕只有一個聚焦的視窗，這通常是使用者目前互動的視窗。如果找不到聚焦的視窗，輸入內容會發出沒有聚焦的視窗 ANR。無聚焦的視窗 ANR 是一種輸入分派 ANR 類型。

預設逾時期限：5 秒。

常見原因

未聚焦的視窗 ANR 通常是由下列其中一個問題造成：

• 應用程式執行過多工作，速度太慢，無法繪製第一個影格。
• 主視窗無法聚焦。如果視窗被標記為 FLAG_NOT_FOCUSABLE，使用者就無法傳送鍵或按鈕事件到該視窗。

Kotlin

override fun onCreate(savedInstanceState: Bundle) {
  super.onCreate(savedInstanceState)
  setContentView(R.layout.activity_main)
  window.addFlags(WindowManager.LayoutParams.FLAG_FLAG_NOT_FOCUSABLE)
}

Java

@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  setContentView(R.layout.activity_main);
  getWindow().addFlags(WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE);
}

廣播接收器逾時

當廣播接收器未及時處理廣播訊息時，就會發生廣播接收器 ANR。如果同步接收器或接收器未呼叫 goAync()，逾時表示 onReceive() 並未及時完成。如為非同步接收器或呼叫 goAsync() 的接收器，逾時代表未及時呼叫 PendingResult.finish()。

廣播接收器經常在以下執行緒發生 ANR：

• 主執行緒 (如果問題是應用程式啟動速度緩慢)。
• 執行廣播接收器 (如果問題是緩慢 onReceive() 代碼) 的執行緒。
• 如果問題是緩慢 goAsync() 廣播代碼，請播送廣播工作站執行緒。

為避免廣播接收器 ANR，請遵循下列最佳做法：

• 請確保應用程式啟動速度很快，因為如果應用程式開始處理廣播，就會計入 ANR 逾時。
• 如果使用 goAsync()，請確保快速呼叫 PendingResult.finish()。因此會出現與同步廣播接收器相同的 ANR 逾時。
• 如果使用 goAsync()，請確保工作站執行緒未與其他長時間執行或封鎖的作業共用。
• 建議您使用 registerReceiver() 在非主執行緒中執行廣播接收器，以免封鎖在主執行緒中執行的 UI 程式碼。

逾時期限

廣播接收器逾時時間取決於是否已設定前景意圖旗標和平台版本。

意圖類型	Android 13 以下版本	Android 14 以上版本
前景優先意圖 (已設定 FLAG_RECEIVER_FOREGROUND)。	10 秒	10 至 20 秒 (視程序是否仰賴 CPU 處理而定)
背景優先意圖 (未設定 FLAG_RECEIVER_FOREGROUND)	60 秒	60 至 120 秒，視程序是否仰賴 CPU

如要確認 FLAG_RECEIVER_FOREGROUND 標記是否已設定，請在 ANR 主體中尋找「flg=」，並檢查是否存在 0x10000000。如果設定了這個位元，意圖就會設定 FLAG_RECEIVER_FOREGROUND，因此逾時時間會較短。

廣播逾時時間短 (10-20 秒) 的 ANR 主題示例：

Broadcast of Intent { act=android.inent.action.SCREEN_ON flg=0x50200010 }

廣播逾時過長 (60-120 秒) 的 ANR 主題示例：

Broadcast of Intent { act=android.intent.action.TIME_SET flg=0x25200010 }

廣播時間的評估方式

廣播時間長度測量作業會從 system_server 分派給應用程式，並在應用程式處理完廣播時結束。如果應用程式程序尚未執行，也需要在 ANR 逾時期間內進行冷啟動。因此，應用程式啟動速度緩慢可能會導致廣播接收器 ANR。

下圖說明廣播接收器 ANR 時間軸與特定應用程式程序一致。

圖 3. 廣播接收器 ANR 時間軸。

接收器完成播送作業後，ANR 逾時測量作業即結束；實際發生的時間取決於同步或非同步接收器。

• 如果是同步接收器，測量會在 onReceive() 傳回時停止。
• 如果是非同步接收器，測量會在呼叫 PendingResult.finish() 時停止。

圖 4 同步與非同步接收器的 ANR 逾時測量端點。

常見原因

以下是廣播接收器 ANR 的一些常見原因和建議修正方式。

原因	套用至	狀況說明	建議修正方式
應用程式啟動速度緩慢	所有接收器	應用程式進行冷啟動的時間過長。	最佳化應用程式啟動速度緩慢。
未排定onReceive()	所有接收器	廣播接收器執行緒忙於執行其他作業，因此無法啟動 onReceive() 方法。	請勿在接收器執行緒上執行長時間執行的工作，或是將接收器移至專屬執行緒。
onReceive()速度緩慢	所有接收器，但主要為同步接收器	onReceive() 方法已開始，但遭到封鎖或速度緩慢，因此並未及時完成。	最佳化速度緩慢的接收器程式碼。
未排定非同步接收者工作	goAsync() 個接收器	onReceive() 方法嘗試在已封鎖的工作站執行緒集區上執行工作，因此工作從未啟動。	針對慢速或封鎖的呼叫進行最佳化，或針對廣播工作站與其他長時間執行的工作使用不同的執行緒。
工作站速度緩慢或遭到封鎖	goAsync() 個接收器	處理廣播訊息時，工作站執行緒集區中的某個位置有封鎖或速度緩慢的作業。因此，系統不會及時呼叫 PendingResult.finish。	最佳化速度緩慢的 async 接收器程式碼。
忘記打電話給PendingResult.finish	goAsync() 個接收器	程式碼路徑中缺少對 finish() 的呼叫。	確保系統一律會呼叫 finish()。

如何偵錯

根據叢集簽章和 ANR 報告，您可以找出接收端使用的執行緒，以及遺失或執行速度緩慢的特定程式碼。

注意： 請勿忽略顯示「nativePollOnce」或「main 加強執行緒閒置」的廣播接收器 ANR 叢集。Google Play 管理中心和 Firebase Crashlytics 中 ANR 簽名內的堆疊通常是透過主執行緒建構，但廣播接收器可能會在非主執行緒或呼叫 goAsync() 上執行。因此，您還是能透過查看堆疊傾印中的相關執行緒，對這些叢集執行操作。

以下流程圖說明如何判斷廣播接收器 ANR 發生的原因。

圖 5. 如何對廣播接收器 ANR 進行偵錯。

找出接收者代碼

Google Play 管理中心會在 ANR 簽名中顯示接收器類別和廣播意圖。請找出以下項目：

• cmp=<receiver class>
• act=<broadcast_intent>

以下是廣播接收器 ANR 簽名的範例：

com.example.app.MyClass.myMethod
Broadcast of Intent { act=android.accounts.LOGIN_ACCOUNTS_CHANGED
cmp=com.example.app/com.example.app.MyAccountReceiver }

找出執行 onReceive() 方法的執行緒

如果您使用 Context.registerReceiver 指定自訂處理常式，即為執行此處理常式的執行緒。否則，就是主要執行緒。

例如：未排定非同步接收器工作

本節將逐步示範如何對廣播接收器 ANR 進行偵錯。

假設 ANR 簽名如下所示：

com.example.app.MyClass.myMethod
Broadcast of Intent {
act=android.accounts.LOG_ACCOUNTS_CHANGED cmp=com.example.app/com.example.app.MyReceiver }

根據簽章，廣播意圖看起來像是 android.accounts.LOG_ACCOUNTS_CHANGED，而接收器類別是 com.example.app.MyReceiver。

在接收器程式碼中，您可以判斷執行緒集區「BG Thread [0,1,2,3]」負責處理此廣播訊息。查看堆疊傾印時，您可以看到四個背景 (BG) 執行緒都具有相同的模式：這些執行緒執行封鎖呼叫 getDataSync。由於所有 BG 執行緒都忙碌中，系統無法及時處理廣播訊息，進而導致 ANR。

BG Thread #0 (tid=26) Waiting

at jdk.internal.misc.Unsafe.park(Native method:0)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:211)
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture:563)
at com.google.common.util.concurrent.ForwardingFuture.get(ForwardingFuture:68)
at com.example.app.getDataSync(<MyClass>:152)

...

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
at com.google.android.libraries.concurrent.AndroidExecutorsModule.lambda$withStrictMode$5(AndroidExecutorsModule:451)
at com.google.android.libraries.concurrent.AndroidExecutorsModule$$ExternalSyntheticLambda8.run(AndroidExecutorsModule:1)
at java.lang.Thread.run(Thread.java:1012)
at com.google.android.libraries.concurrent.ManagedPriorityThread.run(ManagedPriorityThread:34)

There are several approaches to fix the issue:

• Find out why getDataSync is slow and optimize.
• Don't run getDataSync on all four BG threads.
• More generally, ensure that the BG thread pool isn't saturated with long-running operations.
• Use a dedicated thread pool for goAsync worker tasks.
• Use an unbounded thread pool instead of the bounded BG thread pool

Example: slow app startup

A slow app startup can cause several types of ANRs, especially broadcast receiver and execute service ANRs. The cause of an ANR is likely slow app startup if you see ActivityThread.handleBindApplication in the main thread stacks.

Execute service timeout

An execute service ANR happens when the app's main thread doesn't start a service in time. Specifically, a service doesn't finish executing onCreate() and onStartCommand() or onBind() within the timeout period.

Default timeout period: 20 seconds for foreground service; 200 seconds for background service. The ANR timeout period includes the app cold start, if necessary, and calls to onCreate(), onBind(), or onStartCommand().

To avoid execute service ANRs, follow these general best practices:

• Make sure that app startup is fast, since it's counted in the ANR timeout if the app is started to run the service component.
• Make sure that the service's onCreate(), onStartCommand(), and onBind() methods are fast.
• Avoid running any slow or blocking operations on the main thread from other components; these operations can prevent a service from starting quickly.

Common causes

The following table lists common causes of execute service ANRs and suggested fixes.

Cause	What	Suggested fix
Slow app startup	The app takes too long to perform a cold start.	Optimize slow app start.
Slow onCreate(), onStartCommand(), or onBind()	The service component's onCreate(), onStartCommand(), or onBind() method takes too long to execute on the main thread.	Optimize slow code. Move slow operations off the critical path where possible.
Not scheduled (main thread blocked before onStart())	The app's main thread is blocked by another component before the service can be started.	Move other component's work off the main thread. Optimize other component's blocking code.

How to debug

From the cluster signature and ANR report in Google Play Console or Firebase Crashlytics, you can often determine the cause of the ANR based on what the main thread is doing.

Note: Ignore execute service ANR clusters that say "nativePollOnce" or "main thread idle." These usually correspond to ANRs where the stack dump is taken too late, and are generally not actionable. The actual ANR issues are usually present in other clusters, so real issues aren't being hidden. See nativePollOnce for more details.

The following flow chart describes how to debug an execute service ANR.

Figure 6. How to debug an execute service ANR.

If you've determined that the execute service ANR is actionable, follow these steps to help resolve the issue:

1. Find the service component class in the ANR signature. In Google Play Console, the service component class is shown in the ANR signature. In the following example ANR details, it's com.example.app/MyService.

   com.google.common.util.concurrent.Uninterruptibles.awaitUninterruptibly
   Executing service com.example.app/com.example.app.MyService
   

2. Determine whether the slow or block operation is part of app startup, the service component, or elsewhere by checking for the following important function call(s) in the main threads.

   Function call(s) in main thread stacks	What it means
   android.app.ActivityThread.handleBindApplication	App was starting up, so the ANR was caused by slow app start.
   <ServiceClass>.onCreate() [...] android.app.ActivityThread.handleCreateService	Service was being created, so the ANR was likely caused by slow onCreate() code.
   <ServiceClass>.onBind() [...] android.app.ActivityThread.handleBindService	Service was being bound, so the ANR was likely caused by slow onBind() code.
   <ServiceClass>.onStartCommand() [...] android.app.ActivityThread.handleServiceArgs	Service was being started, so the ANR was likely caused by slow onStartCommand() code.

   For example, if the onStartCommand() method in the MyService class is slow, the main threads will look like this:

   at com.example.app.MyService.onStartCommand(FooService.java:25)
   at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:4820)
   at android.app.ActivityThread.-$$Nest$mhandleServiceArgs(unavailable:0)
   at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2289)
   at android.os.Handler.dispatchMessage(Handler.java:106)
   at android.os.Looper.loopOnce(Looper.java:205)
   at android.os.Looper.loop(Looper.java:294)
   at android.app.ActivityThread.main(ActivityThread.java:8176)
   at java.lang.reflect.Method.invoke(Native method:0)
   

   如果您沒有看到任何重要的函式呼叫，則還有以下其他選項：

   • 服務正在執行或關機，這表示堆疊的處理時間太晚。在這種情況下，您可以忽略 ANR 視為偽陽性。
   • 正在執行其他應用程式元件，例如廣播接收器。在這種情況下，主要執行緒可能會遭到封鎖，導致服務無法啟動。

3. 如果您看見關鍵函式呼叫，且能確定 ANR 一般發生的位置，請查看主要執行緒堆疊的其餘部分，找出慢速作業並進行最佳化，或將其移至關鍵路徑。

如要進一步瞭解服務，請參閱以下頁面：

• 服務總覽
• 前景服務
• Service

內容供應器沒有回應

遠端內容供應器回應查詢的逾時時間超過逾時時間並終止，就會發生內容供應器 ANR。

預設逾時期間：內容供應器使用 ContentProviderClient.setDetectNotResponding 指定。ANR 逾時期限包含遠端內容供應器查詢的執行時間總時間，包括在未執行的情況下冷啟動遠端應用程式。

為避免內容供應器 ANR，請遵循下列最佳做法：

• 請確保應用程式啟動速度很快，因為如果應用程式開始執行內容供應器，就會計入 ANR 逾時。
• 確保內容供應器查詢快速。
• 請勿執行會封鎖所有應用程式繫結器執行緒的大量並行封鎖繫結呼叫。

常見原因

下表列出內容供應器 ANR 的常見原因和建議的修正方式。

原因	會發生的情況	訊號	建議修正方式
內容供應器查詢速度緩慢	內容供應器執行時間過長或已遭封鎖。	android.content.ContentProvider$Transport.query 影格位於繫結器執行緒中。	最佳化內容供應器查詢。找出封鎖繫結器執行緒的原因。
應用程式啟動速度緩慢	內容供應者的應用程式啟動時間過長。	ActivityThread.handleBindApplication 影格位於主執行緒中。	最佳化應用程式啟動。
繫結機制中斷：所有繫結機制執行緒皆忙碌中	所有繫結器執行緒都忙於處理其他同步要求，因此內容供應器繫結器呼叫無法執行。	應用程式不會啟動，所有繫結器執行緒都忙碌中，且內容供應器並未執行。	減少繫結器執行緒的負載。也就是說，減少同步傳出繫結器呼叫的數量，或是處理來電時的工作量。

如何偵錯

如要使用 Google Play 管理中心或 Firebase Crashlytics 中的叢集簽章和 ANR 報告對內容供應器 ANR 進行偵錯，請查看主要執行緒和繫結器執行緒正在執行的操作。

以下流程圖說明瞭如何對內容供應器 ANR 進行偵錯：



圖 7. 如何對內容供應器 ANR 進行偵錯。

下列程式碼片段顯示因內容供應器查詢速度緩慢而遭到封鎖時，繫結器執行緒的外觀。在這種情況下，內容供應器查詢在開啟資料庫時正在等待鎖定。

binder:11300_2 (tid=13) Blocked

Waiting for osm (0x01ab5df9) held by at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers:182)
at com.example.app.MyClass.blockingGetOpenDatabase(FooClass:171)
[...]
at com.example.app.MyContentProvider.query(MyContentProvider.java:915)
at android.content.ContentProvider$Transport.query(ContentProvider.java:292)
at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:107)
at android.os.Binder.execTransactInternal(Binder.java:1339)
at android.os.Binder.execTransact(Binder.java:1275)

下列程式碼片段顯示當主執行緒因應用程式啟動速度緩慢而遭封鎖時的外觀。在此情況下，應用程式啟動速度會因為 Dagger 初始化期間發生鎖定爭用情形。

main (tid=1) Blocked

[...]
at dagger.internal.DoubleCheck.get(DoubleCheck:51)
- locked 0x0e33cd2c (a qsn)at dagger.internal.SetFactory.get(SetFactory:126)
at com.myapp.Bar_Factory.get(Bar_Factory:38)
[...]
at com.example.app.MyApplication.onCreate(DocsApplication:203)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1316)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6991)
at android.app.ActivityThread.-$$Nest$mhandleBindApplication(unavailable:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2235)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at android.app.ActivityThread.main(ActivityThread.java:8170)
at java.lang.reflect.Method.invoke(Native method:0)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:971)

工作回應速度緩慢

當應用程式回應 JobService.onStartJob() 或 JobService.onStopJob() 的時間過長，或使用 JobService.setNotification() 提供通知的時間過長，工作回應 ANR 就會緩慢。這表示應用程式的主執行緒遭到封鎖，無法執行其他操作。

如果問題是 JobService.onStartJob() 或 JobService.onStopJob()，請檢查主要執行緒上的狀況。如果是 JobService.setNotification() 的問題，請務必盡快呼叫。發送通知前，不要完成太多工作。

神秘 ANR

有時候，您無法確定發生 ANR 的原因，或是在叢集簽名和 ANR 報告中資訊不足，無法對其進行偵錯。在這類情況下，您依然可以採取一些步驟，判斷 ANR 是否可行。

訊息佇列閒置或 nativePollOnce

如果您在堆疊中看到頁框 android.os.MessageQueue.nativePollOnce，通常表示疑似無回應的執行緒其實是閒置，並正在等待循環訊息。Google Play 管理中心的 ANR 詳細資料如下所示：

Native method - android.os.MessageQueue.nativePollOnce
Executing service com.example.app/com.example.app.MyService

舉例來說，如果主要執行緒處於閒置狀態，堆疊顯示如下：

"main" tid=1 NativeMain threadIdle

#00  pc 0x00000000000d8b38  /apex/com.android.runtime/lib64/bionic/libc.so (__epoll_pwait+8)
#01  pc 0x0000000000019d88  /system/lib64/libutils.so (android::Looper::pollInner(int)+184)
#02  pc 0x0000000000019c68  /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+112)
#03  pc 0x000000000011409c  /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
at android.os.MessageQueue.nativePollOnce (Native method)
at android.os.MessageQueue.next (MessageQueue.java:339)  at android.os.Looper.loop (Looper.java:208)
at android.app.ActivityThread.main (ActivityThread.java:8192)
at java.lang.reflect.Method.invoke (Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:626)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1015)

可疑的無回應執行緒可能處於閒置狀態的原因有以下幾種：

• Late Stack dump從 ANR 觸發和轉儲堆疊之間的短時間內復原執行緒。Android 13 的 Pixel 延遲時間約 100 毫秒，但可能超過 1 秒。Android 14 的 Pixel 延遲時間通常低於 10 毫秒。
• 討論串歸因錯誤。用來建構 ANR 簽名的執行緒，並不是導致 ANR 的實際無回應執行緒。在這種情況下，請嘗試判斷 ANR 是否為以下類型之一：
  • 廣播接收器逾時
  • 內容供應器沒有回應
  • 沒有聚焦的視窗
• 整個系統的問題。由於系統負載過高或系統伺服器發生問題，導致程序未排定時間。

沒有堆疊框架

部分 ANR 報告不包含有 ANR 的堆疊，也就是說，在產生 ANR 報告時，堆疊傾印失敗。缺少堆疊框架的可能原因如下：

• 堆疊呼叫時間過長和逾時。
• 程序在拿到堆疊之前就已經結束或遭終止。

[...]

--- CriticalEventLog ---
capacity: 20
timestamp_ms: 1666030897753
window_ms: 300000

libdebuggerd_client: failed to read status response from tombstoned: timeout reached?

----- Waiting Channels: pid 7068 at 2022-10-18 02:21:37.<US_SOCIAL_SECURITY_NUMBER>+0800 -----

[...]

叢集簽名或 ANR 報告無法針對不含堆疊框架的 ANR 事件採取因應措施。如要偵錯，請查看應用程式的其他叢集，因為如果問題夠大，我們通常會有自己的叢集，其中存在堆疊框架。或者，您也可以查看 Perfetto 追蹤記錄。

已知問題

由於系統會以非同步方式監控 ANR，因此在應用程式程序中保留計時器，以便在 ANR 觸發條件發生前完成廣播處理方式，因此可能無法正常運作。