input的处理细节比较复杂,在app端时,是通过监听input channel的fd,把事件接入到主线程的looper中,所以我们可以看到,相关的处理是在主线程中进行的,
再进行一个试验,在onTouchEvent方法中,对MOTION_DOWN和MOTION_MOVE 事件处理分别打印堆栈,大家觉得会是一样的么?
试一下,就会发现,处理流程不一样,头尾是相同的,但是中间出现了分支,
同样的touch事件,分成了2种流程,一种相思两处闲愁,这样的处理确实让人发愁。
move事件的处理调用到choreographer相关处理。
为什么会这样,在哪里进行的区分呢?
这里大致看一下,
在注册input的fd到主线程loopper的时候,设置了回调方法,当有数据到来的时候,会调用到
frameworks/base/core/jni/android_view_InputEventReceiver.cpp
int NativeInputEventReceiver::handleEvent(int receiveFd, int events, void* data)
又调用到
status_t NativeInputEventReceiver::consumeEvents(JNIEnv* env,
220 bool consumeBatches, nsecs_t frameTime, bool* outConsumedBatch)
这里的处理比较复杂,
对于move事件,似乎调用到了这里,意图进行批量处理
261 env->CallVoidMethod(receiverObj.get(),
262 gInputEventReceiverClassInfo.dispatchBatchedInputEventPending);
对于down和up事件,似乎走到了这里,直接调用dispatchInputEvent进行分发,
317 env->CallVoidMethod(receiverObj.get(),
318 gInputEventReceiverClassInfo.dispatchInputEvent, seq, inputEventObj,
319 displayId);
处理的比较复杂,有时间再细看一下,这里猜测move事件可能是会合并到MOTION_EVENT的hisroty数据里面,这样来保证数据不丢失和让touch事件和vsync信号同步。
参考资料
Android Input系统5 UI线程_Big Skipper的博客-CSDN博客
Android GPU呈现模式原理及卡顿掉帧浅析 - 简书
|