PowerManagerService負責Android系統中電源管理方面的工作，為了簡便我們在下文中將其簡稱為PMS。

我們先大致了解一下PMS在Android中的整體結構：?
?
如上圖所示，可以看出PMS的對外接口是PowerManager，其通過Binder通信來調用PMS中定義的BinderService的接口。?
BinderService與PowerManger之間的通信接口由IPowerManager.aidl來進行約束。

PMS由SystemServer來啟動，我們看看SystemServer.java中相關的代碼：

private void startBootstrapServices() {..........mPowerManagerService = mSystemServiceManager.startService(PowerManagerService.class);.......... }private void startOtherServices() {........try {mPowerManagerService.systemReady(mActivityManagerService.getAppOpsService());.........} catch (Throwable e) {.........}........ }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16

SystemServer.java中PMS涉及的地方主要有兩處：?
1、利用startService啟動PMS。?
之前分析PKMS時我們已經提過，startService主要通過反射調用服務的構造函數，然后再調用服務的onStart函數。?
2、調用PMS的systemReady方法。?
接下來我們就分三部分，分別看看PMS的構造函數、onStart函數及systemReady函數涉及到的流程。

一、構造函數?
PowerManagerService的構造函數如下所示：

public PowerManagerService(Context context) {............//ServiceThread繼承自HandlerThread，專門針對系統服務定義的，應該是優先級更高吧mHandlerThread = new ServiceThread(TAG,Process.THREAD_PRIORITY_DISPLAY, false /*allowIo*/);mHandlerThread.start();mHandler = new PowerManagerHandler(mHandlerThread.getLooper());synchronized (mLock) {//創建一些鎖對象，同構acquire和release修改引用數mWakeLockSuspendBlocker = createSuspendBlockerLocked("PowerManagerService.WakeLocks");mDisplaySuspendBlocker = createSuspendBlockerLocked("PowerManagerService.Display");mDisplaySuspendBlocker.acquire();mHoldingDisplaySuspendBlocker = true;mHalAutoSuspendModeEnabled = false;mHalInteractiveModeEnabled = true;mWakefulness = WAKEFULNESS_AWAKE;nativeInit();nativeSetAutoSuspend(false);nativeSetInteractive(true);nativeSetFeature(POWER_FEATURE_DOUBLE_TAP_TO_WAKE, 0);} }

• 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

容易看出PMS的構造函數較為簡單，僅需要進一步分析其native函數的作用。?
在com_android_server_power_PowerManagerService.cpp中：

static void nativeInit(JNIEnv* env, jobject obj) {//創建一個全局引用對象，引用PMSgPowerManagerServiceObj = env->NewGlobalRef(obj);//利用hw_get_module加載底層動態庫，具體實現還是依賴與dlsym函數status_t err = hw_get_module(POWER_HARDWARE_MODULE_ID,(hw_module_t const**)&gPowerModule);if (!err) {//調用底層動態庫的init函數gPowerModule->init(gPowerModule);} else {ALOGE("Couldn't load %s module (%s)", POWER_HARDWARE_MODULE_ID, strerror(-err));} }static void nativeSetAutoSuspend(JNIEnv* /* env */, jclass /* clazz */, jboolean enable) {if (enable) {ALOGD_IF_SLOW(100, "Excessive delay in autosuspend_enable() while turning screen off");autosuspend_enable();} else {ALOGD_IF_SLOW(100, "Excessive delay in autosuspend_disable() while turning screen on");//初始時調用autosuspend_disable函數，定義于system/core/libsuspend/autosuspend.c中//最終將調用到autosuspend_earlysuspend_disable函數，就是將底層的置為pwr_state_on的狀態autosuspend_disable();} }static void nativeSetInteractive(JNIEnv* /* env */, jclass /* clazz */, jboolean enable) {if (gPowerModule) {if (enable) {ALOGD_IF_SLOW(20, "Excessive delay in setInteractive(true) while turning screen on");//初始時，調用動態庫的setInteractive函數，目前還不確定這個函數調用后的效果gPowerModule->setInteractive(gPowerModule, true);} else {ALOGD_IF_SLOW(20, "Excessive delay in setInteractive(false) while turning screen off");gPowerModule->setInteractive(gPowerModule, false);}} }static void nativeSetFeature(JNIEnv *env, jclass clazz, jint featureId, jint data) {int data_param = data;if (gPowerModule && gPowerModule->setFeature) {//初始時，調用動態庫的setFeature函數，將POWER_FEATURE_DOUBLE_TAP_TO_WAKE置為0gPowerModule->setFeature(gPowerModule, (feature_t)featureId, data_param);} }

• 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

從上面的代碼可以看出，PMS的構造函數還是比較簡單的，就是創建一些基本的成員，然后利用native函數加載底層的動態庫，并設置一些狀態和標志位。

二、onStart?
接下來我們看看PMS的onStart函數：

public void onStart() {publishBinderService(Context.POWER_SERVICE, new BinderService());publishLocalService(PowerManagerInternal.class, new LocalService());Watchdog.getInstance().addMonitor(this);Watchdog.getInstance().addThread(mHandler); }

• 1
• 2
• 3
• 4
• 5
• 6
• 7

從代碼來看，onStart內容可以分成3類，即發布BinderService、發布LocalService和完成watchdog相關的工作。?
我們分別看看這3類工作具體的流程。

1、publishBinderService?
publishBinderService定義在PMS的父類SystemService中：

//PMS中的BinderService繼承自IPowerManager.Stub，實現了IBinder接口 //name為PMS的名稱，power protected final void publishBinderService(String name, IBinder service) {publishBinderService(name, service, false); }protected final void publishBinderService(String name, IBinder service,boolean allowIsolated) {//調用ServiceManger的接口，實際上利用Binder通信向Service Manger進程注冊服務ServiceManager.addService(name, service, allowIsolated); }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

通過上述代碼，PMS就將內部定義的BinderService注冊到Service Manager進程，對應的名稱為”power”。

2、publishLocalService?
publishLocalService同樣定義在PMS的父類SystemService中：

//參數中的LocalService繼承自PowerManagerInternal類 protected final <T> void publishLocalService(Class<T> type, T service) {LocalServices.addService(type, service); }

• 1
• 2
• 3
• 4

我們來看看LocalServices類的addService函數：

/** * Adds a service instance of the specified interface to the global registry of local services. */ public static <T> void addService(Class<T> type, T service) {synchronized (sLocalServiceObjects) {if (sLocalServiceObjects.containsKey(type)) {throw new IllegalStateException("Overriding service registration");}sLocalServiceObjects.put(type, service);} }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

從代碼來看，LocalServices的作用與單例模式有些相似，不過更為嚴格。?
單例模式用于保證某個類只能創建出一個對象； LocalServices管理對象時，確保繼承某個類或接口的對象只有一個。?
目前，還看不出PMS利用LocalServices管理其內部的LocalService的理由，先在此留個懸念。

3、watchdog相關工作?
在之前的博客中，分析過Android 6.0中watchdog流程。?
對于watchdog而言，Android 7.0與Android 6.0基本類似，這里僅再簡單介紹一下涉及到的流程。

//PMS實現了Watchdog.Monitor接口，下面的代碼將PMS加入到watchdog的mMonitorChecker中 Watchdog.getInstance().addMonitor(this); //將PMS的ServiceThread對對應的handler傳入watchdog中，watchdog將利用該handler構造一個HandlerChecker Watchdog.getInstance().addThread(mHandler);

• 1
• 2
• 3
• 4

3.1 addThread?
當PMS調用addThread時，watchDog利用mHandler構造一個HandlerChecker，然后周期性地調用HandlerChecker的scheduleCheckLocked方法：

public void scheduleCheckLocked() {//PMS對應的HandlerChecker沒有monitor，因此mMonitors.size()恒等于0//調用MessageQueue的isPolling函數，判斷是否處于polling狀態；//當MessageQueue native層的looper處于等待狀態，即沒有事件需要處理時，isPolling返回trueif (mMonitors.size() == 0 && mHandler.getLooper().getQueue().isPolling()) {mCompleted = true;return;}if (!mCompleted) {// we already have a check in flight, so no needreturn;}mCompleted = false;mCurrentMonitor = null;mStartTime = SystemClock.uptimeMillis();//HandlerChecker繼承runnable，這里的意思是向PMS的handler發送一個HandlerChecker類型的runnable事件mHandler.postAtFrontOfQueue(this); }public void run() {final int size = mMonitors.size();//PMS對應的HandlerChecker的mMonitors.size為0，跳過for (int i = 0 ; i < size ; i++) {synchronized (Watchdog.this) {mCurrentMonitor = mMonitors.get(i);}mCurrentMonitor.monitor();}//只要PMS的mHandler在規定事件內，執行了上文傳入的runnable事件，就說明沒有阻塞，PMS是正常的synchronized (Watchdog.this) {mCompleted = true;mCurrentMonitor = null;} }

• 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

3.2 addMonitor?
當PMS調用watchDog的addMonitor函數后，watchDog就會周期性地調用PMS的monitor接口：

public void monitor() {// Grab and release lock for watchdog monitor to detect deadlocks.synchronized (mLock) {} }

• 1
• 2
• 3
• 4
• 5

PMS只要能在規定時間內獲得mLock鎖，watchDog就能確認PMS沒有死鎖，狀態正常。

以上只是簡略介紹了一下watchDog相關的內容，詳情可以參考下面的博客。?
Android6.0 watchdog

三、systemReady?
接下來我們看一下PMS的systemReady函數：

public void systemReady(IAppOpsService appOps) {//這里持鎖，意味者內部所有函數必須在規定事件內執行完畢//否則watchDog將會檢測到錯誤synchronized (mLock) {mSystemReady = true;mAppOps = appOps;//注意下面的對象都是從LocalServices取出的，從之前PMS加入LocalServices的流程來看//下面取出的實際上應該是繼承抽象類的實際子類//因此大概可以理解LocalServices的作用了，以抽象類名為key，保存實際的子類//以key取出子類對象時，子類退化為抽象類，于是得到了實際對象，但僅能利用父類的接口//整個設計演變為面向接口的編程//從注釋來看，與doze有關mDreamManager = getLocalService(DreamManagerInternal.class);//顯示管理相關mDisplayManagerInternal = getLocalService(DisplayManagerInternal.class);//Window管理相關mPolicy = getLocalService(WindowManagerPolicy.class);//電源管理相關mBatteryManagerInternal = getLocalService(BatteryManagerInternal.class);//這里獲取PowerManager就是為了方便獲取下面三個系統屬性PowerManager pm = (PowerManager) mContext.getSystemService(Context.POWER_SERVICE);mScreenBrightnessSettingMinimum = pm.getMinimumScreenBrightnessSetting();mScreenBrightnessSettingMaximum = pm.getMaximumScreenBrightnessSetting();mScreenBrightnessSettingDefault = pm.getDefaultScreenBrightnessSetting();//Sensor相關SensorManager sensorManager = new SystemSensorManager(mContext, mHandler.getLooper());//系統電量統計有關mBatteryStats = BatteryStatsService.getService();// The notifier runs on the system server's main looper so as not to interfere// with the animations and other critical functions of the power manager.mNotifier = new Notifier(Looper.getMainLooper(), mContext, mBatteryStats,mAppOps, createSuspendBlockerLocked("PowerManagerService.Broadcasts"),mPolicy);//無線充電檢測相關mWirelessChargerDetector = new WirelessChargerDetector(sensorManager,createSuspendBlockerLocked("PowerManagerService.WirelessChargerDetector"),mHandler);mSettingsObserver = new SettingsObserver(mHandler);//lightService相關mLightsManager = getLocalService(LightsManager.class);mAttentionLight = mLightsManager.getLight(LightsManager.LIGHT_ID_ATTENTION);// Initialize display power management.//調用DisplayManagerService內部的LocalService的函數//創建出DisplayBlanker和DisplayPowerControllermDisplayManagerInternal.initPowerManagement(mDisplayPowerCallbacks, mHandler, sensorManager);//定義一堆BroadcastReceiver..................//利用mSettingsObserver監聽一堆數據庫字段的變化..................//VR相關IVrManager vrManager =(IVrManager) getBinderService(VrManagerService.VR_MANAGER_BINDER_SERVICE);try {vrManager.registerListener(mVrStateCallbacks);} catch (RemoteException e) {Slog.e(TAG, "Failed to register VR mode state listener: " + e);}//從資源文件中讀取大量配置信息readConfigurationLocked();//讀取數據庫字段，保存到本地變量中//必要時會進行一些實際的操作，例如設置feature到native層的動態庫updateSettingsLocked();mDirty |= DIRTY_BATTERY_STATE;//更新全局的電源狀態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
• 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
• 77
• 78
• 79
• 80
• 81
• 82
• 83
• 84

從代碼來看，PMS在systemReady中主要是獲得一些成員變量，注冊一些廣播接收對象、讀取一些配置參數等。雖然PMS會與多個服務打交道，使得systemReady內容較為龐雜，但整個過程比較簡單。

在systemReady函數的最后，調用了一個比較重要的函數updatePowerStateLocked。當PMS監控到終端發生重大變化時，將利用該函數集中更新所有相關的狀態。updatePowerStateLocked涉及的內容較多，等對PMS整體有了初步的了解后，再來分析這個函數。

總結?

本篇博客側重于介紹PMS的啟動過程，同時對PMS需要打交道的服務建立一個基本的認識。

原文地址：　http://blog.csdn.net/gaugamela/article/details/52785041

總結

以上是生活随笔為你收集整理的Android7.0 PowerManagerService(1) 启动过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。