Android 睡眠流程

Android wakelock 学习总结第二篇 2014-01-24 17:24:28

分类： Android平台

如果看完第一篇的同学，是不是对大概上层睡眠流程有点小感了呢？如果你看过我说的几个代码，细心的你会发现上篇文章最后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的流程进行分析，走一遍！