BugReport 概述

Android BugReport 中包含文本 (.txt) 格式的 dumpsys（转储系统）、dumpstate（转储状态）、Logcat 数据，便于轻松搜索特定内容。以下各部分详细说明了BugReport 的组成部分及常见问题，并提供了关于查找与这些错误相关的日志的实用提示和 grep 命令。

一、获取 BugReport

连接测试手机，进行相应测试后，打开终端，执行：$ adb shell bugreport > bugreport.txt

二、如何阅读 BugReport

1、Logcat
Logcat 日志是所有 Logcat 信息采用字符串形式的转储。其中，包括：System Log、Event Log 等。

（1）System Log 部分专门用于记录框架方面的信息，与包含所有其他内容的 main 部分相比，该部分包含更长时间内的记录。
每行都以 timestamp PID TID log-level 开头。
（2）Event Log 中包含将二进制格式转换成了字符串形式的日志消息。它比 Logcat 日志要清晰明了，但也有些难以阅读。在查看 Event Log时，可以在这一部分中搜索特定进程 ID (PID)，以查看相应进程一直在做什么。基本格式是：timestamp PID TID log-level log-tag tag-values。

注意：日志级别包括以下几种：
<1> V：详细
<2> D：调试
<3> I：信息
<4> W：警告
<5> E：错误

2、ANR（应用无响应）
BugReport 有助于找出导致 ANR 错误和死锁事件的原因。当某个应用在一定时间内没有响应（通常是由于主线程被阻塞或繁忙）时，系统会终止该进程，并将堆栈转储到 /data/anr。

（1）为了找出 ANR 背后的罪魁祸首，可以对二进制事件日志中的 am_anr 执行 grep 命令。

$ grep "am_anr" bugreport.txt
10-01 18:12:49.599  4600  4614 I am_anr : [0,29761,com.google.android.youtube,953695941,executing service com.google.android.youtube/com.google.android.apps.youtube.app.offline.transfer.OfflineTransferService]
10-01 18:14:10.211  4600  4614 I am_anr : [0,30363,com.google.android.apps.plus,953728580,executing service com.google.android.apps.plus/com.google.android.apps.photos.service.PhotosService]

（2）也可以对 Logcat 日志（包含关于发生 ANR 时，是什么在占用 CPU 的更多信息）中的 ANR in 执行 grep 命令。

$ grep "ANR in" bugreport.txt
10-01 18:13:11.984  4600  4614 E ActivityManager: ANR in com.google.android.youtube
10-01 18:14:31.720  4600  4614 E ActivityManager: ANR in com.google.android.apps.plus
10-01 18:14:31.720  4600  4614 E ActivityManager: PID: 30363
10-01 18:14:31.720  4600  4614 E ActivityManager: Reason: executing service com.google.android.apps.plus/com.google.android.apps.photos.service.PhotosService
10-01 18:14:31.720  4600  4614 E ActivityManager: Load: 35.27 / 23.9 / 16.18
10-01 18:14:31.720  4600  4614 E ActivityManager: CPU usage from 16ms to 21868ms later:
10-01 18:14:31.720  4600  4614 E ActivityManager:  74% 3361/mm-qcamera-daemon: 62% user + 12% kernel / faults: 15276 minor 10 major
10-01 18:14:31.720  4600  4614 E ActivityManager:  41% 4600/system_server: 18% user + 23% kernel / faults: 18597 minor 309 major
10-01 18:14:31.720  4600  4614 E ActivityManager:  32% 27420/com.google.android.GoogleCamera: 24% user + 7.8% kernel / faults: 48374 minor 338 major
10-01 18:14:31.720  4600  4614 E ActivityManager:  16% 130/kswapd0: 0% user + 16% kernel
10-01 18:14:31.720  4600  4614 E ActivityManager:  15% 283/mmcqd/0: 0% user + 15% kernel
...
10-01 18:14:31.720  4600  4614 E ActivityManager:  0.1% 27248/irq/503-synapti: 0%
10-01 18:14:31.721  4600  4614 I ActivityManager: Killing 30363:com.google.android.apps.plus/u0a206 (adj 0): bg anr

