Android应用程序键盘（Keyboard）消息处理机制分析（四）

最新推荐文章于 2021-05-26 17:37:37 发布
最新推荐文章于 2021-05-26 17:37:37 发布
阅读量1.5k 收藏
点赞数
分类专栏： Android 文章标签： android keyboard server session 代码分析 null

上接：Android应用程序键盘（Keyboard）消息处理机制分析（三）

----

        4. 应用程序注销键盘消息接收通道的过程分析
        当Activity窗口创建时，它会向InputManager注册键盘消息接收通道，而当Activity窗口销毁时，它就会向InputManager注销前面注册的键盘消息接收通道了，本节内容就来看看应用程序注销键盘消息接收通道的过程。

        当我们按下键盘上的Back键时，当前激活的Activity窗口就会被失去焦点，但是这时候它还没有被销毁，它的状态被设置为Stopped；当新的Activity窗口即将要显示时，它会通知WindowManagerService，这时候WindowManagerService就会处理当前处理Stopped状态的Activity窗口了，要执行的操作就是销毁它们了，在销毁的时候，就会注销它们之前所注册的键盘消息接收通道。

        新的Activity窗口通知WindowManagerService它即将要显示的过程比较复杂，但是它与我们本节要介绍的内容不是很相关，因此，这里就略过大部过程了，我们从ActvitiyRecord的windowsVisible函数开始分析。注意，这里的ActivityRecord是新的Activity窗口在ActivityManangerService的代表，而那些处于Stopped状态的Activity窗口

会放在ActivityStack类的一个等待可见的mWaitingVisibleActivities列表里面，事实于，对于那些Stopped状态的Activity窗口来说，它们是等待销毁，而不是等待可见。

        像前面一样，我们先来看一张应用程序注销键盘消息接收通道的过程的序列图，然后根据这个序列图来详细分析互一个步骤：


点击查看大图

        Step 1. ActivityRecord.windowsVisible

        这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityRecord.java文件中：

view plain
  1. class ActivityRecord extends IApplicationToken.Stub {  
  2.     ......  
  3.     boolean nowVisible;     // is this activity's window visible?  
  4.     boolean idle;           // has the activity gone idle?  
  5.     ......  
  6.   
  7.   
  8.     public void windowsVisible() {  
  9.         synchronized(service) {  
  10.             ......  
  11.   
  12.             if (!nowVisible) {  
  13.                 nowVisible = true;  
  14.                 if (!idle) {  
  15.                     .......  
  16.                 } else {  
  17.                     // If this activity was already idle, then we now need to  
  18.                     // make sure we perform the full stop of any activities  
  19.                     // that are waiting to do so.  This is because we won't  
  20.                     // do that while they are still waiting for this one to  
  21.                     // become visible.  
  22.                     final int N = stack.mWaitingVisibleActivities.size();  
  23.                     if (N > 0) {  
  24.                         for (int i=0; i<N; i++) {  
  25.                             ActivityRecord r = (ActivityRecord)  
  26.                                 stack.mWaitingVisibleActivities.get(i);  
  27.                             r.waitingVisible = false;  
  28.                             ......  
  29.                         }  
  30.                         stack.mWaitingVisibleActivities.clear();  
  31.   
  32.                         Message msg = Message.obtain();  
  33.                         msg.what = ActivityStack.IDLE_NOW_MSG;  
  34.                         stack.mHandler.sendMessage(msg);  
  35.   
  36.                     }  
  37.                 }  
  38.                 ......  
  39.             }  
  40.         }  
  41.     }  
  42.   
  43.     ......  
  44. }  
        应用程序中的每一个Activity在ActivityManagerService都有一个代表ActivityRecord，它们以堆栈的形式组织在ActivityManaerService中的ActivityStack中。一个即将要显示，但是还没有显示的Activity，它在ActivityManagerService中的ActivityRecord的成员变量nowVisible为false，而成员变量idle为ture，表示这个即将要显示的Activity窗口处于空闲状态。因此，在上面的这个函数中，会执行下面的语句：

