PM特点
Wakelock机制
WakeLock是一种锁的机制,只要有人拿着这个锁,系统就无法进入休眠&＃xff08;这里的休眠&＃xff0c;指的是标准的Linux的休眠&＃xff0c;不包含使用early_suspend&＃xff08;&＃xff09;进行休眠的设备&＃xff0c;使用early_suspend()的设备&＃xff0c;在系统还有wake_lock锁的时候&＃xff0c;也是要休眠的&＃xff09;,可以被用户态程序和内核获得.这个锁可以是有超时的或者是没有超时的,超时的锁会在时间过去以后自动解锁.
如果没有锁了或者超时了,内核就会启动休眠的那套机制来进入休眠.
PowerManager.WakeLoc有加锁和解锁两种状态&＃xff0c;加锁的方式有两种&＃xff0c;一种是永久的锁住&＃xff0c;这样的锁除非显式的放开&＃xff0c;是不会解锁的&＃xff0c;所以这种锁用起来要非常的小心。第二种锁是超时锁&＃xff0c;这种锁会在锁住后一段时间解锁。
在创建了 PowerManager.WakeLock 后&＃xff0c;有两种机制&＃xff0c;第一种是不计数锁机制&＃xff0c;另一种是计数锁机制。可以通过 setReferenceCounted(boolean value) 来指定&＃xff0c;一般默认为计数机制。这两种机制的区别在于&＃xff0c;前者无论 acquire() 了多少次&＃xff0c;只要通过一次 release()即可解锁。而后者正真解锁是在&＃xff08; --count&＃61;&＃61; 0 &＃xff09;的时候&＃xff0c;同样当 (count&＃61;&＃61;0) 的时候才会去申请加锁&＃xff0c;其他情况 isHeld 状态是不会改变的。所以 PowerManager.WakeLock 的计数机制并不是正真意义上的对每次请求进行申请&＃xff0f;释放每一把锁&＃xff0c;它只是对同一把锁被申请&＃xff0f;释放的次数进行了统计再正真意义上的去操作。一下进行了永久锁的测试&＃xff1a; 从测试我们可以看到使用计数和计数锁的区别。
(一).内核维护了:
1).两个链表&＃xff0c;active_wake_locks[WAKE_LOCK_TYPE_COUNT]
active_wake_locks[0]维护的是suspendlock.
active_wake_locks[1]维护的是idlelock.
2).一个链表&＃xff0c;inactive_locks来记录所有处于inactive状态的锁.
(二).下面讲述应用层申请的锁怎么传到kernel下面的&＃xff0c;来理解整个wakelock的框架。
比如/sys/power/wake_lock下面的PowerManagerService
的生成过程。
1).Android 提供了现成android.os.PowerManager类,类中
提供newWakeLock(intflags, String tag)方法来取得相应
层次的锁&＃xff0c;此函数的定义
frameworks/base/core/java/android/os/PowerManager.java下面&＃xff0c;应用程序在申请wake_lock时都会有调用。
实例&＃xff1a;
PowerManagerpm &＃61;(PowerManager)getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLockwl &＃61; pm.newWakeLock
(PowerManager.SCREEN_DIM_WAKE_LOCK, “MyTag”);
wl.acquire();//申请锁这个里面会调用PowerManagerService里面acquireWakeLock()
wl.release();//释放锁&＃xff0c;显示的释放&＃xff0c;如果申请的锁不在此释放系统就不会进入休眠。
2).frameworks层
/frameworks/base/services/java/com/android/server/
PowerManagerService.java
这个类是来管理所有的应用程序申请的wakelock。比如音视频播放器&＃xff0c;camera等申请的wakelock都是通过这个类来管理的。
staticfinal String PARTIAL_NAME &＃61;"PowerManagerService"
Power.acquireWakeLock(Power.PARTIAL_WAKE_LOCK,
PARTIAL_NAME);
这个函数调用Power类里面的acquireWakeLock()&＃xff0c;此时的PARTIAL_NAME作为参数传递到底层去。
/frameworks/base/core/java/android/os/Power.java
publicstatic native void acquireWakeLock(int lock, Stringid);
注&＃xff1a;native申明的方法在Power类中没有实现&＃xff0c;其实现体在frameworks/base/core/jni/android_os_Power.cpp中&＃xff0c;所以调用Power类的acquireWakeLock()方法时会调用JNI下的实现方法。
3).JNI层的实现
路径&＃xff1a;frameworks/base/core/jni/android_os_Power.cpp
staticvoid acquireWakeLock(JNIEnv *env, jobject clazz,
jint lock,jstring idObj)
{
const char *id &＃61; env->GetStringUTFChars(idObj,NULL);
acquire_wake_lock(lock,id);
env->ReleaseStringUTFChars(idObj,id);
}
注&＃xff1a;在acquireWakeLock()中调用了路径下hardware/libhardware_legacy/power/power.c下面的acquire_wake_lock(lock,id)
4).与kernel层的交互
在power.c下的acquire_wake_lock(lock,id)函数如下&＃xff1a;
intacquire_wake_lock(int lock, const char* id)
{
returnwrite(fd, id, strlen(id));
}
注&＃xff1a;fd就是文件描述符&＃xff0c;在此表示”/sys/power/wake_lock”id就是从PowerManagerService类中传下来的参数即&＃xff1a;
PARTIAL_NAME&＃61; "PowerManagerService"
Earlysuspend
Android在标准的Linux休眠与唤醒机制上又加了一层&＃xff0c;就是early_suspend/late_resume。顾名思意&＃xff0c;使用early_suspend&＃xff08;&＃xff09;进行休眠的设备&＃xff0c;它休眠的时刻早于其他设备&＃xff0c;使用late_resume&＃xff08;&＃xff09;唤醒的设备&＃xff0c;它被唤醒的时刻要晚于其他设备。这对函数通常成对出现&＃xff0c;当内核打开了CONFIG_EARLY_SUSPEND(Android默认打开)后&＃xff0c;就可以使用这组函数来代替驱动中标准的suspend/resume接口。在early_suspend()函数中&＃xff0c;首先会检查现在请求的状态是否是suspend&＃xff0c;以防止suspend的请求在此时撤销(因为此时用户程序还在运行)&＃xff0c;如果需要退出&＃xff0c;就简单的退出了&＃xff1b;如果不需要退出&＃xff0c;这个函数会把early_suspend中注册的一系列函数都掉用一次&＃xff0c;然后同步文件系统&＃xff0c;最后放弃main_wake_lock。这个wakelock是没有超时的锁&＃xff0c;如果不放弃这个锁那么系统就无法进行休眠。Earlysuspend 是android引进的一种机制,这种机制在上游备受争议,这里不做评论.这个机制作用在关闭显示的时候,在这个时候,一些和显示有关的设备,比如LCD背光,比如重力感应器,触摸屏,这些设备都会关掉,但是系统可能还是在运行状态(这时候还有wakelock)进行任务的处理,例如在扫描Sd卡上的文件等.在嵌入式设备中,背光是一个很大的电源消耗,所以android会加入这样一种机制.
Staticssize_tstate_store(structkobject*kobj, structkobj_attribute*attr, constchar*buf,size_tn)
{
.........
#ifdefCONFIG_SUSPEND
for (s &＃61; &pm_states[state]; state
if(*s && len &＃61;&＃61; strlen(*s) && !strncmp(buf, *s, len))
break;
}
if(state
#ifdefCONFIG_EARLYSUSPEND
if(state &＃61;&＃61; PM_SUSPEND_ON || valid_state(state)) {
error&＃61; 0;
request_suspend_state(state); //这里&＃xff0c;进入了Android的休眠与唤醒的处理函数
}
#else
error&＃61; enter_state(state);
#endif
#endif
.........
}
power_attr(state);
voidrequest_suspend_state(suspend_state_t new_state)
{
......
if(!old_sleep && new_state !&＃61; PM_SUSPEND_ON) {
state|&＃61; SUSPEND_REQUESTED;
queue_work(suspend_work_queue,&early_suspend_work);//在休眠的时候&＃xff0c;去遍历执行early_suspend_work这个队列
}else if (old_sleep && new_state &＃61;&＃61; PM_SUSPEND_ON) {
state&&＃61; ~SUSPEND_REQUESTED;
wake_lock(&main_wake_lock);
queue_work(suspend_work_queue,&late_resume_work);//在唤醒的时候&＃xff0c;去遍历执行late_resume_work这个队列
}
......
}
//state的值会在0->1->3->2->0循环变化&＃xff0c;后面分析代码都可以看出这些值代表系统目前处于什么阶段&＃xff0c;简单得说就是&＃xff1a;正常->准备进earlysuspend->开始early suspend并且对名为mian的wakelock解锁&＃xff0c;如果此时没有其余wakelock处于lock状态&＃xff0c;那么系统就走linux的休眠唤醒路线让整个系统真正休眠&＃xff0c;直到唤醒源发生&＃xff0c;然后将处理器和linux层唤醒。之后android层判断本次底层醒来是由于我所定义的唤醒源引起的吗&＃xff1f;如果不是&＃xff0c;android将不予理会&＃xff0c;过段时间没有wakelock锁&＃xff0c;系统会再次走linux的休眠路线进入休眠。如果是&＃xff0c;那么android上层就会写一个on的指令到state接口中&＃xff0c;同样是会调用到函数request_suspend_state()-> 准备执行lateresume -> 开始执行lateresume&＃xff0c;之后整个系统就这样被唤醒了
根据用户/系统所请求的状态&＃xff0c;去做相应的动作&＃xff08;休眠/唤醒&＃xff09;
能用到的一些变量的声明如下&＃xff1a;
staticvoid early_suspend(struct work_struct *work);
staticvoid late_resume(struct work_struct *work);
staticDECLARE_WORK(early_suspend_work, early_suspend);
staticDECLARE_WORK(late_resume_work, late_resume);
early_suspend这个函数指针来处理early_suspend_work这条队列&＃xff0c;late_resume这个函数指针来处理late_resume_work这条队列.
staticvoid early_suspend(struct work_struct *work)
{
.......................
if(debug_mask & DEBUG_SUSPEND)
pr_info("early_suspend:call handlers\n");
list_for_each_entry(pos,&early_suspend_handlers, link) { //这里就是关键了&＃xff0c;遍历early_suspend_handler这条链表&＃xff08;在驱动中注册early_suspend的时候&＃xff0c;都注册到这条链表上了&＃xff09;
if(pos->suspend !&＃61; NULL) {
if(debug_mask & DEBUG_VERBOSE)
pr_info("early_suspend:calling %pf\n", pos->suspend);
pos->suspend(pos);//调用各个实现进行各设备的休眠
}
}
.......................
if(state &＃61;&＃61; SUSPEND_REQUESTED_AND_SUSPENDED)
wake_unlock(&main_wake_lock);//wake_lock主要用来防止系统休眠&＃xff0c;也就是说&＃xff0c;只要系统中其他地方还拥有wake_lock锁&＃xff08;类型WAKE_LOCK_SUSPEND&＃xff09;&＃xff0c;系统就没法进入休眠&＃xff0c;如果没有锁了&＃xff0c;那就要接着走标准Linux的那一套休眠机制了
......................
}
由于屏幕的耗电比重很大&＃xff0c;所以当屏幕关闭的时候会关掉背光&＃xff0c;重力感器等设备&＃xff0c;然后等到没有程序持有唤醒的时候进入真正睡眠&＃xff0c;但是标准的linux并不一定睡眠。
Lateresume
LateResume是和suspend配套的一种机制,是在内核唤醒完毕开始执行的.主要就是唤醒在EarlySuspend的时候休眠的设备。
当所有的唤醒已经结束以后,用户进程都已经开始运行了,唤醒通常会是以下的几种原因:
&＃xff08;1&＃xff09;来电
如果是来电,那么Modem会通过发送命令给rild来让rild通知WindowManager有来电响应,这样就会远程调用PowerManagerService来写"on"到/sys/power/state来执行lateresume的设备,比如点亮屏幕等.
&＃xff08;2&＃xff09;用户按键
用户按键事件会送到WindowManager中,WindowManager会处理这些按键事件,按键分为几种情况,如果案件不是唤醒键(能够唤醒系统的按键)那么WindowManager会主动放弃wakeLock来使系统进入再次休眠,如果按键是唤醒键,那么WindowManger就会调用PowerManagerService中的接口来执行LateResume.LateResume会依次唤醒前面调用了EarlySuspend的设备.
Staticvoid late_resume(struct work_struct *work)
{
staticvoid late_resume(struct work_struct *work)
{
structearly_suspend *pos;
unsignedlong irqflags;
intabort &＃61; 0;
mutex_lock(&early_suspend_lock);
spin_lock_irqsave(&state_lock,irqflags);
if(state &＃61;&＃61; SUSPENDED)
state&&＃61; ~SUSPENDED;
else
abort&＃61; 1;
spin_unlock_irqrestore(&state_lock,irqflags);
if(abort) {
if(debug_mask & DEBUG_SUSPEND)
pr_info("late_resume:abort, state %d\n", state);
gotoabort;
}
if(debug_mask & DEBUG_SUSPEND)
pr_info("late_resume:call handlers\n");
list_for_each_entry_reverse(pos,&early_suspend_handlers, link) {
if(pos->resume !&＃61; NULL) {
if(debug_mask & DEBUG_VERBOSE)
pr_info("late_resume:calling %pf\n", pos->resume);
//遍历链表依次调用每个驱动注册的resume handler.
pos->resume(pos);
//恢复操作
}
}
if(debug_mask & DEBUG_SUSPEND)
pr_info("late_resume:done\n");
abort:
mutex_unlock(&early_suspend_lock);
}
}
评价
android系统基于linux系统针对移动设备的特点做了改进提高&＃xff0c;但是从机制上讲还有所不成熟的地方。
由于程序不合理的占有WakeLock导致系统无法进入休眠。Android电源管理中没有相应的机制对这种情况作出判断。或者说没有完整性检查的步骤。
没有考虑外设的特点&＃xff0c;而仅仅有earlysuspend 和 lateresume这种统一的回调接口&＃xff0c;而缺乏更细粒度的依据设备特点的管理&＃xff0c;比如CPU的不同频率的管理&＃xff0c;屏幕亮度管理&＃xff0c;Wifi芯片的工作机制管理&＃xff0c;这里边很多机制的实现有赖于具体的芯片&＃xff0c;有些则需要系统整体考量&＃xff0c;进行统一的回调处理。如系统会评估当前的任务&＃xff0c;和当前的运行器件&＃xff0c;给出一个20%电量的时候高优先设备&＃xff0c;低优先级设备应该去实现的回调接口。
没有针对嵌入式设备的特点&＃xff0c;对启动过程进行具体设计。而只是在已有的机制上面加入必要性的扫描机制。缺乏如快照启动之类的支持。
缺乏用户个性化的手机使用资料收集及统计&＃xff0c;缺乏个性化的电源管理方案支持。如果有这方面的资料则可以定制化电源管理。
缺乏任务调度和电量消耗及用户体验之间的关系研究。
我们的工作
我们的工作就在于依据具体的设备进行电源管理优化&＃xff0c;考虑具体设备的特点如Broadcom芯片&＃xff0c;Omap的处理芯片。依据设备的特点&＃xff0c;在已有的管理策略基础之上进行优化。
京公网安备 11010802041100号