Alarm用于实现Android中的定时任务,在Android的各个架构层次都有广泛的应用,和timer不同的是,timer在系统休眠后不会触发,而alarm在系统休眠后,可以借助RTC唤醒系统。在功耗调试过程中,也会遇到alarm频繁唤醒系统导致功耗高的情况,所以梳理alarm的整体流程是有必要的。本文主要介绍alarm整体流程和从功耗角度关注的部分细节,如alarm唤醒类型,alarm对齐,alarm suspend处理等。
Alarm整体架构如下,framework层对外提供接口,对内实现具体功能和策略,如alarm创建、处理和对齐等,并通过jni与native通信,native层通过系统调用进入kernel层。不同类型的alarm,在framework层体现在参数不同,具体差异处理在kernel层,如对唤醒和非唤醒alarm的处理,在kernel层体现在是否设置alarm到RTC,具体流程在后面进行阐述。
根据是否可唤醒系统,使用相对时间或绝对时间,alarm type分为下面四类
对于这四类alarm的详细解释,参考代码中注释
RTC_WAKEUP: (wall clock time in UTC), which will wake up the device when it goes off
RTC: (wall clock time in UTC). This alarm does not wake the device up; if it goes off while the device is asleep, it will not be delivered until the next time the device wakes up.
ELAPSED_REALTIME_WAKEUP: (time since boot, including sleep), which will wake up the device when it goes off.
ELAPSED_REALTIME: (time since boot, including sleep). This alarm does not wake the device up; if it goes off while the device is asleep, it will not be delivered until the next time the device wakes up.
4.1 主要接口
在AlarmManager中提供了对外使用的接口,如
设置一次性闹钟:
public void set(int type, long triggerAtMillis, PendingIntent operation)
设置重复闹钟
public void setRepeating(int type, long triggerAtMillis, long intervalMillis, PendingIntent operation)
设置精确闹钟
public void setExact(int type, long triggerAtMillis, PendingIntent operation)
4.2 主要流程
与alarm设置相关的主要流程有:
1) 初始化,创建epoll监听alarm触发状态等;
2) alarm设置,通过AlarmManager中的接口创建alarm后,经过对触发时间的检查、alarm对齐等操作,最终通过setAlarm()设置到native层;
3) alarm处理,当有alarm触发时,epoll监测到状态变化后,在AlarmThread中进行处理与分发,在while(true)里面一直持续等待alarm触发并处理。由于alarm对齐功能,所以一次可能处理多个alarm。
4.3 alarm对齐
alarm使用者可以设置精准模式和非精准模式的alarm,对于非精准模式的alarm,每个alarm根据其触发时间和最大触发时间加入到不同的batch中,同一个batch的alarm同时触发,可以减少设备被唤醒次数,达到节省功耗的目的。
对于精准alarm,单独添加一个batch,以保证alarm唤醒时间的精确性。
4.3.1 batch初始化
当一个alarm找不到合适的batch加入时,会创建一个新的batch并加入,使用该alarm的触发时间和最大触发时间作为batch的初始mStart和mEnd值,作为时间边界。
触发时间与最大触发时间的计算:
触发时间 mWhenElapsed:取minTrigger时间和nominalTrigger时间的最大值。其中minTrigger时间为系统启动到现在时间的时间长度,如果是应用程序(UID>10000)设置的该alarm,则再加上5秒;nominalTrigger为从系统启动到alarm设置的触发时间的时间长度。所以这里取最大值,实际上是限制了应用程序频繁的设置alarm,需要至少间隔5秒。
最大触发时间 mMaxWhenElapsed = mWhenElapsed + windowLength
对于精准alarm,windowLength = WINDOW_EXACT = 0,所以触发时间和最大触发时间相等,保证alarm触发的精确性。
4.3.2 alarm加入batch条件
alarm符合下面条件则加入现有batch:
a) 非精准alarm;
b) alarm触发时间mWhenElapsed小于等于batch结束时间mEnd,并且alarm最大触发时间mMaxWhenElapsed大于等于batch起始时间mStart。保证在batch的时间边界内能满足alarm的触发时间。
4.3.3 alarm加入batch后的时间边界调整
Batch的时间边界(mStart、mEnd)不是一直保持不变的,在有alarm加入后,会进行动态调整。总的来说是边界缩小的一个过程,如下图所示,不再赘述。
从下面这段代码和注释也可以看到,在batch时间边界变化后,会调整其在batches链表中的位置,因为所有batch按照开始时间在batches链表中成升序排列。
5.1系统调用
native层通过系统调用进入kernel层,主要用到的系统调用有如下几个:
SYSCALL_DEFINE2(timerfd_create, int, clockid, int, flags); //初始化
SYSCALL_DEFINE4(timerfd_settime, int, ufd, int, flags, const struct itimerspec __user *, utmr, struct itimerspec __user *, otmr); //设置alarm
SYSCALL_DEFINE2(timerfd_gettime, int, ufd, struct itimerspec __user *, otmr); //获取alarm时间
5.2 alarm设置
frameworks 层的setAlarm()最终通过timerfd_settime()系统调用到达kernel层
5.2.1 timerfd_settime()系统调用关键流程
alarm设置系统调用主要流程如下图所示,主要展示的是通过isalarm()判断是否为唤醒类型的alarm后,如何做不同的处理,在5.2.2小节详细描述。
5.2.2 kernel层对唤醒和非唤醒alarm的处理
frameworks 层的alarm type与kernel层的clockid有如下对应关系
frameworks层带后缀” _WAKEUP”的alarm类型是可以唤醒系统的,对应到kernel层为带后缀” _ALARM”的clockid
对于非唤醒alarm(CLOCK_REALTIME、CLOCK_BOOTTIME),通过设置hrtimer来实现;
对于唤醒alarm(CLOCK_REALTIME_ALARM、CLOCK_BOOTTIME_ALARM),仍然要设置hrtimer,但是和非唤醒alarm不同的是会多一个入队列操作(alarmtimer_enqueue()),主要作用是suspend时,将该alarm从队列取出,再设置到RTC,当alarm时间到期后,通过RTC中断唤醒系统。
5.3 suspend休眠过程对alarm的处理
alarmtimer_suspend()中关键逻辑:
1) 从timer queue中取出超时时间最近的alarm(在alarm_start()中入队)
,设置对应alarm到RTC,实现从suspend中唤醒功能;
2) 如果选出的超时时间最近的alarm,在2秒之内即将触发,则会设置系统继续保持2秒的唤醒状态,以避免频繁的休眠唤醒。
5.4 alarm触发
AlarmThread会一直循环等待alarm的触发,不管是hrtimer或者RTC中断的触发函数,最终都会调用到timerfd_triggered(),触发epoll,上报到framework层进行处理。
5.5 非系统/应用设置的alarm
除了通过AlarmManager中的接口设置alarm,在kernel层及hardware层还可以分别通过 alarm_start()和timerfd_settime()来设置alarm,如下示例,在某驱动中通过alarm_start()设置alarm来满足定时的需求。
在功耗调试过程中,alarm唤醒对电流有一定的影响,通常需要检查alarm是否预期和可优化,如下示例中,频繁的alarm唤醒对待机电流产生了较大的影响。
1) 待机电流65mA,明显偏大,从电流波形图看有很多毛刺,初步判断由于频繁唤醒导致;
2) 从kernel log看有频繁的alarm唤醒;
[ 596.785361] PM: suspend entry
[ 597.212284] gic_show_resume_irq: 302 triggered 7781b8.qcom,mpm
[ 597.212284] gic_show_resume_irq: 170 triggered null
[ 597.212284] PM: Calling msm_pinctrl_resume+0x0/0x190
[ 597.212284] PM: Calling spmi_pmic_arb_resume+0x0/0x34
[ 597.212284] spmi_show_resume_irq: 403 triggered [0x0, 0x61, 0x1] qpnp_rtc_alarm
[ 597.455898] PM: suspend exit
3) 从dumpsys alarm看到GMS有频繁的alarm唤醒
Alarm Stats:
u0a21:com.google.android.gms +1m7s937ms running, 432 wakeups:
+36s855ms 37 wakes 37 alarms, last -3m22s840ms:
*walarm*:com.google.android.intent.action.GCM_RECONNECT
4) 去掉GMS包后,电流毛刺明显减少,待机电流得到明显改善,下降到8mA左右。
本文介绍了alarm主要流程,alarm设置和触发、alarm对齐以及唤醒和非唤醒alarm的不同处理等内容,可以为学习和调试alarm提供参考。
1.https://blog.csdn.net/weixin_50019298/article/details/121307485 《Android中Alarm的机制》
2. https://www.jianshu.com/p/e81fac39023b 《Android电源管理-AlarmManager》
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8