view plain
  1. final int N = stack.mWaitingVisibleActivities.size();  
  2. if (N > 0) {  
  3.     for (int i=0; i<N; i++) {  
  4.         ActivityRecord r = (ActivityRecord)  
  5.         stack.mWaitingVisibleActivities.get(i);  
  6.         r.waitingVisible = false;  
  7.         ......  
  8.     }  
  9.     stack.mWaitingVisibleActivities.clear();  
  10.   
  11.     Message msg = Message.obtain();  
  12.     msg.what = ActivityStack.IDLE_NOW_MSG;  
  13.     stack.mHandler.sendMessage(msg);  
  14.   
  15. }  
        前面我们说过，当用户按下键盘上的Back键时，当前激活的Activity记录就被放在ActivityStack对象stack的成员变量mWaitingVisibleActivities中了，这时候就要对它进行处理了。首先是将它们的Activity记录的waitingVisible设置为false，然后就把它们从ActivityStack对象stack的成员变量mWaitingVisibleActivities清空，最后向ActivityStack对象stack发送一个ActivityStack.IDLE_NOW_MSG消息。这个消息最终是由ActivityStack类的activityIdleInternal函数来处理的。

        Step 2. ActivityStack.activityIdleInternal

        这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中：

view plain
  1. public class ActivityStack {  
  2.     ......  
  3.   
  4.     final void activityIdleInternal(IBinder token, boolean fromTimeout,  
  5.             Configuration config) {  
  6.         ......  
  7.   
  8.         ArrayList<ActivityRecord> stops = null;  
  9.         ......  
  10.   
  11.         int NS = 0;  
  12.         ......  
  13.   
  14.         synchronized (mService) {  
  15.             ......  
  16.   
  17.             // Atomically retrieve all of the other things to do.  
  18.             stops = processStoppingActivitiesLocked(true);  
  19.             NS = stops != null ? stops.size() : 0;  
  20.             ......  
  21.         }  
  22.   
  23.         int i;  
  24.   
  25.         ......  
  26.   
  27.         // Stop any activities that are scheduled to do so but have been  
  28.         // waiting for the next one to start.  
  29.         for (i=0; i<NS; i++) {  
  30.             ActivityRecord r = (ActivityRecord)stops.get(i);  
  31.             synchronized (mService) {  
  32.                 if (r.finishing) {  
  33.                     finishCurrentActivityLocked(r, FINISH_IMMEDIATELY);  
  34.                 } else {  
  35.                     ......  
  36.                 }  
  37.             }  
  38.         }  
  39.   
  40.         ......  
  41.     }  
  42.   
  43.     ......  
  44. }  
        这个函数首先会调用processStoppingActivitiesLocked函数把所有处于Stopped状态的Activity取回来，然后逐个分析它们，如果它们的ActivityRecord中的finishing成员变量为true，就说明这个Activity需要销毁了，于是，就调用finishCurrentActivityLocked函数来销毁它们。

        Step 3. ActivityStack.finishCurrentActivityLocked

        这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中：

view plain
  1. public class ActivityStack {  
  2.     ......  
  3.   
  4.     private final ActivityRecord finishCurrentActivityLocked(ActivityRecord r,  
  5.             int mode) {  
  6.         ......  
  7.   
  8.         return finishCurrentActivityLocked(r, index, mode);  
  9.     }  
  10.   
  11.     private final ActivityRecord finishCurrentActivityLocked(ActivityRecord r,  
  12.             int index, int mode) {  
  13.         ......  
  14.   
  15.         // make sure the record is cleaned out of other places.  
  16.         mStoppingActivities.remove(r);  
  17.         mWaitingVisibleActivities.remove(r);  
  18.         ......  
  19.   
  20.         final ActivityState prevState = r.state;  
  21.         r.state = ActivityState.FINISHING;  
  22.   
  23.         if (mode == FINISH_IMMEDIATELY  
  24.             || prevState == ActivityState.STOPPED  
  25.             || prevState == ActivityState.INITIALIZING) {  
  26.             // If this activity is already stopped, we can just finish  
  27.             // it right now.  
  28.             return destroyActivityLocked(r, true) ? null : r;  
  29.         } else {  
  30.             ......  
  31.         }  
  32.   
  33.         return r;  
  34.     }  
  35.   
  36.     ......  
  37. }  
        从上面的Step 2中传进来的参数mode为FINISH_IMMEDIATELY，并且这个即将要被销毁的Activity的状态为Stopped，因此，接下来就会调用destroyActivityLocked函数来销毁它。

        Step 4. ActivityStack.destroyActivityLocked

        这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中：