（3）查找堆栈轨迹
通常可以找到与 ANR 对应的堆栈轨迹。首先确保虚拟机轨迹上的 timeStamp 和 PID 与您正在调查的 ANR 相符，然后再检查进程的主线程。注意：
<1> 主线程只能了解发生 ANR 时，它在做什么，这可能是导致 ANR 的真正原因，也可能不是。（BugReport 中的堆栈可能是无辜的，可能有其它线程在恢复正常之前，粘滞了很长时间，但不足以导致 ANR。）
<2> 可能存在多组堆栈轨迹（VM TRACES JUST NOW 和 VM TRACES AT LAST ANR），要确保查看的是正确的部分。

（4）查找死锁
由于线程出现粘滞，死锁往往首先表现为 ANR。如果系统服务器发生死锁，监控定时器最终会将其终止，从而导致日志中出现类似以下的条目：WATCHDOG KILLING SYSTEM PROCESS。对于用户来说，他们看到的是设备重新启动，但从技术上来讲，这是运行时重启，而不是真正的设备重新启动。说明：
<1> 在运行时重启时，系统服务器已死机并会重启，并且用户会看到设备返回到显示启动动画。
<2> 在设备重新启动时，内核已崩溃，并且用户会看到设备返回到显示 Google 启动徽标。
要查找死锁，请检查 VM 跟踪部分中是否存在以下模式：线程 A 在等待线程 B 占用的某些资源，而线程 B 也在等待线程 A 占用的某些资源。

3、Activity
Activity 是一种应用组件，为用户提供一个可互动的屏幕，用来执行某些操作（如：拨号、拍照、发送电子邮件等）。从 BugReport 的角度来看，Activity 是用户可以执行的一项明确具体的操作，这使得查找在崩溃期间处于聚焦状态的 Activity 变得非常重要。Activity 通过 ActivityManager 运行进程，因此找出指定 Activity 的所有进程启动和停止事件也有助于进行问题排查。

（1）查看处于聚焦状态的 Activity 的历史记录：

$ grep "am_focused_activity" bugreport.txt
10-01 18:10:41.409  4600 14112 I am_focused_activity: [0,com.google.android.GoogleCamera/com.android.camera.CameraActivity]
10-01 18:11:17.313  4600  5687 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

（2）查看进程启动事件的历史记录

$ grep "Start proc" bugreport.txt
10-01 18:09:15.309  4600  4612 I ActivityManager: Start proc 24533:com.metago.astro/u0a240 for broadcast com.metago.astro/com.inmobi.commons.analytics.androidsdk.IMAdTrackerReceiver
10-01 18:09:15.687  4600 14112 I ActivityManager: Start proc 24548:com.google.android.apps.fitness/u0a173 for service com.google.android.apps.fitness/.api.services.ActivityUpsamplingService
10-01 18:09:15.777  4600  6604 I ActivityManager: Start proc 24563:cloudtv.hdwidgets/u0a145 for broadcast cloudtv.hdwidgets/cloudtv.switches.SwitchSystemUpdateReceiver
10-01 18:09:20.574  4600  6604 I ActivityManager: Start proc 24617:com.wageworks.ezreceipts/u0a111 for broadcast com.wageworks.ezreceipts/.ui.managers.IntentReceiver
...

（3）确定设备是否发生抖动，需检查在 am_proc_died 和 am_proc_start 前后的短时间内，是否出现 Activity 异常增多的情况。

