dumpsys alarm 格式解读

    最近在搞应用唤醒排序，一致疑惑dumpsys alarm后的一些东西到底是什么意思？通过几番查阅资料，总结如下：

    在安卓adb root进如命令行后（没有root或者root群组的权限执行不了该命令 ），会吐出一串东西，大家可自行测试。一直不明白，这些格式是什么意思，今天搜索一下，stackvoerflow中找到了一个比较牛的答案，原文地址：

     http://stackoverflow.com/questions/28742884/answer/submit

    

    这里只做简单的翻译，和加一些个人的理解

1.  

Pending alarm batches: 48

当应用设置ALARM的时候，系统不会将这些ALARM在设置的准确时间内触发，而将用一种批量触发（batches mode）的策略，这样可以最小化地使系统从休眠状态醒来，最低程度地减少电池的消耗，即将一批触发时间接近的闹钟，压缩到某一个时间段内一起触发，而不是一个个触发，这样系统会很难休眠。

上面的字段则表示，有48个ALARM将被触发，dumpsys alarm 输出后，就是现实每一个闹钟的触发详情，如：

4293d3a8： 批处理模式下的内部ID号
num = 1：表示在该batch中，只有一个闹钟
start和end后的时间，表示自系统启动后，流逝的时间，该段时间粗略的表示，该闹钟会在start和end之间的时间触发

2.

    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}}

对于每一个alrm，都会有如上所示的三行解说

   
   RTC：表示ALARM的类型，一般有：RTC_WAKEUP, RTC, ELAPSED_WAKEUP, or ELAPSED每个类型代表的意思就不赘述了，有兴趣的         可以自己查阅资料
   #0：表示在该批量模式中，该ALARM的标号，取值0~n-1，n为该batch中alarm个数
  4293d358 ：闹钟的内部编号
  com.android.chrome：设置该闹钟的应用包名
  type=1：闹钟的类型，即第一条中提到的几个闹钟类型
  whenElapsed=1369361：该闹钟会在系统开机后，大概1369361后触发，这是大概时间
  when=+19s304ms：该闹钟会在执行完这条dumpsys alarm命令后，19秒304ms后触发
  window=：根据该alarm被调度的不同方法，设置不同的值，如果该alarm是   setExact()或setAlarmClock()方法调用的，该值为           AlarmManager.WINDOW_EXACT（=0），如果是 setInexactRepeating()，则赋值为AlarmManager.WINDOW_HEURISTIC（=-           1），然而A PI的level不同该值也不同，API小于19（KITKAT）的是WINDOW_EXACT，大于19的是WINDOW_HEURISTIC
  repeatInterval=900000：改闹钟的重复频率，900000ms后重复，0表示不重复
  count=：表示该alarm因为某些原因而被忽略了的次数，0表示没有被忽略过
  operation=PendingIntent{...}：与pendingIntent相关，该intent被实例化后，可以发送广播，启动服务，或者启动Activity，                                说白了就是唤醒应用的操作。

3.

Broadcast Ref Count: 0

     为了使得系统在醒来后，发送必要的广播帧，并且保证在所有的广播帧没有发送出去之前，系统不要进入睡眠状态，内部定义了一个变量： mBroadcastRefCount ，它的初始值是0，并且当需要发送的广播在队列配对的时候，该变量的值就会递增，发送一个广播后则递减，当减到0的时候，就会释放它持有的wakelock，而让系统进入休眠状态。

     所以，Broadcast Ref Count: 0 表示在运行dumpsys alarm的时刻，该时刻并没有广播要发送。

4.

top alarms：

根据应用的唤醒系统的时间排行，取最长时间的前十名，然后按照降序列出，有助于找出第三方app因为编程不规范，而导致极度耗电

5.

Alarm Stats

    列出所有系统中应用设置alarm的情况，可以排查设置的闹钟是否起作用了

    格式如下：

    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.someap：设置alarm的应用包名
    +1s857ms running：系统总体被该应用所有的alarm消耗的时间
    0 wakeups：设备被闹钟唤醒的次数

     接下来是每个alarm的情况：

    +1s817ms：该alarm消耗的时间
    0 wakes：设备被唤醒的次数
    83 alarms：alarm被触发的次数，重复闹钟，该值大于1
    cmp={...}：alarm被触发，则启动该服务，服务实例位置在{}中声明

    如果触发的是广播，则格式如：

     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
    ...

     act=...：发送广播的名称

    看完了之后，发现一切都清楚了，但是有个疑问，笔者一直没有搞清楚，那就是wakes的次数和alarm的次数到底有什么区别？是怎么区分的，如果有知道的，也希望告知一下。