view plain
  1. public class ActivityStack {  
  2.     ......  
  3.   
  4.     final boolean destroyActivityLocked(ActivityRecord r,  
  5.             boolean removeFromApp) {  
  6.         ......  
  7.   
  8.         boolean removedFromHistory = false;  
  9.   
  10.         ......  
  11.   
  12.         final boolean hadApp = r.app != null;  
  13.   
  14.         if (hadApp) {  
  15.             ......  
  16.   
  17.             try {  
  18.                 ......  
  19.                 r.app.thread.scheduleDestroyActivity(r, r.finishing,  
  20.                     r.configChangeFlags);  
  21.             } catch (Exception e) {  
  22.                 ......  
  23.             }  
  24.   
  25.             ......  
  26.         } else {  
  27.             ......  
  28.         }  
  29.   
  30.         ......  
  31.   
  32.         return removedFromHistory;  
  33.     }  
  34.   
  35.     ......  
  36. }  
         在前面一篇文章 Android应用程序启动过程源代码分析 中，我们说到，每一个应用程序进程在ActivityManagerService中，都ProcessRecord记录与之对应，而每一个Activity，都是运行在一个进程上下文中，因此，在ActivityManagerService中，每一个ActivityRecord的app成员变量都应该指向一个ProcessRecord记录，于是，这里得到的hadApp为true。在ProcessRecord类中，有一个成员变量thread，它的类型为IApplicationThread。在文章 Android应用程序启动过程源代码分析 中，我们也曾经说过，每一个应用程序在启动的时候，它都会在内部创建一个ActivityThread对象，而在这个ActivityThread对象中，有一个成员变量mAppThread，它的类型为ApplicationThread，这是一个Binder对象，专门用来负责在应用程序和ActivityManagerService之间执行进程间通信工作的。应用程序在启动的时候，就会将这个Binder对象传递给ActivityManagerService，而ActivityManagerService就会把它保存在相应的ProcessRecord记录的thread成员变量中。因此，ProcessRecord记录的thread成员变量其实就是ApplicationThread对象的远程接口，于是，执行下面这个语句的时候：

view plain
  1. r.app.thread.scheduleDestroyActivity(r, r.finishing,  
  2.     r.configChangeFlags);  
        就会进入到ApplicationThread类中的scheduleDestroyActivity函数来。

        Step 5. ApplicationThread.scheduleDestroyActivity

        这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

view plain
  1. public final class ActivityThread {  
  2.     ......  
  3.   
  4.     private final class ApplicationThread extends ApplicationThreadNative {  
  5.         ......  
  6.   
  7.         public final void scheduleDestroyActivity(IBinder token, boolean finishing,  
  8.                 int configChanges) {  
  9.   
  10.             queueOrSendMessage(H.DESTROY_ACTIVITY, token, finishing ? 1 : 0,  
  11.                     configChanges);  
  12.         }  
  13.   
  14.         ......  
  15.     }  
  16.   
  17.     ......  
  18. }  
        这个函数调用外部类ActivityThread的queueOrSendMessage函数来往应用程序的消息队列中发送一个H.DESTROY_ACTIVITY消息，这个消息最终由ActivityThread类的handleDestroyActivity函数来处理。

        Step 6. ActivityThread.handleDestroyActivity

        这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

view plain
  1. public final class ActivityThread {  
  2.     ......  
  3.   
  4.     private final void handleDestroyActivity(IBinder token, boolean finishing,  
  5.             int configChanges, boolean getNonConfigInstance) {  
  6.         ......  
  7.   
  8.         ActivityClientRecord r = performDestroyActivity(token, finishing,  
  9.             configChanges, getNonConfigInstance);  
  10.         if (r != null) {  
  11.             WindowManager wm = r.activity.getWindowManager();  
  12.             View v = r.activity.mDecor;  
  13.             if (v != null) {  
  14.                 ......  
  15.   
  16.                 if (r.activity.mWindowAdded) {  
  17.                     wm.removeViewImmediate(v);  
  18.                 }  
  19.                   
  20.                 ......  
  21.             }  
  22.             ......  
  23.         }  
  24.   
  25.         ......  
  26.     }  
  27.   
  28.     ......  
  29. }  
        这里首先调用performDestroyActivity来执行一些销毁Activity的操作，期间就会调用Activity的onDestroy函数让Activity本身有机会执行一些销毁前的工作了。这里通过r.activity.getWindowManager函数返回的是一个LocalWindowManager对象，而通过r.activity.mDecor得到的是一个DecorView对象，这些都是在Activity启动的时候设置好的。函数最后调用LocalWindowManager对象wm的removeViewImmediate函员来从LocalWindowManager移除这个DecorView对象。

        Step 7. LocalWindowManager.removeViewImmediate

        这个函数定义在frameworks/base/core/java/android/view/Window.java文件中：

