ANR

当 Android 应用的用户界面 (UI) 线程被阻塞太长时间时，会触发“应用程序无响应”(ANR) 错误。如果应用位于前台，系统会向用户显示一个对话框，如图 1 所示。ANR 对话框使用户有机会强制退出应用。

Figure 1. ANR dialog displayed to the user

图 1. 显示给用户的 ANR 对话框

ANR 是一个问题，因为负责更新 UI 的应用主线程无法处理用户输入事件或进行绘制，从而导致用户感到沮丧。有关应用主线程的更多信息，请参阅进程和线程。

当发生以下任一情况时，会为您的应用触发 ANR

输入分发超时：如果您的应用在 5 秒内未响应输入事件（例如按键或屏幕触摸）。
执行服务：如果您的应用声明的服务无法在几秒钟内完成执行Service.onCreate()和Service.onStartCommand()/Service.onBind()。
未调用 Service.startForeground()：如果您的应用使用Context.startForegroundService()在前台启动新服务，但服务随后未在 5 秒钟内调用startForeground()。
广播意图：如果BroadcastReceiver未在设定的时间内完成执行。如果应用在前台有任何活动，则此超时时间为 5 秒。
JobScheduler交互：如果一个JobService在几秒钟内没有从JobService.onStartJob()或JobService.onStopJob()返回，或者如果一个用户发起的作业启动并且您的应用在JobService.onStartJob()被调用后的几秒钟内没有调用JobService.setNotification()。对于目标平台为 Android 13 及以下的应用，ANR 是静默的，不会向应用报告。对于目标平台为 Android 14 及以上的应用，ANR 是明确的，并会向应用报告。

如果您的应用遇到 ANR，您可以使用本文档中的指导来诊断和解决问题。

检测问题

如果您已经发布了您的应用，您可以使用 Android Vitals 查看应用的 ANR 信息。您可以使用其他工具来检测现场的 ANR，但请注意，与 Android Vitals 不同，第三方工具无法在旧版 Android（Android 10 及以下版本）上报告 ANR。

Android 核心指标

Android Vitals 可以帮助您监控和改善应用的 ANR 率。Android Vitals 测量多种 ANR 率

ANR 率：每天活跃用户中遇到任何类型 ANR 的百分比。
用户感知 ANR 率：每天活跃用户中至少遇到一次用户感知 ANR的百分比。目前，只有类型为Input dispatching timed out的 ANR 被认为是用户感知的。
多次 ANR 率：每天活跃用户中至少遇到两次 ANR 的百分比。

每天活跃用户是指在一天内在一个设备上使用您的应用的唯一用户，可能跨多个会话。如果用户在同一天在多个设备上使用您的应用，则每个设备都会计入当天的活跃用户数。如果多个用户在同一天使用同一台设备，则计为一个活跃用户。

用户感知 ANR 率是核心指标，这意味着它会影响您的应用在 Google Play 上的发现率。它很重要，因为其统计的 ANR 总是发生在用户与应用交互时，从而造成最大的干扰。

Play 已为此指标定义了两个不良行为阈值

整体不良行为阈值：在所有设备型号中，至少有 0.47% 的每日活跃用户遇到用户感知 ANR。
每设备不良行为阈值：对于单个设备型号，至少有 8% 的每日用户遇到用户感知 ANR。

如果您的应用超过了整体不良行为阈值，则可能在所有设备上的发现率都会降低。如果您的应用在某些设备上超过了每设备不良行为阈值，则可能在这些设备上的发现率会降低，并且您的商店列表中可能会显示警告。

当您的应用出现过多的 ANR 时，Android Vitals 可以通过Play Console向您发出警报。

有关 Google Play 如何收集 Android Vitals 数据的信息，请参阅Play Console 文档。

诊断 ANR

在诊断 ANR 时，有一些常见的模式需要查找

应用在主线程上执行涉及 I/O 的缓慢操作。
应用在主线程上执行长时间计算。
主线程正在对另一个进程执行同步 Binder 调用，并且该其他进程需要很长时间才能返回。
主线程被阻塞，等待另一个线程上的长时间操作的同步块。
主线程与另一个线程发生死锁，无论是在您的进程中还是通过 Binder 调用。主线程不仅仅是在等待一个长时间的操作完成，而是在死锁状态。有关更多信息，请参阅维基百科上的死锁。

以下技术可以帮助您确定 ANR 的原因。

HealthStats

