亮滅屏問題一直是Android模塊最常見的問題之一。

? ? ? ?由于問題出現問題的地方涉及到公司代碼，我這里僅僅只作原生代碼模塊的分析

? ? ? ?其實在看過另外一篇關于android亮屏流程的文章就會發現，影響亮屏快慢的因素大致有三種：1.設置背光流程出問題了，導致屏幕黑屏，2.window繪制時間過長，導致屏幕block時間過長；3.底層surfacecontroller準備時間過長。

而根據遇到的亮屏慢的問題，基本上都是由于window繪制時間過長，導致屏幕亮屏慢

最近處理的幾個亮屏慢的問題，其中關鍵log信息基本都是：

10-28 09:02:59.002 ?1393 ?1462 I DisplayPowerController: Blocking screen on until initial contents have been drawn.

10-28 09:03:05.020 ?1393 ?1462 I DisplayPowerController: Unblocked screen on after 6018 ms

由于在android亮屏流程中大致描述的亮屏所走的流程點，但是僅僅只能作為一個粗略的點做參考，但是看到上面的兩條信息，我們可以去追溯一下代碼流程：

在每一次屏幕電源狀態發生改變的都會調用的到DisplayPowerController中的updatePowerState方法，在該方法中如果屏幕狀態發生改變的話，會去調用到animateScreenStateChange,在setScreenState方法里面去設置屏幕狀態。那么就到了該問題的主要流程了。

在DisplayPowerController.java中的setScreenState()方法中，有代碼：

[java]?view plain?copy

????if?(mPowerState.getColorFadeLevel()?==?0.0f)?{??

????????blockScreenOn();??

????}?else?{??

????????unblockScreenOn();??

????}??

????mWindowManagerPolicy.screenTurningOn(mPendingScreenOnUnblocker);??

}??

??

//?Return?true?if?the?screen?isn't?blocked.??

return?mPendingScreenOnUnblocker?==?null;??

首先會調用到 blockScreenOn方法，先看看該方法以及后面要調用到的unblockScreenOn的方法

[java]?view plain?copy

private?void?blockScreenOn()?{??

????if?(mPendingScreenOnUnblocker?==?null)?{??

????????Trace.asyncTraceBegin(Trace.TRACE_TAG_POWER,?SCREEN_ON_BLOCKED_TRACE_NAME,?0);??

????????mPendingScreenOnUnblocker?=?new?ScreenOnUnblocker();??

????????mScreenOnBlockStartRealTime?=?SystemClock.elapsedRealtime();??

????????Slog.i(TAG,?"Blocking?screen?on?until?initial?contents?have?been?drawn.");??

????}??

}??

???

private?void?unblockScreenOn()?{??

????if?(mPendingScreenOnUnblocke?!=?null)?{??

????????mPendingScreenOnUnblocker?=?null;??

????????long?delay?=?SystemClock.elapsedRealtime()?-?mScreenOnBlockStartRealTime;??

????????Slog.i(TAG,?"Unblocked?screen?on?after?"?+?delay?+?"?ms");??

????????Trace.asyncTraceEnd(Trace.TRACE_TAG_POWER,?SCREEN_ON_BLOCKED_TRACE_NAME,?0);??

????}??

}??

在blockScreenOn函數中其實就是創建了一個mPendingScreenOnUnblocker 對象，當該對象為空時，mPendingScreenOnUnblocker == null;返回值才為true。animateScreenStateChange才能繼續往下執行下去。

?

亮屏過程中繪制window過程是通過mWindowManagerPolicy.screenTurningOn(mPendingScreenOnUnblocker);?調用到PhoneWindowManager中的screenTurningOn(),

[java]?view plain?copy

private?final?class?ScreenOnUnblocker?implements?WindowManagerPolicy.ScreenOnListener?{??

????@Override??

????public?void?onScreenOn()?{??

????????Message?msg?=?mHandler.obtainMessage(MSG_SCREEN_ON_UNBLOCKED,?this);??

????????msg.setAsynchronous(true);??

????????mHandler.sendMessage(msg);??

????}??

}??

可以看到mPendingScreenOnUnblocker是繼承了WindowManagerPolicy.ScreenOnListener這個接口，而該接口同樣是作為一個callback到PhoneWindowManager那邊去繪制window，當all window for drawn 完成之后，會回調到 mPendingScreenOnUnblocker的onScreenOn,會去unblock屏幕

這里用一個圖來詳細描述

可以看到 整個過程調用的點較為混亂，這里只能簡單描述一下其調用過程當PowerManagerService發出的wakeup請求到DisplayPowerController這邊，在DisplayPowerConrtoller中setScreenState方法中會調用到PhoneWindowManager模塊的screenTurningOn方法去通過window繪制屏幕。

由于在滅屏之后亮屏首先現實的界面應該是鎖屏界面，所以亮屏首先應該去繪制keyguard，并且keyguard經常會出現超時，當出現keyguard超時時會打印：

WindowManager:Keyguard drawn timeout. Setting mKeyguardDrawComplete

當出現上述打印，便可以確定時keyguard模塊繪制鎖屏超時，需要鎖屏的人去確認超時原因。鎖屏超時時間最長也只有2秒時間。因為

[java]?view plain?copy

if?(mKeyguardDelegate?!=?null)?{??

????mHandler.removeMessages(MSG_KEYGUARD_DRAWN_TIMEOUT);??

????mHandler.sendEmptyMessageDelayed(MSG_KEYGUARD_DRAWN_TIMEOUT,?1000);??

????mKeyguardDelegate.onScreenTurningOn(mKeyguardDrawnCallback);??

}?else?{??

當mKeyguardDelegate.onScreenTurningOn(mKeyguardDrawnCallback);正常執行完成的情況下會調用到finishKeyguardDrawn，當未能正常執行，超過1秒還未完成便會發送消息MSG_KEYGUARD_DRAWN_TIMEOUT強制執行finishKeyguardDrawn，? ??

?在finishKeyguardDrawn完成后會檢查所有的亮屏后所依賴的window是否都繪制完成，在mWindowManagerInternal.waitForAllWindowsDrawn(mWindowManagerDrawCallback,WAITING_FOR_DRAWN_TIMEOUT);//WAITING_FOR_DRAWN_TIMEOUT = 1000?中會去檢查window繪制，如上，當超過1秒后，會自動release等待的window，然后正常亮屏。

原文地址：http://blog.csdn.net/u011311586/article/details/53174280

總結

以上是生活随笔為你收集整理的(原创)Android6.0亮屏流程之Keyguard Window绘制的全部內容，希望文章能夠幫你解決所遇到的問題。

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