view plain
  1. public abstract class Window {  
  2.     ......  
  3.   
  4.     private class LocalWindowManager implements WindowManager {  
  5.         ......  
  6.   
  7.         public final void removeViewImmediate(View view) {  
  8.             mWindowManager.removeViewImmediate(view);  
  9.         }  
  10.   
  11.         ......  
  12.   
  13.         private final WindowManager mWindowManager;  
  14.     }  
  15.   
  16.     ......  
  17. }  
        LocalWindowManager类的成员变量mWindowManager是一个WndowManagerImpl对象，这个函数只是简单地调用WndowManagerImpl类的removeViewImmediate来进一步处理。

       Step 8. WndowManagerImpl.removeViewImmediate

       这个函数定义在frameworks/base/core/java/android/view/WindowManagerImpl.java文件中：

view plain
  1. public class WindowManagerImpl implements WindowManager {  
  2.     ......  
  3.   
  4.     public void removeViewImmediate(View view) {  
  5.         synchronized (this) {  
  6.             int index = findViewLocked(view, true);  
  7.             ViewRoot root = mRoots[index];  
  8.             ......  
  9.   
  10.             root.die(true);  
  11.               
  12.             ......  
  13.         }  
  14.     }  
  15.   
  16.     ......  
  17. }  
         这个函数首先是找到这个view所属的ViewRoot对象root，然后调用这个root对象的die函数来销毁它。

         Step 9. ViewRoot.die

         这个函数定义在frameworks/base/core/java/android/view/ViewRoot.java文件中：

view plain
  1. public final class ViewRoot extends Handler implements ViewParent,  
  2.         View.AttachInfo.Callbacks {  
  3.     ......  
  4.   
  5.     public void die(boolean immediate) {  
  6.         if (immediate) {  
  7.             doDie();  
  8.         } else {  
  9.             ......  
  10.         }  
  11.     }  
  12.       
  13.     ......  
  14. }  
        上面Step 8传进来的immediate参数为true，因此，这里直接调用doDie函数来进一步处理。

        Step 10. ViewRoot.doDie

        这个函数定义在frameworks/base/core/java/android/view/ViewRoot.java文件中：

view plain
  1. public final class ViewRoot extends Handler implements ViewParent,  
  2.         View.AttachInfo.Callbacks {  
  3.     ......  
  4.   
  5.     void doDie() {  
  6.         ......  
  7.   
  8.         synchronized (this) {  
  9.             ......  
  10.   
  11.             if (mAdded) {  
  12.                 mAdded = false;  
  13.                 dispatchDetachedFromWindow();  
  14.             }  
  15.         }  
  16.     }  
  17.       
  18.     ......  
  19. }  
        当我们把Activity窗口中的View添加到一个ViewRoot对象时，就会把它的成员变量mAdded设置为true，这样就表示这个ViewRoot中有View存在，于是，这里就会调用dispatchDetachedFromWindow函数来进一步处理。

        Step 11. ViewRoot.ispatchDetachedFromWindow

        这个函数定义在frameworks/base/core/java/android/view/ViewRoot.java文件中：

view plain
  1. public final class ViewRoot extends Handler implements ViewParent,  
  2.         View.AttachInfo.Callbacks {  
  3.     ......  
  4.   
  5.     void dispatchDetachedFromWindow() {  
  6.         ......  
  7.   
  8.         if (mInputChannel != null) {  
  9.             if (mInputQueueCallback != null) {  
  10.                 ......  
  11.             } else {  
  12.                 InputQueue.unregisterInputChannel(mInputChannel);  
  13.             }  
  14.         }  
  15.   
  16.         try {  
  17.             sWindowSession.remove(mWindow);  
  18.         } catch (RemoteException e) {  
  19.         }  
  20.   
  21.         ......  
  22.     }  
  23.   
  24.     ......  
  25. }  
        前面在介绍应用程序注册键盘消息接收通道的过程时，在Step 18，我们说到，ViewRoot类中的mInputQueueCallback为null，表示由这个ViewRoot自己来管理键盘输入事件，因此，这里首先会调用InputQueue的unregisterInputChannel函数来注销注册在应用程序这一侧的Client端InputChannel，然后再调用sWindowSession的remove函数来注销注册在InputManager这一侧的Server端InputChannel，这个逻辑是和前面介绍应用程序注册键盘消息接收通道的逻辑相对应的，前面分别注册了这两个InputChannel，现在Activity要销毁了，当然就要把它们注销了。

        我们先来看注销注册在应用程序这一侧的Client端InputChannel，然后再回过头来分析注销注册在InputManager这一侧的Server端InputChannel。

        Step 12. InputQueue.unregisterInputChannel

        这个函数定义在frameworks/base/core/java/android/view/InputQueue.java文件中：

