Android Input（七）-ViewRootImpl处理事
原创内容，转载请注明出处，多谢配合。
上一篇分析了ViewRootImpl接收事件，最终事件由InputStage实现类执行onProcess(q)来处理。那么本篇文章就来具体看看事件是如何处理的。
接上篇，我们知道Activity和View的事件的事件处理对于的InputStage为ViewPostImeInputStage，而事件的处理核心方法在onProcess(q)。
frameworks/base/core/java/android/view/ViewRootImpl.java
final class ViewPostImeInputStage extends InputStage {
public ViewPostImeInputStage(InputStage next) {
super(next);
}
@Override
protected int onProcess(QueuedInputEvent q) {
if (q.mEvent instanceof KeyEvent) {
return processKeyEvent(q); //对于的是按键事件处理
} else {
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);
}
}
}
...
}
这里我们主要来分析下触摸事件的处理：
private int processPointerEvent(QueuedInputEvent q) {
...
boolean handled = mView.dispatchPointerEvent(event);
...
}
mView变量是在setview方法中赋值的,对于应用窗口来说, mView变量指向PhoneWindow的内部类DecorView对象。但是调用的是父类View的dispatchPointerEvent方法。
frameworks/base/core/java/android/view/View.java
public final boolean dispatchPointerEvent(MotionEvent event) {
if (event.isTouchEvent()) {
return dispatchTouchEvent(event);//处理touchEvent
} else {
return dispatchGenericMotionEvent(event);
}
}
dispatchTouchEvent这个方法会被子类重写，这里子类对应的是viewtree的根视图：DecorView
frameworks/base/core/java/com/android/internal/policy/DecorView.java
public boolean dispatchTouchEvent(MotionEvent ev) {
final Window.Callback cb = mWindow.getCallback();
return cb != null && !mWindow.isDestroyed() && mFeatureId < 0
? cb.dispatchTouchEvent(ev) : super.dispatchTouchEvent(ev);
}
Activity和Dialog都是Callback接口的具体实现,主要看Activity的dispatchTouchEvent方法：
public boolean dispatchTouchEvent(MotionEvent ev) {
if (ev.getAction() == MotionEvent.ACTION_DOWN) {
onUserInteraction();
}
if (getWindow().superDispatchTouchEvent(ev)) {
return true;
}
return onTouchEvent(ev);
}
getWindow对应的是PhoneWindow，调用它的superDispatchTouchEvent方法,如果未处理才继续调用onTouchEvent方法。
public boolean superDispatchTouchEvent(MotionEvent event) {
return mDecor.superDispatchTouchEvent(event);
}
调用DecorView的superDispatchTouchEvent
public boolean superDispatchTouchEvent(MotionEvent event) {
return super.dispatchTouchEvent(event);
}
从这里开始真正的View Tree的事件传递和消费。
public boolean dispatchTouchEvent(MotionEvent event) {
// If the event should be handled by accessibility focus first.
if (event.isTargetAccessibilityFocus()) {
// We don't have focus or no virtual descendant has it, do not handle the event.
if (!isAccessibilityFocusedViewOrHost()) {
return false;
}
// We have focus and got the event, then use normal event dispatch.
event.setTargetAccessibilityFocus(false);
}
boolean result = false;
if (mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onTouchEvent(event, 0);
}
final int actionMasked = event.getActionMasked();
if (actionMasked == MotionEvent.ACTION_DOWN) {
// Defensive cleanup for new gesture
stopNestedScroll();
}
if (onFilterTouchEventForSecurity(event)) {
if ((mViewFlags & ENABLED_MASK) == ENABLED && handleScrollBarDragging(event)) {
result = true;
}
//noinspection SimplifiableIfStatement
ListenerInfo li = mListenerInfo;
if (li != null && li.mOnTouchListener != null
&& (mViewFlags & ENABLED_MASK) == ENABLED
&& li.mOnTouchListener.onTouch(this, event)) {
result = true;
}
if (!result && onTouchEvent(event)) {
result = true;
}
}
if (!result && mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onUnhandledEvent(event, 0);
}
// Clean up after nested scrolls if this is the end of a gesture;
// also cancel it if we tried an ACTION_DOWN but we didn't want the rest
// of the gesture.
if (actionMasked == MotionEvent.ACTION_UP ||
actionMasked == MotionEvent.ACTION_CANCEL ||
(actionMasked == MotionEvent.ACTION_DOWN && !result)) {
stopNestedScroll();
}
return result;
}
View事件传递过程分析网上一抓一大把，这里就不赘述了，贴点我之前的总结吧：
一、 事件处理函数
dispatchTouchEvent(分发)、onInteceptTouchEvent(过滤)、onTouchEvent(处理)
其中onInteceptTouchEvent只有ViewGroup才有。
二、 处理函数的分发流程
两条主线：
onInteceptTouchEvent: 父 -->子
-拦截（true）：ViewGroup自己的onTouchEvent处理。
-不拦截（false）：传递到子View去处理。
onTouchEvent: 子-->父
-消费（true）：View自己的onTouchEvent处理。
-不消费（false）：传递到父ViewGroup去处理
三、 事件传递Activity、ViewGroup、View详细逻辑
事件传递从Activity开始，再到最底层ViewGroup，最后才到子View。
Activity
- 首先会触发Activity的dispatchTouchEvent方法。
- dispatchTouchEvent方法中如果是ACTION_DOWN的情况下会接着触发onUserInteraction方法。
- 接着在dispatchTouchEvent方法中会通过Activity的root View（id为content的FrameLayout），实质是ViewGroup，通过super.dispatchTouchEvent把touchevent派发给各个activity的子view，也就是我们再Activity.onCreat方法中setContentView时设置的view。
- 若Activity下面的子view拦截了touchevent事件(返回true)则Activity.onTouchEvent方法就不会执行。
ViewGroup
- Android事件派发是先传递到最顶级的ViewGroup，再由ViewGroup递归传递到View的。
- 在ViewGroup中可以通过onInterceptTouchEvent方法对事件传递进行拦截，onInterceptTouchEvent方法返回true代表不允许事件继续向子View传递，返回false代表不对事件进行拦截，默认返回false。
- 子View中如果将传递的事件消费掉，ViewGroup中将无法接收到任何事件。
View
- 触摸控件（View）首先执行dispatchTouchEvent方法。
- 在View的dispatchTouchEvent方法中先执行onTouch方法，后执行onClick方法（onClick方法在onTouchEvent中执行）。
- 如果控件（View）的onTouch返回false或者mOnTouchListener为null（控件没有设置setOnTouchListener方法）或者控件不是enable的情况下会调用onTouchEvent，dispatchTouchEvent返回值与onTouchEvent返回一样。
- 如果控件不是enable的设置了onTouch方法也不会执行，只能通过重写控件的onTouchEvent方法处理，dispatchTouchEvent返回值与onTouchEvent返回一样。
- 如果控件（View）是enable且onTouch返回true情况下，dispatchTouchEvent直接返回true，不会调用onTouchEvent方法。
- 当dispatchTouchEvent在进行事件分发的时候，只有前一个action返回true，才会触发下一个action（也就是说dispatchTouchEvent返回true才会进行下一次action派发）。
四、 View的各种事件处理顺序
优先级：onTouch > onTouchEvent > onLongClick > onClick
在View的onTouchEvent down中onLongClick起了一个子线程来执行这个事件，而在up时，在主线程中执行onClick。
另外需要注意的是，onTouch能够得到执行需要两个前提条件，第一mOnTouchListener的值不能为空，第二当前点击的控件必须是enable的。因此如果你有一个控件是非enable的，那么给它注册onTouch事件将永远得不到执行。对于这一类控件，如果我们想要监听它的touch事件，就必须通过在该控件中重写onTouchEvent方法来实现。
五、事件拦截处理
-
子容器控制父容器的拦截：
父容器 .requestDisallowInterceptTouchEvent(true);//true表示放行,false表示拦截 -
父容器主动控制：重写dispatchTouchEvent or onInteceptTouchEvent
最后还有一个重要的问题需要分析：事件处理完了如何通知InputDispatcher去回调Callback？
简单跟下代码：
private void finishInputEvent(QueuedInputEvent q) {
...
q.mReceiver.finishInputEvent(q.mEvent, handled);
...
}
frameworks/base/core/java/android/view/InputEventReceiver.java
public final void finishInputEvent(InputEvent event, boolean handled) {
...
nativeFinishInputEvent(mReceiverPtr, seq, handled);
...
}
static void nativeFinishInputEvent(JNIEnv* env, jclass clazz, jlong receiverPtr,
jint seq, jboolean handled) {
sp<NativeInputEventReceiver> receiver =
reinterpret_cast<NativeInputEventReceiver*>(receiverPtr);
status_t status = receiver->finishInputEvent(seq, handled);
if (status && status != DEAD_OBJECT) {
String8 message;
message.appendFormat("Failed to finish input event. status=%d", status);
jniThrowRuntimeException(env, message.string());
}
}
frameworks/base/core/jni/android_view_InputEventReceiver.cpp
status_t NativeInputEventReceiver::finishInputEvent(uint32_t seq, bool handled) {
...
status_t status = mInputConsumer.sendFinishedSignal(seq, handled);
...
}
frameworks/native/libs/input/InputTransport.cpp
status_t InputConsumer::sendFinishedSignal(uint32_t seq, bool handled) {
...
return sendUnchainedFinishedSignal(seq, handled);
}
status_t InputConsumer::sendUnchainedFinishedSignal(uint32_t seq, bool handled) {
InputMessage msg;
msg.header.type = InputMessage::TYPE_FINISHED;
msg.body.finished.seq = seq;
msg.body.finished.handled = handled;
return mChannel->sendMessage(&msg);
}
客户端事件分发处理完毕后会执行finishInputEvent，按如上流程最终会通过InputChannel 发送完成的message, 服务端收到消息后回调InputDispatcher.handleReceiveCallback()，最终会调用doDispatchCycleFinishedLockedInterruptible()方法 ,将dispatchEntry事件从等待队列(waitQueue)中移除。
ViewRootImpl处理事件就分析完了，这一套流程下来确实也是挺复杂的，而且细节特别多。这个系列也只是走了个主线流程而已，碰到具体问题还需要去抠代码细节。
下一篇文章：
Android Input（八）- ANR原理分析
