作为移动终端,电量是一种稀缺资源,需要尽可能的节省。于是,Android系统在空闲时,会主动进入到休眠状态。
我们知道整个Android系统中运行着很多个进程,因此必须有一种机制能够知道每个进程是否正在进行重要的工作,只有这样Android系统才能对整个终端当前的状态做出判断。
显然我们不能启动一个进程,去主动监管其它所有进程的工作状态,这样CPU开销太大,反而加剧了电量的消耗。为此Android引入了基于WakeLock的电量管理机制,而PMS就是专门负责管理WakeLock的进程。
个人觉得WakeLock机制的思想,有点类似于早期通信领域局域网中的令牌环机制。当局域网中有设备需要发送数据时,需要申请令牌(Token),申请到令牌才能发送数据;设备发送完数据后,再释放掉令牌。
与此相似,Android设备中运行的进程需要使用电量资源时,也需要向PMS申请一个WakeLock;当工作完成后,就释放掉申请的WakeLock。PMS通过判断当前是否还有进程持有WakeLock,就能得出系统是否空闲的结论。
从这里也可以看出,当我们写一个永不停止工作的线程,但不申请WakeLock时,系统仍然可以休眠。在休眠时,CPU不会再耗费资源去调度该线程,于是“永不停止工作”被打上了引号。
接下来,我们就来看看PMS中的WakeLock。
一、创建WakeLock
我们以RIL.java为例,看看一般情况下,PMS以外的其它进程如何使用WakeLock。
在RIL.java的构造函数中:
public RIL(Context context, int preferredNetworkType, int cdmaSubscription, Integer instanceId) { ............. PowerManager pm = (PowerManager)context.getSystemService(Context.POWER_SERVICE); mWakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, RILJ_LOG_TAG); mWakeLock.setReferenceCounted(false); ........... mWakeLockCount = 0; ...........}
从上面的代码,可以看出调用PowerManager的newWakeLock函数,可以创建出WakeLock。
我们看看newWakeLock函数定义:
public WakeLock newWakeLock(int levelAndFlags, String tag) { validateWakeLockParameters(levelAndFlags, tag); return new WakeLock(levelAndFlags, tag, mContext.getOpPackageName());}
1、WakeLock Level
newWakeLock中的第一个参数对应于WakeLock的级别和标志位构成的位图。
目前,在PowerManger中一共为WakeLock定义了7种level。
/*** Wake lock level: Ensures that the CPU is running; the screen and keyboard* backlight will be allowed to go off.* * If the user presses the power button, then the screen will be turned off* but the CPU will be kept on until all partial wake locks have been released.* /public static final int PARTIAL_WAKE_LOCK = 0x00000001;/*** Wake lock level: Ensures that the screen is on (but may be dimmed);* the keyboard backlight will be allowed to go off.** If the user presses the power button, then the SCREEN_DIM_WAKE_LOCK will be* implicitly released by the system, causing both the screen and the CPU to be turned off.*/@Deprecatedpublic static final int SCREEN_DIM_WAKE_LOCK = 0x00000006;/*** Wake lock level: Ensures that the screen is on at full brightness;* the keyboard backlight will be allowed to go off.**If the user presses the power button, then the SCREEN_BRIGHT_WAKE_LOCK will be* implicitly released by the system, causing both the screen and the CPU to be turned off.*/@Deprecatedpublic static final int SCREEN_BRIGHT_WAKE_LOCK = 0x0000000a;/*** Wake lock level: Ensures that the screen and keyboard backlight are on at* full brightness.**If the user presses the power button, then the FULL_WAKE_LOCK will be* implicitly released by the system, causing both the screen and the CPU to be turned off.*/@Deprecatedpublic static final int FULL_WAKE_LOCK = 0x0000001a;/*** Wake lock level: Turns the screen off when the proximity sensor activates.* If the proximity sensor detects that an object is nearby, the screen turns off* immediately. Shortly after the object moves away, the screen turns on again.** A proximity wake lock does not prevent the device from falling asleep* unlike link FULL_WAKE_LOCK, SCREEN_BRIGHT_WAKE_LOCK and SCREEN_DIM_WAKE_LOCK.* If there is no user activity and no other wake locks are held, then the device will fall asleep (and lock) as usual.* However, the device will not fall asleep while the screen has been turned off* by the proximity sensor because it effectively counts as ongoing user activity.** Cannot be used with ACQUIRE_CAUSES_WAKEUP (WakeLock的flag).*///例如拨号,打通后接听电话,屏幕变黑public static final int PROXIMITY_SCREEN_OFF_WAKE_LOCK = 0x00000020;/*** Wake lock level: Put the screen in a low power state and allow the CPU to suspend* if no other wake locks are held.* * This is used by the dream manager to implement doze mode. It currently* has no effect unless the power manager is in the dozing state.* /public static final int DOZE_WAKE_LOCK = 0x00000040;/*** Wake lock level: Keep the device awake enough to allow drawing to occur.** This is used by the window manager to allow applications to draw while the* system is dozing. It currently has no effect unless the power manager is in* the dozing state.* /public static final int DRAW_WAKE_LOCK = 0x00000080;
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
从上面的代码注释可以看出,WakeLock主要用于控制CPU、屏幕和键盘三大部分(当然,现在的Anroid中基本没有键盘了)。
对于PARTIAL_WAKE_LOCK、SCREEN_DIM_WAKE_LOCK、SCREEN_BRIGHT_WAKE_LOCK和FULL_WAKE_LOCK而言,不考虑Power键的话,随着等级的提高,权限也相应增大,即持有高等级的锁,能够激活的部分越多;如果考虑Power键的话,PARTIAL_WAKE_LOCK可以保证CPU不休眠,反而是权限最大的。
PROXIMITY_SCREEN_OFF_WAKE_LOCK、DOZE_WAKE_LOCK和DRAW_WAKE_LOCK都是和具体场景相关的锁。
2、WakeLock Flag
PowerManager定义的WakeLock Flag很多,无法一一列举,就看一下比较常用的:
/*** Wake lock flag: Turn the screen on when the wake lock is acquired.** Normally wake locks don't actually wake the device, they just cause* the screen to remain on once it's already on. Think of the video player* application as the normal behavior. Notifications that pop up and want* the device to be on are the exception; use this flag to be like them.* * Cannot be used with PARTIAL_WAKE_LOCK.* /public static final int ACQUIRE_CAUSES_WAKEUP = 0x10000000;/*** Wake lock flag: When this wake lock is released, poke the user activity timer* so the screen stays on for a little longer.* * Will not turn the screen on if it is not already on.* * Cannot be used with PARTIAL_WAKE_LOCK.* /public static final int ON_AFTER_RELEASE = 0x20000000;..................
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
总结一下上面的内容,如下所示:
WakeLock Flag一般与WakeLock Level组合使用,使用的时候参照一下注释即可。
3、WakeLock的构造函数
最后,我们来看看WakeLock的构造函数:
WakeLock(int flags, String tag, String packageName) { mFlags = flags; mTag = tag; mPackageName = packageName; mToken = new Binder(); mTraceName = "WakeLock (" + mTag + ")";}
WakeLock的构造函数中需要注意的地方是,创建了一个Binder对象。
回忆一下RIL.java中创建WakeLock的过程,我们就知道这个Binder对象应该是创建在RIL.java所在的Phone进程中。
二、Acquire WakeLock
从上面的分析,我们知道一个进程创建的WakeLock,实际上表明了该进程执行某个工作时对电量的需求,例如声明该工作需要保持屏幕处于点亮状态,或该工作需要CPU处于唤醒态等。
因此,进程创建了WakeLock后,需要将WakeLock发送到PMS中,让PMS明白该进程的需求。
这种将WakeLock通知到PMS的过程,就被称为acquire WakeLock。
同样,我们还是以RIL.java中的使用过程举例:
private void send(RILRequest rr) { Message msg; if (mSocket == null) { rr.onError(RADIO_NOT_AVAILABLE, null); rr.release(); return; } msg = mSender.obtainMessage(EVENT_SEND, rr); acquireWakeLock(rr, FOR_WAKELOCK); msg.sendToTarget();}
当AP侧向modem发送请求时,将要调用RIL.java的send函数。send函数将会发送消息给RILSender,后者利用socket将消息发送给rild进程。
从上面的代码可以看出,在发送消息给RILSender之前,调用了acquireWakeLock函数:
private void acquireWakeLock(RILRequest rr, int wakeLockType) { synchronized(rr) { ............. switch(wakeLockType) { case FOR_WAKELOCK: synchronized (mWakeLock) { mWakeLock.acquire(); mWakeLockCount++; mWlSequenceNum++; ............ } break; ......... } rr.mWakeLockType = wakeLockType; }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
我们跟进一下PowerManager中WakeLock的acquire函数:
public void acquire() { synchronized (mToken) { acquireLocked(); }}private void acquireLocked() { if (!mRefCounted || mCount++ == 0) { ........ try { mService.acquireWakeLock(mToken, mFlags, mTag, mPackageName, mWorkSource, mHistoryTag); } catch (RemoteException e) { throw e.rethrowFromSystemServer(); } mHeld = true; }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
容易看出实际的工作流程将通过Binder通信进入到PMS中:
public void acquireWakeLock(IBinder lock, int flags, String tag, String packageName, WorkSource ws, String historyTag) { ............ final int uid = Binder.getCallingUid(); final int pid = Binder.getCallingPid(); final long ident = Binder.clearCallingIdentity(); try { acquireWakeLockInternal(lock, flags, tag, packageName, ws, historyTag, uid, pid); } finally { Binder.restoreCallingIdentity(ident); }}private void acquireWakeLockInternal(IBinder lock, int flags, String tag, String packageName, WorkSource ws, String historyTag, int uid, int pid) { synchronized (mLock) { ........... WakeLock wakeLock; int index = findWakeLockIndexLocked(lock); boolean notifyAcquire; if (index >= 0) { wakeLock = mWakeLocks.get(index); if (!wakeLock.hasSameProperties(flags, tag, ws, uid, pid)) { notifyWakeLockChangingLocked(wakeLock, flags, tag, packageName, uid, pid, ws, historyTag); wakeLock.updateProperties(flags, tag, packageName, ws, historyTag, uid, pid); } notifyAcquire = false; } else { wakeLock = new WakeLock(lock, flags, tag, packageName, ws, historyTag, uid, pid); try { lock.linkToDeath(wakeLock, 0); } catch (RemoteException ex) { throw new IllegalArgumentException("Wake lock is already dead."); } mWakeLocks.add(wakeLock); setWakeLockDisabledStateLocked(wakeLock); notifyAcquire = true; } applyWakeLockFlagsOnAcquireLocked(wakeLock, uid); mDirty |= DIRTY_WAKE_LOCKS; updatePowerStateLocked(); if (notifyAcquire) { notifyWakeLockAcquiredLocked(wakeLock); } }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
如上代码中标注的注释,acquireWakeLockInternal中有几处比较重要的地方,我们一起来分析一下。
1、监听客户端进程死亡
上面的代码中,第一次创建WakeLock后,调用了:
.........lock.linkToDeath(wakeLock, 0);.........
我们将acquire WakeLock的进程定义为PMS的客户端进程,那么上面代码的lock,就是客户端进程中创建的Binder对象的代理。对于RIL而言,就是存在于Phone进程中的Binder的代理。
PMS调用Binder代理的linkToDeath,实际上使得PMS成为了对应进程Binder的客户端。于是,当对应进程死亡后,将通知PMS。
linkToDeath传入的必须是继承IBinder.DeathRecipient的对象,作为进程死亡的”讣告”接收者。
我们看看PMS中WakeLock与此相关的定义:
private final class WakeLock implements IBinder.DeathRecipient { ........... @Override public void binderDied() { PowerManagerService.this.handleWakeLockDeath(this); } .......}
我们看看PMS的handleWakeLockDeath函数:
private void handleWakeLockDeath(WakeLock wakeLock) { synchronized (mLock) { .......... int index = mWakeLocks.indexOf(wakeLock); if (index < 0) { return; } removeWakeLockLocked(wakeLock, index); }}
跟进removeWakeLockLocked函数:
private void removeWakeLockLocked(WakeLock wakeLock, int index) { mWakeLocks.remove(index); notifyWakeLockReleasedLocked(wakeLock); applyWakeLockFlagsOnReleaseLocked(wakeLock); mDirty |= DIRTY_WAKE_LOCKS; updatePowerStateLocked();}
2、特殊处理PARTIAL_WAKE_LOCK
PMS处理第一次创建的WakeLock时,还会调用setWakeLockDisabledStateLocked函数进行处理:
private boolean setWakeLockDisabledStateLocked(WakeLock wakeLock) { if ((wakeLock.mFlags & PowerManager.WAKE_LOCK_LEVEL_MASK) == PowerManager.PARTIAL_WAKE_LOCK) { boolean disabled = false; if (mDeviceIdleMode) { final int appid = UserHandle.getAppId(wakeLock.mOwnerUid); if (appid >= Process.FIRST_APPLICATION_UID && Arrays.binarySearch(mDeviceIdleWhitelist, appid) < 0 && Arrays.binarySearch(mDeviceIdleTempWhitelist, appid) < 0 && mUidState.get(wakeLock.mOwnerUid, ActivityManager.PROCESS_STATE_CACHED_EMPTY) > ActivityManager.PROCESS_STATE_FOREGROUND_SERVICE) { disabled = true; } } if (wakeLock.mDisabled != disabled) { wakeLock.mDisabled = disabled; return true; } } return false;}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
上面代码大致的含义就是:
在Android Doze模式下,当终端处于device Idle Mode时,
对于一个非系统应用而言,如果该应用不在系统定义的白名单中,
并且该应用所在进程的类型表明,该进程对事件处理的时效性要求不高,
那么即使该应用申请了PARTIAL_WAKE_LOCK,也不能阻止系统进入休眠状态。
有些设备商,为了优化系统的功耗,就修改了这个地方。
例如,有些系统应用其实也很耗电,因此可以去掉该函数中对非系统应用的限制,对系统应用也进行管控。
3、处理WakeLock对应的Flag
前面的代码已经提到,当acquire WakeLock时,将调用applyWakeLockFlagsOnAcquireLocked处理WakeLock对应的flag;
当由于进程死亡,释放WakeLock时,会调用applyWakeLockFlagsOnReleaseLocked处理WakeLock对应的flag。
从函数命名来看,这两个函数应该有相似的地方。
3.1 applyWakeLockFlagsOnAcquireLocked
我们先看看applyWakeLockFlagsOnAcquireLocked:
private void applyWakeLockFlagsOnAcquireLocked(WakeLock wakeLock, int uid) { if ((wakeLock.mFlags & PowerManager.ACQUIRE_CAUSES_WAKEUP) != 0 && isScreenLock(wakeLock)) { .............. wakeUpNoUpdateLocked(SystemClock.uptimeMillis(), wakeLock.mTag, opUid, opPackageName, opUid); }}private boolean wakeUpNoUpdateLocked(long eventTime, String reason, int reasonUid, String opPackageName, int opUid) { ............ if (eventTime < mLastSleepTime || mWakefulness == WAKEFULNESS_AWAKE || !mBootCompleted || !mSystemReady) { return false; } try { mLastWakeTime = eventTime; setWakefulnessLocked(WAKEFULNESS_AWAKE, 0); mNotifier.onWakeUp(reason, reasonUid, opPackageName, opUid); userActivityNoUpdateLocked( eventTime, PowerManager.USER_ACTIVITY_EVENT_OTHER, 0, reasonUid); } ..... return true;}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
3.1.1 setWakefulnessLocked
我们看看唤醒屏幕相关的操作:
private void setWakefulnessLocked(int wakefulness, int reason) { if (mWakefulness != wakefulness) { mWakefulness = wakefulness; mWakefulnessChanging = true; mDirty |= DIRTY_WAKEFULNESS; mNotifier.onWakefulnessChangeStarted(wakefulness, reason); }}
public void onWakefulnessChangeStarted(final int wakefulness, int reason) { final boolean interactive = PowerManagerInternal.isInteractive(wakefulness); ....... mHandler.post(new Runnable() { @Override public void run() { mActivityManagerInternal.onWakefulnessChanged(wakefulness); } }); if (mInteractive != interactive) { if (mInteractiveChanging) { handleLateInteractiveChange(); } mInputManagerInternal.setInteractive(interactive); mInputMethodManagerInternal.setInteractive(interactive); try { mBatteryStats.noteInteractive(interactive); } catch (RemoteException ex) { } mInteractive = interactive; mInteractiveChangeReason = reason; mInteractiveChanging = true; handleEarlyInteractiveChange(); }}/*** Handle early interactive state changes such as getting applications or the lock* screen running and ready for the user to see (such as when turning on the screen).*/private void handleEarlyInteractiveChange() { synchronized (mLock) { if (mInteractive) { mHandler.post(new Runnable() { @Override public void run() { EventLog.writeEvent(EventLogTags.POWER_SCREEN_STATE, 1, 0, 0, 0); mPolicy.startedWakingUp(); } }); mPendingInteractiveState = INTERACTIVE_STATE_AWAKE; mPendingWakeUpBroadcast = true; updatePendingBroadcastLocked(); } else { final int why = translateOffReason(mInteractiveChangeReason); mHandler.post(new Runnable() { @Override public void run() { mPolicy.startedGoingToSleep(why); } }); } }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
从上面的代码来看,应该是PhoneWindowManager完成亮屏前的初始化工作,然后回调到PowerManager的wakeUp函数。
整个过程还是比较复杂的,需要单独进行分析,此处不做进一步说明。
3.2 applyWakeLockFlagsOnReleaseLocked
现在我们再看看applyWakeLockFlagsOnReleaseLocked函数:
private void applyWakeLockFlagsOnReleaseLocked(WakeLock wakeLock) { if ((wakeLock.mFlags & PowerManager.ON_AFTER_RELEASE) != 0 && isScreenLock(wakeLock)) { userActivityNoUpdateLocked(SystemClock.uptimeMillis(), PowerManager.USER_ACTIVITY_EVENT_OTHER, PowerManager.USER_ACTIVITY_FLAG_NO_CHANGE_LIGHTS, wakeLock.mOwnerUid); }}
可以看出applyWakeLockFlagsOnAcquireLocked和applyWakeLockFlagsOnReleaseLocked最后均会调用userActivityNoUpdateLocked函数,只是参数不同。
3.3 userActivityNoUpdateLocked
我们一起来看一下userActivityNoUpdateLocked:
private boolean userActivityNoUpdateLocked(long eventTime, int event, int flags, int uid) { ............. if (eventTime < mLastSleepTime || eventTime < mLastWakeTime || !mBootCompleted || !mSystemReady) { return false; } ........... try { if (eventTime > mLastInteractivePowerHintTime) { powerHintInternal(POWER_HINT_INTERACTION, 0); mLastInteractivePowerHintTime = eventTime; } mNotifier.onUserActivity(event, uid); ............. } finally { ........ }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
从以上代码来看,acquire WakeLock将申请信息递交给PMS统一进行处理。
PMS根据WakeLock的level和flag,完成修改一些变量、通知BatteryStatsService等工作后,
最终还是依赖于updatePowerStateLocked函数来进行实际的电源状态更新操作。
PMS类中有很多***NoUpdateLocked()方法,这些方法都有一些共性,就是仅更新状态,不负责具体的执行。因为PMS中具体的执行逻辑都是在updatePowerStateLocked方法中。
上述acquire WakeLock主要的工作大致可以总结为下图:
三、释放WakeLock
当进程完成工作后,需要释放之前申请的WakeLock。我们同样以RIL.java中的操作为例:
private void processResponse (Parcel p) { int type; type = p.readInt(); if (type == RESPONSE_UNSOLICITED || type == RESPONSE_UNSOLICITED_ACK_EXP) { ........... } else if (type == RESPONSE_SOLICITED || type == RESPONSE_SOLICITED_ACK_EXP) { RILRequest rr = processSolicited (p, type); if (rr != null) { if (type == RESPONSE_SOLICITED) { decrementWakeLock(rr); } rr.release(); return; } } else if (type == RESPONSE_SOLICITED_ACK) { ........... }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
我们跟进decrementWakeLock函数:
private void decrementWakeLock(RILRequest rr) { synchronized(rr) { switch(rr.mWakeLockType) { case FOR_WAKELOCK: synchronized (mWakeLock) { if (mWakeLockCount > 1) { mWakeLockCount--; } else { mWakeLockCount = 0; mWakeLock.release(); } } break; ........ } } ........}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
现在我们跟进PowerManager中WakeLock定义的release函数:
/*** Releases the wake lock with flags to modify the release behavior.** This method releases your claim to the CPU or screen being on.* The screen may turn off shortly after you release the wake lock, or it may* not if there are other wake locks still held.**/public void release(int flags) { synchronized (mToken) { if (!mRefCounted || --mCount == 0) { mHandler.removeCallbacks(mReleaser); if (mHeld) { ....... try { mService.releaseWakeLock(mToken, flags); } catch (RemoteException e) { throw e.rethrowFromSystemServer(); } mHeld = false; } } .... }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
最后一起来看看PMS中释放WakeLock的函数:
public void releaseWakeLock(IBinder lock, int flags) { ............. final long ident = Binder.clearCallingIdentity(); try { releaseWakeLockInternal(lock, flags); } finally { Binder.restoreCallingIdentity(ident); }}private void releaseWakeLockInternal(IBinder lock, int flags) { synchronized (mLock) { int index = findWakeLockIndexLocked(lock); ........... WakeLock wakeLock = mWakeLocks.get(index); ........... if ((flags & PowerManager.RELEASE_FLAG_WAIT_FOR_NO_PROXIMITY) != 0) { mRequestWaitForNegativeProximity = true; } wakeLock.mLock.unlinkToDeath(wakeLock, 0); removeWakeLockLocked(wakeLock, index); }}private void removeWakeLockLocked(WakeLock wakeLock, int index) { mWakeLocks.remove(index); notifyWakeLockReleasedLocked(wakeLock); applyWakeLockFlagsOnReleaseLocked(wakeLock); mDirty |= DIRTY_WAKE_LOCKS; updatePowerStateLocked();}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
整个release的过程大致可以总结为下图:
四、总结
通过前面的分析,我们知道了向PMS申请电量的基本用法类似于:
........//1、创建PowerManager pm = (PowerManager)context.getSystemService(Context.POWER_SERVICE);mWakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, RILJ_LOG_TAG);......mWakeLock.acquire();.........//3、releasemWakeLock.release();...........
当申请发送到PMS后,PMS将针对WakeLock的level和flag信息进行一些处理。
无论是acquire还是release WakeLock,PMS最终将利用updatePowerStateLocked函数对终端的电源状态进行调整。
我们将单独分析一下PMS核心的updatePowerStateLocked函数。
原文地址:http://blog.csdn.net/gaugamela/article/details/52813400