HealthStats 通过捕获总用户和系统时间、CPU 时间、网络、无线电统计信息、屏幕开/关时间和唤醒闹钟来提供有关应用程序健康状况的指标。这可以帮助衡量整体 CPU 使用率和电池消耗。

Debug

Debug 有助于在开发期间检查 Android 应用程序，包括跟踪和分配计数，以识别应用中的卡顿和延迟。您还可以使用Debug获取运行时和本机内存计数器，以及可以帮助识别特定进程内存占用量的内存指标。

ApplicationExitInfo

ApplicationExitInfo 在 Android 11（API 级别 30）或更高版本上可用，并提供有关应用程序退出原因的信息。这包括 ANR、内存不足、应用崩溃、过度 CPU 使用、用户中断、系统中断或运行时权限更改。

严格模式

使用StrictMode可以帮助您在开发应用时查找主线程上意外的 I/O 操作。您可以在应用程序或活动级别使用StrictMode。

启用后台 ANR 对话框

Android 仅当设备的开发者选项中启用了显示所有 ANR时，才会为处理广播消息花费过长时间的应用显示 ANR 对话框。出于这个原因，后台 ANR 对话框并不总是显示给用户，但应用仍然可能遇到性能问题。

Traceview

您可以在执行用例时使用 Traceview 获取正在运行的应用的跟踪，并识别主线程繁忙的位置。有关如何使用 Traceview 的信息，请参阅使用 Traceview 和 dmtracedump 进行性能分析。

拉取 traces 文件

Android 在遇到 ANR 时会存储跟踪信息。在较旧的操作系统版本上，设备上有一个单一的/data/anr/traces.txt文件。在较新的操作系统版本上，有多个/data/anr/anr_*文件。您可以使用Android 调试桥 (adb) 以 root 身份访问设备或模拟器上的 ANR 跟踪。

adb root
adb shell ls /data/anr
adb pull /data/anr/<filename>

您可以使用设备上的“获取错误报告”开发者选项或开发机器上的 adb bugreport 命令从物理设备捕获错误报告。有关更多信息，请参阅捕获和读取错误报告。

修复问题

确定问题后，您可以使用本节中的提示来修复常见问题。

主线程上的缓慢代码

确定应用的主线程繁忙超过 5 秒的代码位置。查找应用中可疑的用例，并尝试重现 ANR。

例如，图 2 显示了一个 Traceview 时间线，其中主线程繁忙超过 5 秒。

Figure 2. Traceview timeline showing a busy main
thread

图 2. 显示主线程繁忙的 Traceview 时间线

图 2 显示大多数违规代码发生在onClick(View) 处理程序中，如下面的代码示例所示

Kotlin

override fun onClick(v: View) {
    // This task runs on the main thread.
    BubbleSort.sort(data)
}

Java

@Override
public void onClick(View view) {
    // This task runs on the main thread.
    BubbleSort.sort(data);
}

在这种情况下，您应该将主线程中运行的工作移至工作线程。Android 框架包含可以帮助将任务移至工作线程的类。有关更多信息，请参阅工作线程。

主线程上的 IO

在主线程上执行 IO 操作是主线程上缓慢操作的常见原因，这会导致 ANR。建议将所有 IO 操作移至工作线程，如上一节所示。

一些 IO 操作的示例包括网络和存储操作。有关更多信息，请参阅执行网络操作和保存数据。

锁争用

在某些情况下，导致 ANR 的工作并非直接在应用的主线程上执行。如果工作线程持有主线程完成其工作所需资源的锁，则可能会发生 ANR。

例如，图 3 显示了一个 Traceview 时间线，其中大部分工作是在工作线程上执行的。

Figure 3. Traceview timeline that shows the work being executed on a worker
thread

图 3. 显示工作在工作线程上执行的 Traceview 时间线

但是，如果您的用户仍然遇到 ANR，则应查看 Android 设备监视器中主线程的状态。通常，如果主线程已准备好更新 UI 并且通常响应，则它处于RUNNABLE状态。

但是，如果主线程无法恢复执行，则它处于BLOCKED状态，无法响应事件。该状态在 Android 设备监视器上显示为监视器或等待，如图 5 所示。

Figure 4. Main thread in the Monitor
status

图 4. 处于监视器状态的主线程

以下跟踪显示了一个应用程序的主线程被阻塞，等待资源