view plain
  1. public final class InputQueue {  
  2.     ......  
  3.   
  4.     public static void unregisterInputChannel(InputChannel inputChannel) {  
  5.         ......  
  6.   
  7.         synchronized (sLock) {  
  8.             ......  
  9.   
  10.             nativeUnregisterInputChannel(inputChannel);  
  11.         }  
  12.     }  
  13.   
  14.     ......  
  15. }  
         这个函数只是简单地调用本地方法nativeUnregisterInputChannel来执行具体的操作。

         Step 13. InputQueue.nativeUnregisterInputChannel
         这个函数定义在frameworks/base/core/jni/android_view_InputQueue.cpp文件中：

view plain
  1. static void android_view_InputQueue_nativeUnregisterInputChannel(JNIEnv* env, jclass clazz,  
  2.         jobject inputChannelObj) {  
  3.     status_t status = gNativeInputQueue.unregisterInputChannel(env, inputChannelObj);  
  4.   
  5.     ......  
  6. }  
        这里调用NativeInputQueue的成员函数unregisterInputChannel来进一步处理。

        Step 14. NativeInputQueue.unregisterInputChannel
        这个函数定义在frameworks/base/core/jni/android_view_InputQueue.cpp文件中：

view plain
  1. status_t NativeInputQueue::unregisterInputChannel(JNIEnv* env, jobject inputChannelObj) {  
  2.     sp<InputChannel> inputChannel = android_view_InputChannel_getInputChannel(env,  
  3.         inputChannelObj);  
  4.     ......  
  5.   
  6.     { // acquire lock  
  7.         AutoMutex _l(mLock);  
  8.   
  9.         ssize_t connectionIndex = getConnectionIndex(inputChannel);  
  10.         ......  
  11.   
  12.         sp<Connection> connection = mConnectionsByReceiveFd.valueAt(connectionIndex);  
  13.         mConnectionsByReceiveFd.removeItemsAt(connectionIndex);  
  14.   
  15.         connection->status = Connection::STATUS_ZOMBIE;  
  16.   
  17.         connection->looper->removeFd(inputChannel->getReceivePipeFd());  
  18.   
  19.         env->DeleteGlobalRef(connection->inputHandlerObjGlobal);  
  20.         connection->inputHandlerObjGlobal = NULL;  
  21.         ......  
  22.     } // release lock  
  23.   
  24.     ......  
  25.     return OK;  
  26. }  
        真正的注销工作就是这里实现的了，读者可以对照前面介绍应用程序注册键盘消息接收通道过程中的Step 21（NativeInputQueue.registerInputChannel）来分析，它首先是将在之前创建的Connection对象从NativeInputQueue中的mConnectionByReceiveFd向量中删除：

view plain
  1. ssize_t connectionIndex = getConnectionIndex(inputChannel);  
  2. ......  
  3.   
  4. sp<Connection> connection = mConnectionsByReceiveFd.valueAt(connectionIndex);  
  5. mConnectionsByReceiveFd.removeItemsAt(connectionIndex);  
        然后再把这个Client端InputChannel的前向管道的读端文件描述符从应用程序主线程中的Looper对象中删除：

view plain
  1. connection->looper->removeFd(inputChannel->getReceivePipeFd());  
        这样，这个Activity窗口以后就不会接收到键盘事件了。

        最后将Connection对象中的回调对象inputHandlerOjbGlobal对象删除：

view plain
  1. env->DeleteGlobalRef(connection->inputHandlerObjGlobal);  
  2. connection->inputHandlerObjGlobal = NULL;  
        回忆一下前面我们在分析InputManager分发键盘消息给应用程序处理时，曾经说到，每当有键盘事件发生时，InputManager首先就会调用NativeInputQueue类的handleReceiveCallback函数。在这个handleReceiveCallback函数里面，NativeInputQueue会找到相应的Connection对象，然后把它里面的内部对象inputHandlerOjbGlobal作为参数来调用Java层的InputQueue类的dispatchKeyEvent函数来通知应用程序，有键盘事件发生了。在InputQueue类的dispatchKeyEvent函数里面，就是通过这个inputHandlerOjbGlobal对象来直正通知到当前激活的Activity窗口来处理这个键盘事件的。

        注册在应用程序这一侧的Client端InputChannel被注销以后，回到前面的Step 11中，我们继续分析注销注册在InputManager这一侧的Server端InputChannel。

        Step 15. WindowManagerService.Session.remove

        这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java文件中：

view plain
  1. public class WindowManagerService extends IWindowManager.Stub  
  2.         implements Watchdog.Monitor {  
  3.     ......  
  4.   
  5.     private final class Session extends IWindowSession.Stub  
  6.             implements IBinder.DeathRecipient {  
  7.         ......  
  8.   
  9.         public void remove(IWindow window) {  
  10.             removeWindow(this, window);  
  11.         }  
  12.   
  13.         ......  
  14.     }  
  15.   
  16.     ......  
  17. }  

        这个函数只是简单地调用其外部类WindowManagerService的removeWindow函数来进一步执行操作。

        Step 16. WindowManagerService.removeWindow
        这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java文件中：

