浅谈Android之Activity触摸事件传输机制介绍

8 Activity触摸事件传输机制介绍

当我们触摸屏幕的时候，程序会收到对应的触摸事件，这个事件是在app端去读取的吗？肯定不是，如果app能读取，那会乱套的，所以app不会有这个权限，系统按键的读取以及分发都是通过WindowManagerService来完成

 

在WMS中，它的管理单位是WindowState，当你点击屏幕时，它会根据Z-Order顺序找到top & focus WindowState来handle这个事件，然后再跨进程传给App端对应的Window, App端Window对应的代码主体就是ViewRootImpl

 

接下去我们来看看ViewRootImpl是如何接收WMS发来的事件以及发送到对应的Décor view的

 

8.1 触摸事件数据如何跨进程传输

触摸事件从WMS跨进程传给App端，跨进程通讯方式采用的是基于socketpair双工通讯，可能大家会问，Android进程间通讯不都是基于Binder来传输的吗？为什么不用binder？

让我们回顾下Binder的优势：

1）  支持RPC，也就是说我们可以很方便实现复杂的数据交互指令

2）  内存拷贝次数会比socket等方式少

 

但是考虑到触摸事件数据是非常小的，而且就是简单的数据传输，不需要RPC操作，这个时候如果采用binder，基本上就不存在什么优势，可能效率还赶不上socketpair双工通讯，因为数据量太小，内存拷贝次数减少的优势基本可以忽略，而且支持RPC还需要额外的开销

 

还有更重要的原因，就是socket Pair返回的是file descriptor，这样就意味着，可以共用主线程Looper对其file descriptor的状态进行监听，具体细节下面会介绍

 

socketPair是基于c++的，Android实现InputChannel对这部分代码进行封装

创建过程如下：

InputChannel[] inputChannels = InputChannel.openInputChannelPair(name);

 

openInputChannelPair最终会调用native函数，通过jni调用c++代码创建socketpair，然后基于新创建的socket file descriptor对来创建InputChannel对并返回到Java层，由于

InputChannel是parcelable的，接下去只需要把其中一个InputChannel通过Binder传到另一进程，另外进程拿到后，二者就可以基于InputChannel进行数据共享了

 

但是InputChannel只是利用JNI基于C++对file descriptor和数据的读取操作进行封装，所以还需要封装一个类用于对InputChannel 对应的filedescriptor 进行监听，并在

file descriptor ready的时候，及时触发InputChannel的读取操作并将数据通过JNI回调到Java层(发送在WMS端，如果扩展开，篇幅太大，这边就不做介绍了)

 

这个类是WindowInputEventReceiver，它派生自InputEventReceiver，详细的下面介绍

 