...
AsyncTask #2" prio=5 tid=18 Runnable
  | group="main" sCount=0 dsCount=0 obj=0x12c333a0 self=0x94c87100
  | sysTid=25287 nice=10 cgrp=default sched=0/0 handle=0x94b80920
  | state=R schedstat=( 0 0 0 ) utm=757 stm=0 core=3 HZ=100
  | stack=0x94a7e000-0x94a80000 stackSize=1038KB
  | held mutexes= "mutator lock"(shared held)
  at com.android.developer.anrsample.BubbleSort.sort(BubbleSort.java:8)
  at com.android.developer.anrsample.MainActivity$LockTask.doInBackground(MainActivity.java:147)
  - locked <0x083105ee> (a java.lang.Boolean)
  at com.android.developer.anrsample.MainActivity$LockTask.doInBackground(MainActivity.java:135)
  at android.os.AsyncTask$2.call(AsyncTask.java:305)
  at java.util.concurrent.FutureTask.run(FutureTask.java:237)
  at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:243)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
  at java.lang.Thread.run(Thread.java:761)
...

查看跟踪可以帮助您找到阻塞主线程的代码。以下代码负责持有阻塞上一跟踪中主线程的锁

Kotlin

override fun onClick(v: View) {
    // The worker thread holds a lock on lockedResource
    LockTask().execute(data)

    synchronized(lockedResource) {
        // The main thread requires lockedResource here
        // but it has to wait until LockTask finishes using it.
    }
}

class LockTask : AsyncTask<Array<Int>, Int, Long>() {
    override fun doInBackground(vararg params: Array<Int>): Long? =
            synchronized(lockedResource) {
                // This is a long-running operation, which makes
                // the lock last for a long time
                BubbleSort.sort(params[0])
            }
}

Java

@Override
public void onClick(View v) {
    // The worker thread holds a lock on lockedResource
   new LockTask().execute(data);

   synchronized (lockedResource) {
       // The main thread requires lockedResource here
       // but it has to wait until LockTask finishes using it.
   }
}

public class LockTask extends AsyncTask<Integer[], Integer, Long> {
   @Override
   protected Long doInBackground(Integer[]... params) {
       synchronized (lockedResource) {
           // This is a long-running operation, which makes
           // the lock last for a long time
           BubbleSort.sort(params[0]);
       }
   }
}

另一个示例是应用程序的主线程正在等待工作线程的结果，如下面的代码所示。请注意，在 Kotlin 中使用wait()和notify()不是推荐的模式，它有自己的并发处理机制。使用 Kotlin 时，应尽可能使用 Kotlin 特定的机制。

Kotlin

fun onClick(v: View) {
    val lock = java.lang.Object()
    val waitTask = WaitTask(lock)
    synchronized(lock) {
        try {
            waitTask.execute(data)
            // Wait for this worker thread’s notification
            lock.wait()
        } catch (e: InterruptedException) {
        }
    }
}

internal class WaitTask(private val lock: java.lang.Object) : AsyncTask<Array<Int>, Int, Long>() {
    override fun doInBackground(vararg params: Array<Int>): Long? {
        synchronized(lock) {
            BubbleSort.sort(params[0])
            // Finished, notify the main thread
            lock.notify()
        }
    }
}

Java

public void onClick(View v) {
   WaitTask waitTask = new WaitTask();
   synchronized (waitTask) {
       try {
           waitTask.execute(data);
           // Wait for this worker thread’s notification
           waitTask.wait();
       } catch (InterruptedException e) {}
   }
}

class WaitTask extends AsyncTask<Integer[], Integer, Long> {
   @Override
   protected Long doInBackground(Integer[]... params) {
       synchronized (this) {
           BubbleSort.sort(params[0]);
           // Finished, notify the main thread
           notify();
       }
   }
}

还有一些其他情况可能会阻塞主线程，包括使用Lock、Semaphore的线程，以及资源池（例如数据库连接池）或其他互斥 (mutex) 机制。

您应该评估应用在一般情况下对资源持有的锁，但如果您想避免 ANR，则应查看主线程所需资源持有的锁。

确保锁保持的时间最短，或者更好的是，评估应用是否首先需要持有锁。如果您正在使用锁来确定何时根据工作线程的处理来更新 UI，请使用诸如 onProgressUpdate() 和 onPostExecute() 之类的机制在工作线程和主线程之间进行通信。

死锁

当一个线程进入等待状态，因为它需要的资源被另一个线程持有，而另一个线程也在等待第一个线程持有的资源时，就会发生死锁。如果应用的主线程处于这种情况，则很可能发生 ANR。