view plain
  1. public class WindowManagerService extends IWindowManager.Stub  
  2.         implements Watchdog.Monitor {  
  3.     ......  
  4.   
  5.     public void removeWindow(Session session, IWindow client) {  
  6.         synchronized(mWindowMap) {  
  7.             WindowState win = windowForClientLocked(session, client, false);  
  8.             if (win == null) {  
  9.                 return;  
  10.             }  
  11.             removeWindowLocked(session, win);  
  12.         }  
  13.     }  
  14.   
  15.     ......  
  16. }  

        回忆一下前面我们在分析应用程序注册键盘消息管道的过程时，在Step 11（WindowManagerService.addWindow）中，WindowManagerService为这个即将要激活的Activity窗口创建了一个WindowState对象win，创建的时候，使用了从ViewRoot中传过来的两个参数，分别是一个Session对象session和一个IWindow对象client。 

       在这个函数中，ViewRoot传过来的两个参数session和client和上面说的两个参数是一致的，因此，这个函数首先通过参数session和client得到一个WindowState对象win，然后调用removeWindowLocked来把它从WindowManagerService删除。

        Step 17. WindowManagerService.removeWindowLocked
        这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java文件中：

view plain
  1. public class WindowManagerService extends IWindowManager.Stub  
  2.         implements Watchdog.Monitor {  
  3.     ......  
  4.   
  5.     public void removeWindowLocked(Session session, WindowState win) {  
  6.         ......  
  7.   
  8.         win.disposeInputChannel();  
  9.   
  10.         ......  
  11.     }  
  12.   
  13.     ......  
  14. }  
        我们忽略了这个函数的其它逻辑，只关注注销之前注册的Server端InputChannel的逻辑，这里，注销的操作就是调用win的disposeInputChannel进行的了。

        Step 18. WindowState.disposeInputChannel

        这个函数定义在frameworks/base/services/java/com/android/server/WindowManagerService.java文件中：

view plain
  1. public class WindowManagerService extends IWindowManager.Stub  
  2.         implements Watchdog.Monitor {  
  3.     ......  
  4.   
  5.     private final class WindowState implements WindowManagerPolicy.WindowState {  
  6.         ......  
  7.   
  8.         void disposeInputChannel() {  
  9.             if (mInputChannel != null) {  
  10.                 mInputManager.unregisterInputChannel(mInputChannel);  
  11.   
  12.                 mInputChannel.dispose();  
  13.                 mInputChannel = null;  
  14.             }  
  15.         }  
  16.   
  17.         ......  
  18.     }  
  19.   
  20.     ......  
  21. }  
        上面说到，在前面分析应用程序注册键盘消息管道的过程时，在Step 11（WindowManagerService.addWindow）中，为当前这个Activity窗口创建了一个WindowState对象，接着创建了一个输入管道后，把Server端的InputChannel保存了在这个WindowState对象的成员变量mInputChannel中，因此，这里，就可以把它取回来，然后调用mInputManager对象的unregisterInputChannel函数来把它注销掉了。

        Step 19. InputManager.unregisterInputChannel

        这个函数定义在frameworks/base/services/java/com/android/server/InputManager.java文件中：

view plain
  1. public class InputManager {  
  2.     ......  
  3.   
  4.     public void unregisterInputChannel(InputChannel inputChannel) {  
  5.         ......  
  6.   
  7.         nativeUnregisterInputChannel(inputChannel);  
  8.     }  
  9.   
  10.     ......  
  11. }  
         这个函数很简单，它调用本地方法nativeUnregisterInputChannel来进一步处理。

         Step 20. InputManager.nativeUnregisterInputChannel

         这个函数定义在frameworks/base/services/jni/com_android_server_InputManager.cpp文件中：

view plain
  1. static void android_server_InputManager_nativeUnregisterInputChannel(JNIEnv* env, jclass clazz,  
  2.         jobject inputChannelObj) {  
  3.     ......  
  4.   
  5.   
  6.     sp<InputChannel> inputChannel = android_view_InputChannel_getInputChannel(env,  
  7.                         inputChannelObj);  
  8.     ......  
  9.   
  10.   
  11.     status_t status = gNativeInputManager->unregisterInputChannel(env, inputChannel);  
  12.   
  13.     ......  
  14. }  
        这个函数首先调用android_view_InputChannel_getInputChannel函数根据Java层的InputChannel对象找到C++层的InputChannel对象，然后调用NativeInputManager的unregisterInputChannel函数来执行注销的操作。

        Step 21. NativeInputManager.unregisterInputChannel
        这个函数定义在frameworks/base/services/jni/com_android_server_InputManager.cpp文件中：

