Android wakelock 學習總結第二篇
轉載自：http://slightsnow.blog.chinaunix.net/uid-29269256-id-4091805.html
如果看完第一篇的同學，是不是對大概上層睡眠流程有點小感了呢？如果你看過我說的幾個程式碼，細心的你會發現上篇文章最後Native層只是對/sys/power/wakelock 和 /sys/power/unwakelock進行了操作，並沒有對/sys/power/state進行操作，這個是在哪裡進行的呢？呼叫的介面函式又寫哪裡呢？彆著急，我們跟隨updatePowerStateLocked（）這個函式沒見過？回頭看我的第一篇，當時沒有看得太明白，所以沒有詳細講啊，哇哈哈！現在我們看下
1114 private void updatePowerStateLocked() {
1115 if (!mSystemReady || mDirty == 0) {
1116 return;
1117 }
1118
1119 // Phase 0: Basic state updates.
1120 updateIsPoweredLocked(mDirty);
1121 updateStayOnLocked(mDirty);
1122
1123 // Phase 1: Update wakefulness.
1124 // Loop because the wake lock and user activity computations are influenced
1125 // by changes in wakefulness.
1126 final long now = SystemClock.uptimeMillis();
1127 int dirtyPhase2 = 0;
1128 for (;;) {
1129 int dirtyPhase1 = mDirty;
1130 dirtyPhase2 |= dirtyPhase1;
1131 mDirty = 0;
1132
1133 updateWakeLockSummaryLocked(dirtyPhase1);
1134 updateUserActivitySummaryLocked(now, dirtyPhase1);
1135 if (!updateWakefulnessLocked(dirtyPhase1)) {
1136 break;
1137 }
1138 }
1139
1140 // Phase 2: Update dreams and display power state.
1141 updateDreamLocked(dirtyPhase2);
1142 updateDisplayPowerStateLocked(dirtyPhase2);
1143
1144 // Phase 3: Send notifications, if needed.
1145 if (mDisplayReady) {
1146 sendPendingNotificationsLocked();
1147 }
1148
1149 // Phase 4: Update suspend blocker.
1150 // Because we might release the last suspend blocker here, we need to make sure
1151 // we finished everything else first!
1152 updateSuspendBlockerLocked();
1153 }
當程式跑到這裡的時候，就是已經要執行睡眠了，我們主要看Phase 2這段的 updateDisplayPowerStateLocked(dirtyPhase2) 這個函式主要關注下：
1696 mDisplayReady = mDisplayPowerController.requestPowerState(mDisplayPowerRequest,
1697 mRequestWaitForNegativeProximity);
這個requestPowerState函式進入到PowerController這個類中，這個幹什麼用的？看得還不太明白，以後慢慢看吧，不過最重要的一個還是要說明下：
1350 private final class DisplayControllerHandler extends Handler {
1351 public DisplayControllerHandler(Looper looper) {
1352 super(looper, null, true /*async*/);
1353 }
1354
1355 @Override
1356 public void handleMessage(Message msg) {
1357 switch (msg.what) {
1358 case MSG_UPDATE_POWER_STATE:
1359 updatePowerState();
1360 break;
1361
1362 case MSG_PROXIMITY_SENSOR_DEBOUNCED:
1363 debounceProximitySensor();
1364 break;
1365
1366 case MSG_LIGHT_SENSOR_DEBOUNCED:
1367 debounceLightSensor();
1368 break;
1369 }
這個Handler 是DisplayController自己重寫的一個hangMessage的方法，具體幹什麼用呢？又有睡呼叫呢？接著上面往下看，剛才呼叫到了requestPowerState，這個函式裝置狀態進行了一大堆判斷，主要是這兩句話：
529 if (changed && !mPendingRequestChangedLocked) {
530 mPendingRequestChangedLocked = true;
531 sendUpdatePowerStateLocked();
532 }
條件為什麼？自己看吧，我還沒有弄明白呢，但是sendUpdatePowerStateLocked(); 這句話確實是進入到了
544 private void sendUpdatePowerStateLocked() {
545 if (!mPendingUpdatePowerStateLocked) {
546 mPendingUpdatePowerStateLocked = true;
547 Message msg = mHandler.obtainMessage(MSG_UPDATE_POWER_STATE);
548 msg.setAsynchronous(true);
549 mHandler.sendMessage(msg);
550 }
551 }
這裡呢，看到沒有看到mHandler.sendMessage(msg); 這個函式就是剛才咱們看到的那個定義哦，哇哈哈是不是特別親切啊？繼續走啊～～～
當我們 進入updatePowerState(); 看到這個函式還真是他媽的長啊，不過仔細看看，無非就是對屏光亮有影響的一個裝置的判斷，比如L-sensor等，這個函式會呼叫setScreenOn(false);
829 private void setScreenOn(boolean on) {
830 if (!mPowerState.isScreenOn() == on) {
831 mPowerState.setScreenOn(on);
832 if (on) {
833 mNotifier.onScreenOn();
834 } else {
835 mNotifier.onScreenOff();
836 }
837 }
838 }
這個函式封裝了DisplayPowerState類中實現的setScreenOn(boolean on)
124 /**
125 * Sets whether the screen is on or off.
126 */
127 public void setScreenOn(boolean on) {
128 if (mScreenOn != on) {
129 if (DEBUG) {
130 Slog.d(TAG, "setScreenOn: on=" + on);
131 }
132
133 mScreenOn = on;
134 mScreenReady = false;
135 scheduleScreenUpdate();
136 }
137 }
再次感嘆JAVA封裝的還真是牛逼哄哄啊，緊接著呼叫scheduleScreenUpdate()，接著呼叫postScreenUpdateThreadSafe()，
272 private void scheduleScreenUpdate() {
273 if (!mScreenUpdatePending) {
274 mScreenUpdatePending = true;
275 postScreenUpdateThreadSafe();
276 }
277 }
278
279 private void postScreenUpdateThreadSafe() {
280 mHandler.removeCallbacks(mScreenUpdateRunnable);
281 mHandler.post(mScreenUpdateRunnable);
282 }
如果你要是問我然後走到哪裡了？呵呵，你肯定沒有見過Handler.post這樣的callback呼叫方法，沒錯，緊接著呼叫的就是mScreenUpdateRunnable這個類重寫的run函式
300 private final Runnable mScreenUpdateRunnable = new Runnable() {
301 @Override
302 public void run() {
303 mScreenUpdatePending = false;
304
305 int brightness = mScreenOn && mElectronBeamLevel > 0f ? mScreenBrightness : 0;
306 if (mPhotonicModulator.setState(mScreenOn, brightness)) {
307 mScreenReady = true;
308 invokeCleanListenerIfNeeded();
309 }
310 }
311 };
312
不要著急，我們已經慢慢快接近真相了啊，下面主要看得是mPhotonicModulator.setState(mScreenOn, brightness)這個函式
342 public boolean setState(boolean on, int backlight) {
343 synchronized (mLock) {
344 if (on != mPendingOn || backlight != mPendingBacklight) {
345 if (DEBUG) {
346 Slog.d(TAG, "Requesting new screen state: on=" + on
347 + ", backlight=" + backlight);
348 }
349
350 mPendingOn = on;
351 mPendingBacklight = backlight;
352
353 if (!mChangeInProgress) {
354 mChangeInProgress = true;
355 AsyncTask.THREAD_POOL_EXECUTOR.execute(mTask);
356 }
357 }
358 return mChangeInProgress;
359 }
360 }
到這裡，呼叫一個mTask，這個在哪裡定義呢？就在下面的函式中：
372 private final Runnable mTask = new Runnable() {
373 @Override
374 public void run() {
375 // Apply pending changes until done.
376 for (;;) {
377 final boolean on;
378 final boolean onChanged;
379 final int backlight;
380 final boolean backlightChanged;
381 synchronized (mLock) {
382 on = mPendingOn;
383 onChanged = (on != mActualOn);
384 backlight = mPendingBacklight;
385 backlightChanged = (backlight != mActualBacklight);
386 if (!onChanged && !backlightChanged) {
387 mChangeInProgress = false;
388 break;
389 }
390 mActualOn = on;
391 mActualBacklight = backlight;
392 }
393
394 if (DEBUG) {
395 Slog.d(TAG, "Updating screen state: on=" + on
396 + ", backlight=" + backlight);
397 }
398 if (onChanged && on) {
399 mDisplayBlanker.unblankAllDisplays();
400 }
401 if (backlightChanged) {
402 mBacklight.setBrightness(backlight);
403 }
404 if (onChanged && !on) {
405 mDisplayBlanker.blankAllDisplays();
406 }
407 }
408
409 // Let the outer class know that all changes have been applied.
410 postScreenUpdateThreadSafe();
411 }
412 };
這個有點長，不過咱們就看mDisplayBlanker.blankAllDisplays(); 這個 與mDisplayBlanker.unblankAllDisplays(); 這兩個函式一看就知道是相反的兩個功能，繼續跟隨這個函式，我們終於回到了PowerManagerService了
2658 @Override
2659 public void blankAllDisplays() {
2660 synchronized (this) {
2661 mBlanked = true;
2662 mDisplayManagerService.blankAllDisplaysFromPowerManager();
2663 nativeSetInteractive(false);
2664 nativeSetAutoSuspend(true);
2665 }
2666 }
2667
2668 @Override
2669 public void unblankAllDisplays() {
2670 synchronized (this) {
2671 nativeSetAutoSuspend(false);
2672 nativeSetInteractive(true);
2673 mDisplayManagerService.unblankAllDisplaysFromPowerManager();
2674 mBlanked = false;
2675 }
2676 }
終於看到了親切的native開頭的函數了，馬上就要到了啊，堅持住啊，其中 nativeSetInteractive(false);nativeSetAutoSuspend(true); 這兩個函式都定義在
frameworks/base/services/jni/com_android_server_power_PowerManagerService.cpp 中，分別列舉下：
170 static void nativeSetInteractive(JNIEnv *env, jclass clazz, jboolean enable) {
171 if (gPowerModule) {
172 if (enable) {
173 ALOGD_IF_SLOW(20, "Excessive delay in setInteractive(true) while turning screen on");
174 gPowerModule->setInteractive(gPowerModule, true);
175 } else {
176 ALOGD_IF_SLOW(20, "Excessive delay in setInteractive(false) while turning screen off");
177 gPowerModule->setInteractive(gPowerModule, false);
178 }
179 }
180 }
181
182 static void nativeSetAutoSuspend(JNIEnv *env, jclass clazz, jboolean enable) {
183 if (enable) {
184 ALOGD_IF_SLOW(100, "Excessive delay in autosuspend_enable() while turning screen off");
185 autosuspend_enable();
186 } else {
187 ALOGD_IF_SLOW(100, "Excessive delay in autosuspend_disable() while turning screen on");
188 autosuspend_disable();
189 }
190 }
第一個暫時沒有找到實現，也不知道幹什麼用，第二個函式的autosuspend_enable()和autosuspend_disable這兩個函式就是就是真正往/sys/power/state寫mem和on的函式啦!但是他在哪裡呢？這個我找了半天，沒想到竟然實現在：system/core/libsuspend/ 被編譯成了一個庫檔案，一直不明白為什麼同樣的power曾的Native的庫檔案，為什麼不放在一起呢？奇怪
水平有限，就先這樣吧，如果說不對的，請大牛幫忙指出，謝謝
現在大概的流程和介面都已經找到了，繼續詳細的看看程式碼了，就不再分析了！
下一篇會對kernel底層的earlysuspend的流程進行分析，走一遍！