死锁是计算机科学中一个经过充分研究的现象，您可以使用死锁预防算法来避免死锁。

有关更多信息，请参阅维基百科上的死锁和死锁预防算法。

广播接收器速度缓慢

应用可以通过广播接收器响应广播消息，例如启用或禁用飞行模式或连接状态的更改。当应用处理广播消息花费的时间过长时，就会发生 ANR。

以下情况会发生 ANR

广播接收器在相当长的时间内未完成其 onReceive() 方法的执行。
广播接收器调用 goAsync() 并且未能对 PendingResult 对象调用 finish()。

您的应用应该只在 BroadcastReceiver 的 onReceive() 方法中执行简短的操作。但是，如果您的应用需要由于广播消息而进行更复杂的处理，则应将任务推迟到 IntentService。

您可以使用 Traceview 等工具来识别您的广播接收器是否在应用的主线程上执行长时间运行的操作。例如，图 6 显示了在主线程上处理消息大约 100 秒的广播接收器的时序图。

Figure 5. Traceview timeline showing the `BroadcastReceiver` work on the main
thread

图 5. 显示 BroadcastReceiver 在主线程上工作的 Traceview 时序图

此行为可能是由于在 BroadcastReceiver 的 onReceive() 方法中执行长时间运行的操作造成的，如下例所示

Kotlin

override fun onReceive(context: Context, intent: Intent) {
    // This is a long-running operation
    BubbleSort.sort(data)
}

Java

@Override
public void onReceive(Context context, Intent intent) {
    // This is a long-running operation
    BubbleSort.sort(data);
}

在类似情况下，建议将长时间运行的操作移至 IntentService，因为它使用工作线程来执行其工作。以下代码显示了如何使用 IntentService 处理长时间运行的操作

Kotlin

override fun onReceive(context: Context, intent: Intent) {
    Intent(context, MyIntentService::class.java).also { intentService ->
        // The task now runs on a worker thread.
        context.startService(intentService)
    }
}

class MyIntentService : IntentService("MyIntentService") {
    override fun onHandleIntent(intent: Intent?) {
        BubbleSort.sort(data)
    }
}

Java

@Override
public void onReceive(Context context, Intent intent) {
    // The task now runs on a worker thread.
    Intent intentService = new Intent(context, MyIntentService.class);
    context.startService(intentService);
}

public class MyIntentService extends IntentService {
   @Override
   protected void onHandleIntent(@Nullable Intent intent) {
       BubbleSort.sort(data);
   }
}

由于使用了 IntentService，因此长时间运行的操作在工作线程而不是主线程上执行。图 7 显示了在 Traceview 时序图中推迟到工作线程的工作。

Figure 6. Traceview timeline showing the broadcast message processed on a
worker thread

图 6. 显示在工作线程上处理广播消息的 Traceview 时序图

您的广播接收器可以使用 goAsync() 告知系统它需要更多时间来处理消息。但是，您应该对 PendingResult 对象调用 finish()。以下示例显示了如何调用 finish() 以便系统回收广播接收器并避免 ANR

Kotlin

val pendingResult = goAsync()

object : AsyncTask<Array<Int>, Int, Long>() {
    override fun doInBackground(vararg params: Array<Int>): Long? {
        // This is a long-running operation
        BubbleSort.sort(params[0])
        pendingResult.finish()
        return 0L
    }
}.execute(data)

Java

final PendingResult pendingResult = goAsync();
new AsyncTask<Integer[], Integer, Long>() {
   @Override
   protected Long doInBackground(Integer[]... params) {
       // This is a long-running operation
       BubbleSort.sort(params[0]);
       pendingResult.finish();
   }
}.execute(data);

但是，如果广播在后台运行，则将代码从缓慢的广播接收器移动到另一个线程并使用 goAsync() 不会修复 ANR。ANR 超时仍然适用。

GameActivity

在使用 C 或 C++ 编写的游戏和应用的案例研究中，GameActivity 库减少了 ANR。如果您用 GameActivity 替换现有的原生 Activity，则可以减少 UI 线程阻塞并防止某些 ANR 发生。

有关 ANR 的更多信息，请参阅保持应用响应。有关线程的更多信息，请参阅线程性能。

为您推荐

注意：当 JavaScript 关闭时，会显示链接文本
唤醒次数过多

下一步

崩溃