view plain
  1. status_t NativeInputManager::unregisterInputChannel(JNIEnv* env,  
  2.         const sp<InputChannel>& inputChannel) {  
  3.     ......  
  4.   
  5.     return mInputManager->getDispatcher()->unregisterInputChannel(inputChannel);  
  6. }  
       这个函数与前面分析应用程序注册键盘消息通道的Step 17（NativeInputManager.registerInputChannel）相对应，主要是调用InputDispatcher对象的unregisterInputChannel函数来执行真正注销的操作。

       Step 22. InputDispatcher.unregisterInputChannel
       这个函数定义在frameworks/base/libs/ui/InputDispatcher.cpp文件中：

view plain
  1. status_t InputDispatcher::unregisterInputChannel(const sp<InputChannel>& inputChannel) {  
  2.     ......  
  3.   
  4.     { // acquire lock  
  5.         AutoMutex _l(mLock);  
  6.   
  7.         ssize_t connectionIndex = getConnectionIndexLocked(inputChannel);  
  8.         ......  
  9.   
  10.         sp<Connection> connection = mConnectionsByReceiveFd.valueAt(connectionIndex);  
  11.         mConnectionsByReceiveFd.removeItemsAt(connectionIndex);  
  12.   
  13.         ......  
  14.   
  15.         mLooper->removeFd(inputChannel->getReceivePipeFd());  
  16.   
  17.         .....  
  18.   
  19.     } // release lock  
  20.   
  21.     ......  
  22.   
  23.     return OK;  
  24. }  
        这一步与前面的Step 14注销应用程序一侧的Client端InputChannel是差不多的，只不过这里是从InputDispatcher中把Server端的InputChannel注销掉。首先是根据传进来的参数inputChannel找到它在InputDispatcher中对应的Connection对象在mConnectionsByReceiveFd中的索引，然后把它从mConnectionsByReceiveFd中删除：

view plain
  1. ssize_t connectionIndex = getConnectionIndexLocked(inputChannel);  
  2.     ......  
  3.   
  4. sp<Connection> connection = mConnectionsByReceiveFd.valueAt(connectionIndex);  
  5. mConnectionsByReceiveFd.removeItemsAt(connectionIndex);  
        最后，还需要把这个InputChannel中的反向管道读端文件描述符从InputDispatcher的内部对象mLooper中删除，因为这个文件描述符是在前面注册Server端的InputChannel时加入到mLooper对象去的，具体可以参考上面分析应用程序注册键盘消息接收通道的过程中的Step 18（InputDispatcher.registerInputChannel）。

        这样， 应用程序注销键盘消息接收通道的过程就分析完成了，整个应用程序键盘消息处理机制也分析完成了，这是一个比较复杂的过程，要完全理解它还需要花费一些努力和时间，不过，理解了这个过程之后，对Android应用程序框架层的理解就更进一步了。

转自：老罗的Android应用程序键盘（Keyboard）消息处理机制分析