接着看ViewRootImpl.setView中相关代码：

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {         synchronized (this) {             if (mView == null) {                 mView = view;               …… if ((mWindowAttributes.inputFeatures             & WindowManager.LayoutParams.INPUT_FEATURE_NO_INPUT_CHANNEL) == 0) {                     mInputChannel = new InputChannel();                 }                 try {                     mOrigWindowType = mWindowAttributes.type;                     mAttachInfo.mRecomputeGlobalAttributes = true;                     collectViewAttributes();                     res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,                             getHostVisibility(), mDisplay.getDisplayId(),                             mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,mInputChannel);                 } catch (RemoteException e) {                   ……                 } finally {                     if (restore) {                         attrs.restore();                     }                 }                 ……                 if (mInputChannel != null) {                     if (mInputQueueCallback != null) {                         mInputQueue = new InputQueue();                         mInputQueueCallback.onInputQueueCreated(mInputQueue);                     }                    mInputEventReceiver = new WindowInputEventReceiver(mInputChannel,                             Looper.myLooper());                 }                 ……                 // Set up the input pipeline.                 CharSequence counterSuffix = attrs.getTitle();                 mSyntheticInputStage = new SyntheticInputStage();                 InputStage viewPostImeStage = new ViewPostImeInputStage(mSyntheticInputStage);                 InputStage nativePostImeStage = new NativePostImeInputStage(viewPostImeStage,                         "aq:native-post-ime:" + counterSuffix);                 InputStage earlyPostImeStage = new EarlyPostImeInputStage(nativePostImeStage);                 InputStage imeStage = new ImeInputStage(earlyPostImeStage,                         "aq:ime:" + counterSuffix);                 InputStage viewPreImeStage = new ViewPreImeInputStage(imeStage);                 InputStage nativePreImeStage = new NativePreImeInputStage(viewPreImeStage,                         "aq:native-pre-ime:" + counterSuffix);                   mFirstInputStage = nativePreImeStage;                 mFirstPostImeInputStage = earlyPostImeStage;                 mPendingInputEventQueueLengthCounterName = "aq:pending:" + counterSuffix;             }         } }

 

首先调用new InputChannel创建InputChannel对象并保存到mInputChannel，不过目前这个对象是不包含实质的File Descriptor的

 

接着调用addToDisplay传入mInputChannel，WMS在创建WindowSate的同时会对应的创建InputChannelPair，然后将其中一个InputChannel保存到mInputChannel返回，至此，

mInputChannel才真正包含了跟WMS中对应WindowState中保存的InputChannel相关联的File Descriptor

 

接下去调用：

mInputEventReceiver = new WindowInputEventReceiver(mInputChannel, Looper.myLooper());

 

WindowInputEventReceiver构造时传入两个参数，一个是InputChannel，另外一个是当前线程，也就是主线程的Looper

 

InputChannel包含要监听的File descriptor，那Looper当然就是用于File descriptor的监听了，

Looper原理是在构造的时候，创建epoll和pipe描述符，并且通过对pipe描述符的监听以及设置监听超时时间来触发从messagequeue中获取queue item数据并回调到handler，所以，通过Looper来监听并触发InputChannel读取没任何问题(详细可以看Looper的源码，这里不做过多介绍了)

 

那还有个疑问，为什么要用主线程的Looper，而不是新创建一个呢？大家记得ANR吗？

当你连续触摸屏幕的时候，如果按键事件超过一定时间没被处理，系统会弹出对话框，显示App无响应

 

翻译成代码逻辑就是，WMS往App当前显示的窗口对应的WindowState中包含的InputChannel写入了按键数据，然后由于App端的Looper在处理当次回调时存在耗时操作，从而导致Looper的下一次pollOnce被延后执行，进而导致App过晚监听到InputChannel的file descriptor的状态改变，影响了对InputChannel中按键数据的及时读取并下发

 

这就是采用主线程Looper的原因

 

数据读取到后，最终会通过Jni回调到Java类InputEventReceiver的如下函数：

@SuppressWarnings("unused")     private void dispatchInputEvent(int seq, InputEvent event) {         mSeqMap.put(event.getSequenceNumber(), seq);         onInputEvent(event); }

 

接着调用WindowInputEventReceiver的onInputEvent

 

最后用一句话总结下，WMS端通过WindowState关联的InputChannel发送按键数据后，App端的ViewRootImpl内的WindowInputEventReceiver实例对应的onInputEvent函数会被回调，参数即为按键数据

 

8.2 App收到触摸事件如何传到DecorView

在App端收到onInputEvent后，接下去数据的传递就是按函数顺序调用，接着直接基于代码来分析：

//WindowInputEventReceiver public void onInputEvent(InputEvent event) { enqueueInputEvent(event, this, 0, true); }

 

接着调用enqueueInputEvent：

//ViewRootImpl void enqueueInputEvent(InputEvent event,             InputEventReceiver receiver, int flags, boolean processImmediately) {         QueuedInputEvent q = obtainQueuedInputEvent(event, receiver, flags);         ……         QueuedInputEvent last = mPendingInputEventTail;         if (last == null) {             mPendingInputEventHead = q;             mPendingInputEventTail = q;         } else {             last.mNext = q;             mPendingInputEventTail = q;         }         mPendingInputEventCount += 1;         ……         if (processImmediately) {             doProcessInputEvents();         } else {             scheduleProcessInputEvents();         } }

 

将新event添加到InputEvent queue，由于processImmediately为true，接着调用

doProcessInputEvents：

//ViewRootImpl void doProcessInputEvents() {         while (mPendingInputEventHead != null) {             QueuedInputEvent q = mPendingInputEventHead;             mPendingInputEventHead = q.mNext;             if (mPendingInputEventHead == null) {                 mPendingInputEventTail = null;             }             q.mNext = null;               mPendingInputEventCount -= 1;             ......             deliverInputEvent(q);         }         …… }

循环从Input event queue中取出event然后调用deliverInputEvent：

//ViewRootImpl private void deliverInputEvent(QueuedInputEvent q) {         ……         InputStage stage;         if (q.shouldSendToSynthesizer()) {             stage = mSyntheticInputStage;         } else {             stage = q.shouldSkipIme() ? mFirstPostImeInputStage : mFirstInputStage;         }           if (stage != null) {             stage.deliver(q);         } else {             finishInputEvent(q);         } }

 

先介绍下InputStage，其实它是一个Input process chain，每一个InputStage构造时，需要传入其next process InputStage，接着在每一个InputStage的deliver被调用时，都有权决定是否要将event继续传递给next input stage

 

mFirstPostImeInputStage和mFirstInputStage这两个InputStagechain的是在setView函数执行到最后创建的，详细的可以回过头看上面的setView代码，这两个chain的last InputStage都是ViewPostImeInputStage，这里我们先忽略IME相关的一大堆InputStage，假定Input Event最终都传递到了ViewPostImeInputStage，接着看其onProcess函数：

// ViewPostImeInputStage protected int onProcess(QueuedInputEvent q) {             if (q.mEvent instanceof KeyEvent) {                 return processKeyEvent(q);             } else {                 // If delivering a new non-key event, make sure the window is                 // now allowed to start updating.                 handleDispatchDoneAnimating();                 final int source = q.mEvent.getSource();                 if ((source & InputDevice.SOURCE_CLASS_POINTER) != 0) {                     return processPointerEvent(q);                 } else if ((source & InputDevice.SOURCE_CLASS_TRACKBALL) != 0) {                     return processTrackballEvent(q);                 } else {                     return processGenericMotionEvent(q);                 }             } }

 

接着看processPointerEvent：

private int processPointerEvent(QueuedInputEvent q) {     final MotionEvent event = (MotionEvent)q.mEvent;     ……     boolean handled = mView.dispatchPointerEvent(event);             ……             return handled ? FINISH_HANDLED : FORWARD; }

 

直接调用Décor View的dispatchPointerEvent，由于Décor View以及ViewGroup未实现该函数，所以默认跑到View.dispatchPointerEvent:

//View  public final boolean dispatchPointerEvent(MotionEvent event) {         if (event.isTouchEvent()) {             return dispatchTouchEvent(event);         } else {             return dispatchGenericMotionEvent(event);         }     }

 

接着调用DecorView的dispatchTouchEvent：

//PhoneWindow.DecorView public boolean dispatchTouchEvent(MotionEvent ev) {            final Callback cb = getCallback();            return cb != null && !isDestroyed() && mFeatureId < 0 ? cb.dispatchTouchEvent(ev)                     : super.dispatchTouchEvent(ev); }

 

先拿到PhoneWindow设置的callback，之前在介绍Activity初始化的时候说过，

在Activity.attach时创建PhoneWindow的时候会将Activity设置为PhoneWindow的callback，所以这里的cb肯定不为null，接着调用Activity的dispatchTouchEvent：

//Activity    public boolean dispatchTouchEvent(MotionEvent ev) {         if (ev.getAction() == MotionEvent.ACTION_DOWN) {             onUserInteraction();         }         if (getWindow().superDispatchTouchEvent(ev)) {             return true;         }         return onTouchEvent(ev);     }

 

到这里可以看出：

1）  Activity. dispatchTouchEvent是Activity事件分发的总入口，我们可以在自定义

Activity中重新实现该函数，即可达到对指定事件的预处理或者截获

2）  调用getWindow().superDispatchTouchEvent(ev)来实现事件在DecorView的分发

3）  如果DecorView没有处理这个事件，则调用Activity.onTouchEvent作默认处理

 

getWindow().superDispatchTouchEvent(ev)直接调用mDecor.superDispatchTouchEvent：

//PhoneWindow.DecorView public boolean superDispatchTouchEvent(MotionEvent event) { return super.dispatchTouchEvent(event); }

 

直接调用super. dispatchTouchEvent,也就是FrameLayout. dispatchTouchEvent来开始事件在

View中的分发，接下去介绍这一块的分发规则

 

8.3 触摸事件在DecorView中的分发规则

Android的Touch Event主要分四种类型：

1）   ACTION_DOWN
当用户手指按压屏幕会产生，这里就称它为前置目标锁定事件，当这个事件传递到

Decor View时，其必须要根据事件对应的坐标来锁定一个target view来处理后续事件

2）   ACTION_UP
用户手指抬起时会产生该事件，也就是上面所说的手续事件之一

3）   ACTION_MOVE
用户在屏幕移动手指时产生的事件，也是上面所说的后续事件之一

4）   ACTION_CANCEL
当一个View在ACTION_DOWN时被判定为target view后，后续ACTION_UP和

ACTION_MOVE事件都会被发送到当前target view来处理，也就是说taretview在这个时候是独享当前事件的输入的，不过targetview的parent view，也就是说它爸爸，或者它爸爸的爸爸，反正比它大的直系ViewGroup都可以在其onInterceptTouchEvent被调用时返回true完成处理权的剥夺，剥夺完成后，当前targetview会收到

ACTION_CANCEL被告知你的事件处理权被取消了，然后刚刚完成剥夺的它爹或爷爷会被设置成新的target view，用以接收后续的ACTION_UP和ACTION_MOVE事件，还有就是这种剥夺是不可逆的，一旦完成对处理权的剥夺，就无法还回去

 

接下去用一个简单的列子来介绍Décor View在收到ACTION_DOWN事件时是如何锁定targetview的

 

先看图：

 

假定DecorView有一个child view叫ViewGroup1，然后ViewGroup1有两个child view分别叫child view1和child view2

 

我们假定用户手指按在child view2和child view1的重叠区域内，这个时候DecorView会收到类型为ACTION_DOWN的触摸事件，接下去将这个ACTION_DOWN分发下去用以锁定target view，流程是这样的：

1）  Décor View会根据用户点击区域来判定点击在哪个子View上，这里当然是ViewGroup1

2）  ViewGroup1同样的，也是通过点击区域来判定目标子View，不同的是，这里child View1和child view2都符合要求，那谁先来处理ACTION_DOWN事件，当然是谁在上面谁先处理，即后添加的child view会先享有处理权，也就说，ChildView2会先处理；如果Child View2返回true，那它就会被设置为target view，反之就继续传给Child View1处理，如果Child View1返回true，锁定结束，否则就只能继续传给其parentview(ViewGroup1)处理了，因为同级已经不存在符合要求的childview了，如果ViewGroup1也是返回false，那就继续往上传，直到找到处理该事件的View为止，如果到达Décor View了都没有被处理，那最终只能调用Activity.onTouchEvent做默认处理了

 

当一个child view通过ACTION_DOWN被设置为target view后，后续它这个target view被取消，只有两种情况：

1）  收到ACTION_UP事件，用户当次触摸结束

2）  上面说过，其parent ViewGroup在处理后续事件时，在onInterceptTouchEvent被调用时返回true完成target view的切换

 

所以，如果同级child view存在重叠区域，当用户点击这个重叠区域时，最上面的child view返回true告知其处理了这个ACTION_DOWN事件，那么重叠区域下面所有的childview都是无法收到任何后续事件的

 

我们都知道Android视图是一个树形结构，所以对于在这个树形结构中的每一个ViewGroup节点来说，它只要保存它的目标childview就可以了，这样数据就能从根节点(DecorView)一级一级的传到最终的target view

 

因此，从代码的角度，我们其实只需要分析ViewGroup是如何确定其direct target child view来处理数据的，就可以以此来推出整个View Tree的数据传递过程了

 

由于分发逻辑主要在ViewGroup.dispatchTouchEvent中，接下去就基于这个函数来分析，先分析ACTION_DOWN事件是如何确定directtarget child view的 ：

//ViewGroup public boolean dispatchTouchEvent(MotionEvent ev) {         ……         boolean handled = false;         if (onFilterTouchEventForSecurity(ev)) {             final int action = ev.getAction();             final int actionMasked = action & MotionEvent.ACTION_MASK;               // Handle an initial down.             if (actionMasked == MotionEvent.ACTION_DOWN) {                 cancelAndClearTouchTargets(ev);                 resetTouchState();             }               final boolean intercepted;             if (actionMasked == MotionEvent.ACTION_DOWN                     || mFirstTouchTarget != null) {          final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;                 if (!disallowIntercept) {                     intercepted = onInterceptTouchEvent(ev);                     ev.setAction(action); // restore action in case it was changed                 } else {                     intercepted = false;                 }             } else {                 // There are no touch targets and this action is not an initial down                 // so this view group continues to intercept touches.                 intercepted = true;             }             ……             // Check for cancelation.             final boolean canceled = resetCancelNextUpFlag(this)                     || actionMasked == MotionEvent.ACTION_CANCEL;               // Update list of touch targets for pointer down, if needed.             final boolean split = (mGroupFlags & FLAG_SPLIT_MOTION_EVENTS) != 0;             TouchTarget newTouchTarget = null;             boolean alreadyDispatchedToNewTouchTarget = false;             if (!canceled && !intercepted) {                 ……    if (actionMasked == MotionEvent.ACTION_DOWN                         || (split && actionMasked == MotionEvent.ACTION_POINTER_DOWN)                         || actionMasked == MotionEvent.ACTION_HOVER_MOVE) {                     final int actionIndex = ev.getActionIndex(); // always 0 for down                     final int idBitsToAssign = split ? 1 << ev.getPointerId(actionIndex)                             : TouchTarget.ALL_POINTER_IDS;                       // Clean up earlier touch targets for this pointer id in case they                     // have become out of sync.                     removePointersFromTouchTargets(idBitsToAssign);                       final int childrenCount = mChildrenCount;                     if (newTouchTarget == null && childrenCount != 0) {                         final float x = ev.getX(actionIndex);                         final float y = ev.getY(actionIndex);                                                final ArrayList preorderedList = buildOrderedChildList();                         final boolean customOrder = preorderedList == null                                 && isChildrenDrawingOrderEnabled();                         final View[] children = mChildren;                         for (int i = childrenCount - 1; i >= 0; i--) {                            ……                             if (!canViewReceivePointerEvents(child)                                    || !isTransformedTouchPointInView(x, y, child, null)) {                                 ev.setTargetAccessibilityFocus(false);                                 continue;                             }                               newTouchTarget = getTouchTarget(child);                             if (newTouchTarget != null) {                                 newTouchTarget.pointerIdBits |= idBitsToAssign;                                 break;                             }                               resetCancelNextUpFlag(child);                        if (dispatchTransformedTouchEvent(ev, false, child, idBitsToAssign)) {                                 ……                                 mLastTouchDownX = ev.getX();                                 mLastTouchDownY = ev.getY();                                 newTouchTarget = addTouchTarget(child, idBitsToAssign);                                 alreadyDispatchedToNewTouchTarget = true;                                 break;                             }                         }                         ……                     }                       if (newTouchTarget == null && mFirstTouchTarget != null) {                         // Did not find a child to receive the event.                         // Assign the pointer to the least recently added target.                         newTouchTarget = mFirstTouchTarget;                         while (newTouchTarget.next != null) {                             newTouchTarget = newTouchTarget.next;                         }                         newTouchTarget.pointerIdBits |= idBitsToAssign;                     }                 }             }               // Dispatch to touch targets.             if (mFirstTouchTarget == null) {                 // No touch targets so treat this as an ordinary view.                 handled = dispatchTransformedTouchEvent(ev, canceled, null,                         TouchTarget.ALL_POINTER_IDS);             } else {                 // Dispatch to touch targets, excluding the new touch target if we already                 // dispatched to it.  Cancel touch targets if necessary.                 TouchTarget predecessor = null;                 TouchTarget target = mFirstTouchTarget;                 while (target != null) {                     final TouchTarget next = target.next;                     if (alreadyDispatchedToNewTouchTarget && target == newTouchTarget) {                         handled = true;                     } else {                         ……                     }                     predecessor = target;                     target = next;                 }             }           ……         return handled; }

 

ViewGroup用一个链表保存target view，链表头保存到mFirstTouchTarget，其实只对于

ACTION_DOWN事件来说，链表只会存在一个数据，也就是target child view

 

在函数一开始，判定如果是ACTION_DOWN事件，则将重置状态，包括将清除target view链表，并将mFirstTouchTarget置空等

 

接着调用ViewGroup的onInterceptTouchEvent看其是否要截断ACTION_DOWN的传输，这里假定不截断，也就是返回false，intercepted为false

 

然后从后向前遍历所有child view，通过isTransformedTouchPointInView判断点击是否在这个child view内，如果在，则调用dispatchTransformedTouchEvent将事件传给该child view处理，如果返回true，说明被这个child view处理了，然后addTouchTarget将这个child view保存为

mFirstTouchTarget并跳出循环；如果返回false，则继续调用下一个child view按相同方式进行处理

 

接下去判断mFirstTouchTarget是否为null，如果为null，说明ViewGroup要么没有child view，要么所有的child view都没有处理ACTION_DOWN事件，接着调用ViewGroup自身的

dispatchTransformedTouchEvent进行处理

 

如果mFirstTouchTarget不为null，说明有child view处理了ACTION_DOWN事件，接着遍历

mFirstTouchTarget链表依次进行事件分发，由于ACTION_DOWN事件上面已经分发过，

这里alreadyDispatchedToNewTouchTarget和target == newTarget都为true，不做任何处理，直接将handled置为true

 

mFirstTouchTarget即为ACTION_DOWN最终锁定的target view，至于其他ACTION_UP和

ACTION_MOVE还有ACTION_CANCEL的处理都比较简单，大家基于上面的分析自行看源码吧，这里就不做分析了

 

至此，触摸事件的传输机制介绍完毕