深入解析Android中的事件传递
前言
前段时间工作中遇到了一个问题，即在软键盘弹出后想监听back事件，但是在Activity中重写了对应的onKeyDown函数却怎么也监听不到，经过一阵Google之后才发现需要重写View的dispatchKeyEventPreIme函数才行。当时就觉得这个函数名字很熟悉，仔细思索一番以后才恍然大悟，当初看WMS源码的时候有过这方面的了解，现在却把它忘到了九霄云外，于是决定写这篇文章，权当记录。
InputManagerService
首先我们知道，不论是“键盘事件”还是“点击事件”，都是系统底层传给我们的，当然这里最底层的LinuxKernel我们不去讨论，我们的起点从Framework层开始。有看过AndroidFramework层源码的同学已经比较清楚，其中存在非常多的XXXManagerService，它们运行在system_server进程中，著名的如AMS(ActivityManagerService)和WMS(WindowManagerService)等等。这里和Android事件相关的Service就是InputManagerService，那么就先让我们看看它是如何进行工作的吧。
publicvoidstart(){
Slog.i(TAG,"Startinginputmanager");
nativeStart(mPtr);
........
}
看到这个nativeStart，是不是倒吸一口凉气，没错，是一个native方法。不过这也没办法，毕竟底层嘛，少不了和c打交道～
staticvoidnativeStart(JNIEnv*env,jclass/*clazz*/,jlongptr){
NativeInputManager*im=reinterpret_cast(ptr);
status_tresult=im->getInputManager()->start();
if(result){
jniThrowRuntimeException(env,"Inputmanagercouldnotbestarted.");
}
}
可以看到，调用了InputManager的start方法。
status_tInputManager::start(){
status_tresult=mDispatcherThread->run("InputDispatcher",PRIORITY_URGENT_DISPLAY);
if(result){
ALOGE("CouldnotstartInputDispatcherthreadduetoerror%d.",result);
returnresult;
}
result=mReaderThread->run("InputReader",PRIORITY_URGENT_DISPLAY);
if(result){
ALOGE("CouldnotstartInputReaderthreadduetoerror%d.",result);
mDispatcherThread->requestExit();
returnresult;
}
returnOK;
}
其中初始化了两个线程——ReaderThread和DispatcherThread。这两个线程的作用非常重要，前者接受来自设备的事件并且将其封装成上层看得懂的信息，后者负责把事件分发出去。可以说，我们上层的Activity或者是View的事件，都是来自于这两个线程。这里我不展开讲了，有兴趣的同学可以自行根据源码进行分析。有趣的是，DispatcherThread在轮询点击事件的过程中，采用的Looper的形式，可见Android中的源码真的是处处相关联，所以不要觉得某一部分的源码看了没用，说不定以后你就会用到了。
ViewRootImpl
从前一小节我们得知，设备的点击事件是通过InputManagerService来进行传递的，其中存在两个线程一个用于处理，一个用于分发，那么事件分发到哪里去呢？直接发到Activity或者View中吗？这显然是不合理的，所以Framework层中存在一个ViewRootImpl类，作为两者沟通的桥梁。需要注意的是，该类在老版本的源码中名为ViewRoot。
ViewRootImpl这个类是在Activity的resume生命周期中初始化的，调用了ViewRootImpl.setView函数，下面让我们看看这个函数做了什么。
publicvoidsetView(Viewview,WindowManager.LayoutParamsattrs,ViewpanelParentView){
synchronized(this){
if(mView==null){
mView=view;
..........
if((mWindowAttributes.inputFeatures
&WindowManager.LayoutParams.INPUT_FEATURE_NO_INPUT_CHANNEL)==0){
mInputChannel=newInputChannel();
}
try{
mOrigWindowType=mWindowAttributes.type;
mAttachInfo.mRecomputeGlobalAttributes=true;
collectViewAttributes();
//Attentionhere!!!
res=mWindowSession.addToDisplay(mWindow,mSeq,mWindowAttributes,
getHostVisibility(),mDisplay.getDisplayId(),
mAttachInfo.mContentInsets,mAttachInfo.mStableInsets,
mAttachInfo.mOutsets,mInputChannel);
}catch(RemoteExceptione){
mAdded=false;
mView=null;
mAttachInfo.mRootView=null;
mInputChannel=null;
mFallbackEventHandler.setView(null);
unscheduleTraversals();
setAccessibilityFocus(null,null);
thrownewRuntimeException("Addingwindowfailed",e);
}finally{
if(restore){
attrs.restore();
}
}
............
if(mInputChannel!=null){
if(mInputQueueCallback!=null){
mInputQueue=newInputQueue();
mInputQueueCallback.onInputQueueCreated(mInputQueue);
}
mInputEventReceiver=newWindowInputEventReceiver(mInputChannel,
Looper.myLooper());
}
}
}
}
这个方法非常的长，我先截取了一小段，看我标注的[Attentionhere]，创建了一个InputChannel的实例，并且通过mWindowSession.addToDisplay方法将其添加到了mWindowSession中。
finalIWindowSessionmWindowSession;
publicViewRootImpl(Contextcontext,Displaydisplay){
mContext=context;
mWindowSession=WindowManagerGlobal.getWindowSession();
......
}
publicstaticIWindowSessiongetWindowSession(){
synchronized(WindowManagerGlobal.class){
if(sWindowSession==null){
try{
InputMethodManagerimm=InputMethodManager.getInstance();
IWindowManagerwindowManager=getWindowManagerService();
sWindowSession=windowManager.openSession(
newIWindowSessionCallback.Stub(){
@Override
publicvoidonAnimatorScaleChanged(floatscale){
ValueAnimator.setDurationScale(scale);
}
},
imm.getClient(),imm.getInputContext());
}catch(RemoteExceptione){
Log.e(TAG,"Failedtoopenwindowsession",e);
}
}
returnsWindowSession;
}
}
mWindowSession是什么呢？通过上面的代码我们可以知道，mWindowSession就是WindowManagerService中的一个内部实例。getWindowManagerService拿到的事WindowManagerNative的proxy对象，所以由此我们可以知道，mWindowSession也是用来IPC的。
如果大家对上面一段话不是很了解，换句话说不了解Android的Binder机制的话，可以先去自行了结一下。
回到上面的setView函数，mWindowSession.addToDisplay方法肯定调用的是对应remote的addToDisplay方法，其中会调用WindowManagerService::addWindow方法去将InputChannel注册到WMS中。
看到这里大家可能会有疑问，第一小节说的是InputManagerService管理设备的事件，怎么到了这一小节就变成了和WindowManagerService打交道呢？秘密其实就在mWindowSession.addToDisplay方法中。
WindowManagerService
publicintaddWindow(Sessionsession,IWindowclient,intseq,
WindowManager.LayoutParamsattrs,intviewVisibility,intdisplayId,
RectoutContentInsets,RectoutStableInsets,RectoutOutsets,
InputChanneloutInputChannel){
..........
if(outInputChannel!=null&&(attrs.inputFeatures
&WindowManager.LayoutParams.INPUT_FEATURE_NO_INPUT_CHANNEL)==0){
Stringname=win.makeInputChannelName();
InputChannel[]inputChannels=InputChannel.openInputChannelPair(name);
win.setInputChannel(inputChannels[0]);
inputChannels[1].transferTo(outInputChannel);
mInputManager.registerInputChannel(win.mInputChannel,win.mInputWindowHandle);
}
...........
}
可以看到在addWindow方法中，创建了一个InputChannel的数组，数组中有两个InputChannel，第一个是remote端的，通过mInputManager.registerInputChannel方法讲其注册到InputManager中；第二个是native端的，通过inputChannels[1].transferTo(outInputChannel)方法，将其指向outInputChannel，而outInputChannel就是前面setView传过来的那个InputChannel，也就是ViewRootImpl里的。
通过这一段代码，我们知道，当Activity初始化的时候，我们就会在WMS中注册两个InputChannel，remote端的InputChannel注册到InputManager中，用于接受ReaderThread和DispatcherThread传递过来的信息，native端的InputChannel指向ViewRootImpl中的InputChannel，用于接受remote端的InputChannel传递过来的信息。
最后，回到ViewRootImpl的setView方法的最后，有这么一句：
mInputEventReceiver=newWindowInputEventReceiver(mInputChannel, Looper.myLooper());
WindowInputEventReceiver，就是我们最终接受事件的接收器了。
键盘事件的传递
下面让我们看看WindowInputEventReceiver做了什么。
finalclassWindowInputEventReceiverextendsInputEventReceiver{
publicWindowInputEventReceiver(InputChannelinputChannel,Looperlooper){
super(inputChannel,looper);
}
@Override
publicvoidonInputEvent(InputEventevent){
enqueueInputEvent(event,this,0,true);
}
@Override
publicvoidonBatchedInputEventPending(){
if(mUnbufferedInputDispatch){
super.onBatchedInputEventPending();
}else{
scheduleConsumeBatchedInput();
}
}
@Override
publicvoiddispose(){
unscheduleConsumeBatchedInput();
super.dispose();
}
}
很简单，回调到onInputEvent函数的时候，就调用ViewRootImpl的enqueueInputEvent函数。
voidenqueueInputEvent(InputEventevent,
InputEventReceiverreceiver,intflags,booleanprocessImmediately){
.........
if(processImmediately){
doProcessInputEvents();
}else{
scheduleProcessInputEvents();
}
}
可以看到，如果需要立即处理该事件，就直接调用doProcessInputEvents函数，否则调用scheduleProcessInputEvents函数加入调度。
这里我们一切从简，直接看doProcessInputEvents函数。
voiddoProcessInputEvents(){
........
deliverInputEvent(q);
........
}
privatevoiddeliverInputEvent(QueuedInputEventq){
Trace.asyncTraceBegin(Trace.TRACE_TAG_VIEW,"deliverInputEvent",
q.mEvent.getSequenceNumber());
if(mInputEventConsistencyVerifier!=null){
mInputEventConsistencyVerifier.onInputEvent(q.mEvent,0);
}
InputStagestage;
if(q.shouldSendToSynthesizer()){
stage=mSyntheticInputStage;
}else{
stage=q.shouldSkipIme()?mFirstPostImeInputStage:mFirstInputStage;
}
if(stage!=null){
stage.deliver(q);
}else{
finishInputEvent(q);
}
}
可以看到deliverInputEvent函数中，存在一个很有意思的东西叫InputStage，通过一些标记位去确定到底是用哪个InputStage去处理。
这些InputStage是在哪里初始化的呢？显示是在setView函数啦。
mSyntheticInputStage=newSyntheticInputStage(); InputStageviewPostImeStage=newViewPostImeInputStage(mSyntheticInputStage); InputStagenativePostImeStage=newNativePostImeInputStage(viewPostImeStage, "aq:native-post-ime:"+counterSuffix); InputStageearlyPostImeStage=newEarlyPostImeInputStage(nativePostImeStage); InputStageimeStage=newImeInputStage(earlyPostImeStage, "aq:ime:"+counterSuffix); InputStageviewPreImeStage=newViewPreImeInputStage(imeStage); InputStagenativePreImeStage=newNativePreImeInputStage(viewPreImeStage, "aq:native-pre-ime:"+counterSuffix); mFirstInputStage=nativePreImeStage; mFirstPostImeInputStage=earlyPostImeStage;
可以看到初始化了如此多的InputStage。这些stage的调用顺序是严格控制的，Ime的意思是输入法，所以大家应该了解这些preIme和postIme是什么意思了吧？
从上面得知，最终会调用InputStage的deliver函数：
publicfinalvoiddeliver(QueuedInputEventq){
if((q.mFlags&QueuedInputEvent.FLAG_FINISHED)!=0){
forward(q);
}elseif(shouldDropInputEvent(q)){
finish(q,false);
}else{
apply(q,onProcess(q));
}
}
其apply方法被各个子类重写的，下面我们以ViewPreImeInputStage为例：
@Override
protectedintonProcess(QueuedInputEventq){
if(q.mEventinstanceofKeyEvent){
returnprocessKeyEvent(q);
}
returnFORWARD;
}
privateintprocessKeyEvent(QueuedInputEventq){
finalKeyEventevent=(KeyEvent)q.mEvent;
if(mView.dispatchKeyEventPreIme(event)){
returnFINISH_HANDLED;
}
returnFORWARD;
}
可以看到，会调用View的dispatchKeyEventPreIme方法。看到这里，文章最开头的那个问题也就迎刃而解了，为什么在输入法弹出的情况下，监听Activity的onKeyDown没有用呢？因为该事件被输入法消耗了，对应的，就是说走到了imeStage这个InputStage中；那为什么重写View的dispatchKeyEventPreIme方法就可以呢？因为它是在ViewPreImeInputStage中被调用的，还没有轮到imeStage呢～
总结
通过这样的一篇分析，相信大家对Android中的事件分发已经有了一定的了解，希望本文的内容对大家的学习或者工作能带来一定的帮助，谢谢大家对毛票票的支持。