我意识到该线程很旧，但是答案并不容易找到，可能有用。我花了很多时间弄清楚这些消息的含义。
Q1：批次
Pending alarm batches: 23
警报被分批组织。如文档中所述：
从API 19开始，传递给此方法的触发时间被视为不准确：警报不会在此时间之前发送，但可以推迟并在以后的某个时间发送。操作系统将使用此策略，以便在整个系统中将警报“批次”在一起，从而最大程度地减少设备“唤醒”所需的次数，并最大程度地减少电池消耗。一般而言，只要将来的警报时间长，就不会延迟不久的警报时间。
每批次可能有多个警报。在这种情况下，有23批警报，这意味着计划的警报可能超过23种。在dumpsys alarm输出中，描述每个批次的行如下所示：
Batch{4293d3a8 num=1 start=1369361 end=1407261}:
其中：
4293d3a8 是与批次关联的内部ID。num=1是该批次中的警报数。在这种情况下，批次中只有一个警报。- 在
start和end数字代表的是距今已有的系统进行最后重新启动的毫秒数在这篇文章中描述的，并且也大致代表在该批次中的报警器应该被触发的时间之窗。
Q2：警报
每个警报由三行描述，如下所示：
RTC #0: Alarm{4293d358 type 1 com.android.chrome}
type=1 whenElapsed=1369361 when=+19s304ms window=-1 repeatInterval=0 count=0
operation=PendingIntent{429e4500: PendingIntentRecord{429dbbc8 com.android.chrome broadcastIntent}}
其中：
- 的第一部分，这是一个
RTC_WAKEUP，RTC，ELAPSED_WAKEUP，或ELAPSED，表示type分别报警和对应的为整数值0-3，
#0是批处理，其中数字是从0到内报警的数量n-1，其中n在批量报警的数量。如果您的警报与其他警报一起批处理，则将来最远的“ when =”定义了该批警报中的所有警报将被触发的时间。4293d358 是与警报关联的内部ID号com.android.chrome 是设置警报的类的包名称type=1，警报的类型，请参见上面的第一个项目符号whenElapsed=1369361 是指自系统启动以来将触发此警报的毫秒数（大约）when=+19s304ms表示警报将在19秒（从dumpsys alarm调用之时起304毫秒）内触发。同样，类似的值+2d13h29m03s882ms表示未来2天13小时29分钟的相对时间window=表示与警报的批处理方法有关的两个内部常数之一。AlarmManager.WINDOW_EXACT=0和在使用setExact()或安排警报时设置setAlarmClock()。AlarmManager.WINDOW_HEURISTIC=-1并在使用安排了警报时设置setInexactRepeating()。否则，该值由API版本确定。对于API <19（KitKat），WINDOW_EXACT使用API => 19 WINDOW_HEURISTIC。（我必须深入研究AlarmManager.java源代码才能弄清楚这一点。）repeatInterval=900000警报重复的频率，例如每900000ms或15分钟。值为0表示警报不会重复。count=指应触发警报但并非出于某种原因触发警报的次数。0是个好数字。> 0表示由于某种原因跳过了警报。operation=PendingIntent{...}是对PendingIntent由警报触发的的引用。根据是否PendingIntent使用实例化getService，getBroadcast，getActivity，或者getActivities，报警器就会启动一个服务，发送广播，或启动一项或多项活动。
Q3：广播引用计数
为了找到有关此内容以及此后其他输出内容的信息，我不得不深入研究AlarmManagerService.java源代码。
为了使某些警报正常工作，必须唤醒设备，并且在发送完所有必需的广播之前，请勿使其进入睡眠状态。内部变量mBroadcastRefCount初始化为0，并随着要发送的广播排队而增加。发送每个广播时，它都会递减，当它恢复为0时，它会wakeLock被释放，并且设备可以重新进入睡眠状态。
Broadcast Ref Count: 0只是意味着在dumpsys alarm运行时，它不在发送任何广播的中间。
Q4：顶部警报
这是按警报代码运行的总合计时间，按降序排列的前十个警报。这可用于查找消耗最大系统资源的警报，例如查找可能会耗尽电池寿命的故障过程。
Q5：警报统计
此部分显示自上次重新启动系统以来已运行的所有警报的统计信息。在这里，您可以查看过去设置的警报是否已触发，是否唤醒了电话等。接下来将介绍这些条目的格式。
Q6：警报统计信息条目
警报统计信息条目如下所示：
com.example.someapp +1s857ms running, 0 wakeups:
+1s817ms 0 wakes 83 alarms: cmp={com.example.someapp/com.example.someapp.someservice}
+40ms 0 wakes 1 alarms: cmp={com.example.someapp/com.example.someapp.someotherservice}
第一行中的位置：
com.example.someapp 是触发警报的进程的程序包名称+1s857ms running 是进程消耗的系统总时间0 wakeups 是设备被这些警报之一唤醒的次数
然后每一行都引用已设置的警报之一，其中包括：
+1s817ms 是消耗的总系统时间0 wakes 是必须唤醒设备的次数83 alarms是触发警报的次数；对于重复的警报，此值仅> 1cmp={...} 触发警报时启动的服务
或者，如果警报触发了广播，则该条目可能类似于：
android +4m51s566ms running, 281 wakeups:
+2m46s583ms 0 wakes 1224 alarms: act=android.intent.action.TIME_TICK
+1m25s624ms 89 wakes 89 alarms: act=android.content.syncmanager.SYNC_ALARM
+52s898ms 0 wakes 41 alarms: act=com.android.server.action.NETWORK_STATS_POLL
...
与：
警报可能同时具有acmp={...}和act=...项，这意味着警报同时广播了意图并启动了服务。
概要
使用的输出调试android警报adb shell dumpsys alarm可能很棘手，并且没有中央位置dumpsys可以完全解释消息。警报如何组合在一起并不总是很明显，有时很难准确地在需要时触发服务或活动。希望这对尝试调试警报的人有用。