先看到PhoneWindowManager中public boolean interceptKeyTi(WindowState win, int code, int metaKeys, boolean down,
int repeatCount, int flags) 這個方法的實現,interceptKeyTi你可以暫時理解為WindowManagerService中處理驅動和上層按鍵實現的過濾器
- if (code == KeyEvent.KEYCODE_HOME) {
-
- // If a system window has focus, then it doesn't make sense
- // right now to interact with applications.
- WindowManager.LayoutParams attrs = win != null ? win.getAttrs() : null;
- if (attrs != null) {
- final int type = attrs.type;
- if (type == WindowManager.LayoutParams.TYPE_KEYGUARD
- || type == WindowManager.LayoutParams.TYPE_KEYGUARD_DIALOG) {
- // the "app" is keyguard, so give it the key
- return false;
- }
- final int typeCount = WINDOW_TYPES_WHERE_HOME_DOESNT_WORK.length;
- for (int i=0; i<typeCount; i++) {
- if (type == WINDOW_TYPES_WHERE_HOME_DOESNT_WORK[i]) {
- // don't do anything, but also don't pass it to the app
- return true;
- }
- }
- }
從上面的注釋可以看到注釋:// the "app" is keyguard, so give it the key ,就是說當在應用界面下的時候,按了HOME鍵而且當前應用的WindowManager.LayoutParams.type的值是WindowManager.LayoutParams.TYPE_KEYGUARD就讓直接返回;返回做什麼呢,我先告訴大家,這個interceptKeyTi方法被調用的地方的流程後續步驟就是根據這個interceptKeyTi的返回值來判斷,如果返回的是false就讓當前應用自己去做HOME鍵的業務處理通過類似下面的代碼
- /* 按鍵按下 */
- public boolean onKeyDown(int keyCode, KeyEvent event)
- {
- switch (keyCode)
- {
- case KeyEvent.KEYCODE_HOME:
- DisplayToast("HOME鍵按下");
- break;
-
- }
- return super.onKeyDown(keyCode, event);
-
- }
-
- /*按鍵彈起*/
- public boolean onKeyUp(int keyCode, KeyEvent event)
- {
- switch (keyCode)
- {
- case KeyEvent.KEYCODE_HOME:
- DisplayToast("HOME鍵彈起");
- break;
-
- }
-
- return super.onKeyUp(keyCode, event);
- }
這裡就產生了疑問:一、WindowManager.LayoutParams.type的值是在應用的哪裡初始化的,二、interceptKeyTi方法被調用的地方的流程後續步驟是怎麼調應用的HOME鍵的處理方式的,三、interceptKeyTi方法被調用的地方的流程後續步驟是怎麼獲取到WindowManager.LayoutParams.type初始化的值的;這三個疑問基本上就是按鍵的一個流程即怎麼通過底層驅動到Activity相應按鍵事件相應的。
下面我們來看第一個問題的解答:Activity中有兩個可覆蓋的方法,都可以做如下的初始化:
- /**
- * Called when the current {@link Window} of the activity gains or loses
- * focus. This is the best indicator of whether this activity is visible
- * to the user. The default implementation clears the key tracking
- * state, so should always be called.
- *
- * <p>Note that this provides information about global focus state, which
- * is managed independently of activity lifecycles. As such, while focus
- * changes will generally have some relation to lifecycle changes (an
- * activity that is stopped will not generally get window focus), you
- * should not rely on any particular order between the callbacks here and
- * those in the other lifecycle methods such as {@link #onResume}.
- *
- * <p>As a general rule, however, a resumed activity will have window
- * focus... unless it has displayed other dialogs or popups that take
- * input focus, in which case the activity itself will not have focus
- * when the other windows have it. Likewise, the system may display
- * system-level windows (such as the status bar notification panel or
- * a system alert) which will temporarily take window input focus without
- * pausing the foreground activity.
- *
- * @param hasFocus Whether the window of this activity has focus.
- *
- * @see #hasWindowFocus()
- * @see #onResume
- * @see View#onWindowFocusChanged(boolean)
- */
- public void onWindowFocusChanged(boolean hasFocus) {
- WindowManager.LayoutParams lp = new WindowManager.LayoutParams();
- lp.type = WindowManager.LayoutParams.TYPE_KEYGUARD ;
- this.getWindow().setAttributes(lp);
- }
-
-
- /** * Called when the main window associated with the activity has been
- * attached to the window manager.
- * See {@link View#onAttachedToWindow() View.onAttachedToWindow()}
- * for more information.
- * @see View#onAttachedToWindow
- */
- public void onAttachedToWindow() {
- this.getWindow().setType(WindowManager.LayoutParams.TYPE_KEYGUARD);
- super.onAttachedToWindow();
- }
-
-
- onWindowFocusChanged(boolean) 當窗口包含的view獲取或失去焦點時觸發
- onAttachedToWindow() 當view被附著到一個窗口時觸發