SimbaYu7
关注
专栏目录
android应用程序键盘事件机制
王学明
02-27 2833
启动初始化 Android的键盘事件由InputManager监控。 先来看下InputManager是如何启动的。 Android在启动的时候，Zygote会启动SystemServer.java 目录：frameworks/base/services/java/com/android/server/SystemServer.java class ServerThread {
KeyboardMessage
09-12
见文知义keyboard库，功能就是将arduino 模拟成一个usb键盘。 Api如下 •Keyboard.begin() •Keyboard.end() •Keyboard.press() •Keyboard.print() •Keyboard.println() •Keyboard.release() •Keyboard.releaseAll() •Keyboard.write()
Android应用程序键盘（Keyboard）消息处理机制分析（三）
yanlijun250
12-17 905
上接：Android应用程序键盘（Keyboard）消息处理机制分析（二） ------- 3.InputManager分发键盘消息给应用程序的过程分析 在分析InputManager分发键盘消息给应用程序的过程之前，我们先假设现在没有键盘事件发生，因此，InputManager中的InputReader正在睡眠等待键盘事件的发生，而InputMan...
Programming Windows （五）_Keyboard Message
scoollau的专栏
03-16 621
A window procedure can determine when its window has the input focus by trapping WM_SETFOCUS and WM_KILLFOCUS messages. WM_SETFOCUS indicates that the window is receiving the input focus, and WM_K
Android应用程序键盘（Keyboard）消息处理机制分析（二）
yanlijun250
12-17 201
上接：Android应用程序键盘（Keyboard）消息处理机制分析（一） ----- 2.应用程序注册键盘消息接收通道的过程分析 InputManager启动以后，就开始负责监控键盘输入事件了。当InputManager监控到键盘输入事件时，它应该把这个键盘事件分发给谁呢？当然是要把这个键盘消息分发给当前激活的Activity窗口了，不过，当前激活的Activity窗口...
Android应用程序键盘（Keyboard）消息处理机制分析.doc
07-08
Android应用程序键盘（Keyboard）消息处理机制分析
Android应用程序键盘（Keyboard）消息处理机制分析
03-03
### Android应用程序键盘（Keyboard）消息处理机制分析 #### InputManager的启动过程分析 在Android系统中，键盘事件的监控和管理是由`InputManager`服务负责的。这一过程始于`SystemServer`启动`...
浅谈Android应用程序键盘消息处理机制.pdf
04-12
一个牛人写的博客，虽然名为浅谈，实际非常详尽 从注册到事件上传都有，复制下来竟然有... 收一元辛苦费，没积分的同学自己看博客吧： http://www.itivy.com/android/archive/2011/10/25/android-keyboard-message.html
键盘(Keyboard)
04-05
2. **事件监听机制**：AndroidKeyboardWatcher的核心在于事件监听，它可以捕获到用户何时触发软键盘的打开或关闭，并通知应用程序进行相应的响应。 3. **Java与Kotlin编程**：作为Android开发的一部分，可能涉及到...
KeyBoardPatch
05-08
解决安卓软键盘遮挡和顶部title被顶上去问题
Android应用程序键盘（Keyboard）消息处理机制分析（1）
weixin_33694172的博客
10-24 123
        在Android系统中，键盘按键事件是由WindowManagerService服务来管理的，然后再以消息的形式来分发给应用程序处理，不过和普通消息不一样，它是由硬件中断触发的；在上一篇文章《Android应用程序消息处理机制（Looper、Handler）分析》中，我们分析了Android应用程序的消息处理机制，本文将结合这种消息处理机制来详细分析Android应用程序是如何获得...
Keyboard
谁的青春不迷茫
01-07 1007
http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html
Hiren's BootCD 9.4 + keyboard patch
Linhanshi Blog
02-18 1276
 Hirens Boot CD is a boot CD containing various diagnostic programs such as partitioning agents, system performance benchmarks, disk cloning and imaging tools, data recovery tools, MBR tools, BIOS to
《老罗的Android之旅》阅读笔记——键盘(Keyboard)消息处理机制
WYYZ5的专栏
12-24 1138
Android应用程序获得键盘按键消息的过程： InputManager的启动过程应用程序注册键盘消息接收通道的过程InputManager分发键盘消息给应用程序的过程应用程序注销键盘消息接收通道的过程 InputManager的启动过程 Android系统的键盘事件是由InputManager来监控的，而InputManager是由窗口管理服务WindowManagerServic
解决安卓软键盘遮挡和顶部title被顶上去问题
qq_33886657的博客
04-23 2265
1、工具类KeyBoardPatch 下载 2、使用方法 2-1、任意新建一个Activity,在AndroidMainifest配置android:windowSoftInputMode="stateHidden|adjustPan" 2-2、Activity布局文件中，最外层控件设置id。 android:id="@+id/content" 2-3、Activity的onCrea...
Android应用程序键盘（Keyboard）消息处理机制分析（25）
weixin_33885253的博客
11-08 54
Step 2. ActivityStack.activityIdleInternal 这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityStack.java文件中： publicclassActivityStack{ ........
android键盘关闭回调函数,Android Kotlin 监听软键盘弹出与关闭
weixin_35853083的博客
05-26 611
前言众所周知，google是没有为android提供官方的API来监听软键盘的弹出与关闭的，通俗的做法都是监听Activity这个window的布局变化来判断是否弹出/关闭软键盘代码实现需要说明的是，这儿并不使用ViewTreeObserver.OnGlobalLayoutListener来实现对布局的监听，而是会开一个子线程定时检查，因为在实际生产中发现，onGlobalLayout()的刷新时...
Windows钩子技术：键盘消息拦截与处理
钩子是系统提供的一种机制，它允许在系统消息传递过程中插入自定义的处理程序，从而实现对特定事件的监听和响应。通过安装键盘钩子，我们可以拦截键盘消息，即使这些消息是发往其他应用程序的，从而在用户不察觉的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值