$ grep -e "am_proc_died" -e "am_proc_start" bugreport.txt
10-01 18:07:06.494  4600  9696 I am_proc_died: [0,20074,com.android.musicfx]
10-01 18:07:06.555  4600  6606 I am_proc_died: [0,31166,com.concur.breeze]
10-01 18:07:06.566  4600 14112 I am_proc_died: [0,18812,com.google.android.apps.fitness]
10-01 18:07:07.018  4600  7513 I am_proc_start: [0,20361,10113,com.sony.playmemories.mobile,broadcast,com.sony.playmemories.mobile/.service.StartupReceiver]
10-01 18:07:07.357  4600  4614 I am_proc_start: [0,20381,10056,com.google.android.talk,service,com.google.android.talk/com.google.android.libraries.hangouts.video.CallService]
10-01 18:07:07.784  4600  4612 I am_proc_start: [0,20402,10190,com.andcreate.app.trafficmonitor:loopback_measure_serivce,service,com.andcreate.app.trafficmonitor/.loopback.LoopbackMeasureService]
10-01 18:07:10.753  4600  5997 I am_proc_start: [0,20450,10097,com.amazon.mShop.android.shopping,broadcast,com.amazon.mShop.android.shopping/com.amazon.identity.auth.device.storage.LambortishClock$ChangeTimestampsBroadcastReceiver]
10-01 18:07:15.267  4600  6605 I am_proc_start: [0,20539,10173,com.google.android.apps.fitness,service,com.google.android.apps.fitness/.api.services.ActivityUpsamplingService]
10-01 18:07:15.985  4600  4612 I am_proc_start: [0,20568,10022,com.android.musicfx,broadcast,com.android.musicfx/.ControlPanelReceiver]
10-01 18:07:16.315  4600  7512 I am_proc_died: [0,20096,com.google.android.GoogleCamera]

4、内存
由于 Android 设备的物理内存通常都存在限制，因此管理 RAM (随机存取存储器) 至关重要。BugReport 中包含一些用于指示内存不足的指标以及一个提供内存快照的 dumpstate。

（1）发现内存不足的情况
内存不足可能会导致系统发生抖动，这是因为虽然内存不足时，系统会终止某些进程来释放内存，但又会继续启动其它进程。如需查看内存不足的确凿证据，请检查二进制事件日志中的 am_proc_died 和 am_proc_start 条目的密集程度。
内存不足还可能会减慢任务切换速度，并且可能会阻止进行返回的尝试（因为用户尝试返回的任务已被终止）。如果启动器被终止，它会在用户触摸主屏幕按钮时重启，并且日志中会显示启动器重新加载其内容。
<1> 查看历史指标
二进制事件日志中的 am_low_memory 条目，表示最后一个缓存的进程已终止。在此之后，系统开始终止各项服务。

$ grep "am_low_memory" bugreport.txt
10-01 18:11:02.219  4600  7513 I am_low_memory: 41
10-01 18:12:18.526  4600 14112 I am_low_memory: 39
10-01 18:12:18.874  4600  7514 I am_low_memory: 38
10-01 18:12:22.570  4600 14112 I am_low_memory: 40
10-01 18:12:34.811  4600 20319 I am_low_memory: 43
10-01 18:12:37.945  4600  6521 I am_low_memory: 43
10-01 18:12:47.804  4600 14110 I am_low_memory: 43

<2> 查看抖动指标
关于系统抖动（分页、直接回收等）的其它指标，包括：kswapd、kworker、mmcqd 消耗周期。（ 注意：收集 BugReport 可能会影响抖动指标 ）
ANR 日志可以提供类似的内存快照。

（2）获取内存快照
内存快照是一种 dumpstate，其中会列出正在运行的 Java 进程和本机进程。（ 注意：快照仅提供特定时刻的状态，在此快照之前，系统的状况可能更好，也可能更糟。）

5、广播
应用会生成广播，以便在当前应用内或向其它应用发送事件。广播接收器可以（通过过滤器）订阅特定消息，以便收听和响应广播。BugReport 中包含已发送广播和未发送广播的相关信息，以及关于收听特定广播的所有接收器的 dumpsys。

（1）查看历史广播
历史广播（即：已发送的广播），按时间逆序排列。
<1> summary（摘要）部分，用于提供最近 300 个前台广播和最近 300 个后台广播的概况。

Historical broadcasts summary [foreground]:
  #0: act=android.intent.action.SCREEN_ON flg=0x50000010
    +1ms dispatch