Android事件分发机制(1)

2401_84122782

已于 2024-04-29 11:03:10 修改

阅读量269

点赞数 5

分类专栏：程序员文章标签： android

于 2024-04-29 11:03:08 首次发布

本文链接：https://blog.csdn.net/2401_84122782/article/details/138305764

版权

程序员专栏收录该内容

473 篇文章 1 订阅

订阅专栏

<ViewStub android:id=“@+id/action_mode_bar_stub”

android:inflatedId=“@+id/action_mode_bar”

android:layout=“@layout/action_mode_bar”

android:layout_width=“match_parent”

android:layout_height=“wrap_content”

android:theme=“?attr/actionBarTheme” />

<FrameLayout

android:id=“@android:id/content”

android:layout_width=“match_parent”

android:layout_height=“match_parent”

android:foregroundInsidePadding=“false”

android:foregroundGravity=“fill_horizontal|top”

android:foreground=“?android:attr/windowContentOverlay” />

从布局中可以看到，contentParent是个id为content的FrameLayout。

到这里我们就可以得到结论：我们在Activity 中onCreate()方法里常写的setContentView(layoutResID)最终会填充到FrameLayout的布局中去。而这个FrameLayout是放在一个竖直方向的LinearLayout里面。

那这整个以LinearLayout为最外层的layout要放在哪里呢？

//将layoutResource加载到DecorView去

mDecor.onResourcesLoaded(mLayoutInflater, layoutResource);

public class DecorView extends FrameLayout

void onResourcesLoaded(LayoutInflater inflater, int layoutResource) {

…

final View root = inflater.inflate(layoutResource, null);

addView(root, 0, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));

…

}

从这段代码可以看出，contentParent最终会通过addView方法填充到DecorView中去。

到这里可以小结一下：在Activity里设置的布局会添加到名为contentParent的view上，而contentParent会添加到DecorView中，而DecorView是PhoneWindow下的View，所以它也顺理成章成为了整个View树的顶级View。从这里也可以得出一个结论：Activity它并负责视图控制，真正控制试图的是PhoneWindow。

可以思考一个问题：这样看没有Activity的存在也是可以的，那Activity被设计的目的是什么呢？

为了可以更直观的展示上面的结论，上图：

提这个前置知识最重要有两个目的：

对整个View树的构建过程有个了解
View树的顶级View是DecorView

知道这两点后可以帮助我们更容易的理解后面的核心内容。

事件分发整体的设计

事件分发的源头往往是我们触摸屏幕（包含手指、笔、鼠标等），它最开始是一个物理层面的触摸输入事件，然后通过一系列转换过程到我们应用上层。作为应用层开发者，更直接关注到的肯定还是应用层面的代码。

那假设这个触摸输入事件已经到我们的应用层了，那我们从应用层角度来设计的话，会如何设计？

我们是否只要定义这样一个类MotionInputEvent去接收事件并处理就可以了？看命名还挺贴切的。其实仔细想想，除了触摸输入事件外，常用的还有键盘输入，所以只定义这样一个类从设计上是不合理的，没有考虑到它的可扩展性。

因此定义一个输入事件抽象层InputEvent，让触摸输入事件MotionEvent、键盘输入KeyEvent都继承该抽象类，这才是一个合理的设计。看看源码确实是这么设计的：

#package android.view;

public abstract class InputEvent implements Parcelable{}

public final class MotionEvent extends InputEvent implements Parcelable {}

public class KeyEvent extends InputEvent implements Parcelable {}

既然有了这两种输入事件类型，肯定还需要一个地方管理它们：在接收到输入事件的时候进行管理，然后再分发给具体的输入事件类来处理。这个类就是系统输入管理器InputManager。InputManager作为管理分发InputEvent的地方，那它是在哪里被创建出来的呢？

我们知道手机启动后，手机就要响应我们的输入事件，所以可以猜测出在系统启动时，和它相关的某个类应该就要创建出来。查看frameworks层的SystemServer类，找到那个最直接相关的类，发现是 InputManagerService ，看着是不是有点熟悉。看它长得就像我们熟知的 ActivityManagerService、WindowManagerService一样，所以它在SystemServer启动时应该就会被创建出来。

#frameworks/base/services/java/com/android/server/SystemServer.java

public final class SystemServer {

private void run() {

startOtherServices()

}

private void startOtherServices() {

…

InputManagerService inputManager = null

inputManager = new InputManagerService(context);

//这里可以看出，InputManagerService和WindowManagerService有紧密的联系，InputManagerService的实例直接传给了WindowManagerService的main方法

wm = WindowManagerService.main(context, inputManager, !mFirstBoot, mOnlyCore,

new PhoneWindowManager(), mActivityManagerService.mActivityTaskManager);

inputManager.start();

…

}

#frameworks/base/services/core/java/com/android/server/input/InputManagerService.java

public class InputManagerService extends IInputManager.Stub

implements Watchdog.Monitor {

public InputManagerService(Context context) {

mPtr = nativeInit(this, mContext, mHandler.getLooper().getQueue());

}

//调用native方法初始化InputManagerService

private static native long nativeInit(InputManagerService service,

Context context, MessageQueue messageQueue);

}

有意思的是，从源码可以看到InputManagerService和WindowManagerService居然建立了联系，这是我们一开始没有想到的。不过细想琢磨一下，如果对WindowManagerService 熟悉的话，会发现这样的设计是理所当然的：

WindowManagerService是窗口的大主管(下面简称WMS)，它记录了当前系统中所有窗口的完整信息，所以只有它才能判断出要把输入的事件投递给具体的某个应用进程进行处理。

当然具体怎么传递的就涉及细节。不用理会它们，在考虑整体设计的时候，具体细节都可暂时跳过，不能被它们蒙蔽了双眼，阻碍了前进的脚步。这些细节点，可在事后找时间逐一击破它们。

到这里我们可以小结一下：在系统启动时，SystemServer会启动窗口管理服务WindowManagerService，WindowManagerService在启动的时候就会通过InputManagerService，启动Native层的InputManager来接收硬件层的输入事件。接收到输入事件后，WindowManagerService会经过判断把输入事件分发给某个具体的应用进程。

WMS不仅是是窗口的大主管，还是InputEvent的派发者

那么现在的问题就转变成：WMS分发输入事件InputEvent后，应用进程如何接收的了？这里的应用进程可以理解成是一个应用层级的窗口Window。因为事件输入的目的地是应用层级的窗口Window。

我们可以想到的是在WMS和应用窗口Window中间肯定需要一个纽带或者说是中介，去衔接这两者。那这个纽带是谁呢？

对View绘制比较了解的人应该很熟悉ViewRootImpl。View的测量、布局、绘制都由它控制。它作为整个View树的根部，是View树正常运作的基石。后面的分析过程也会提到这一点的。

于此同时，ViewRootImpl就是WMS和应用窗口Window建立通信的纽带。既然是纽带，那么必然有两者的依赖，所以它的创建过程就非常重要了，按理说是可以从中找到依据的。

ViewRootImpl的创建

ViewRootImpl是在哪里被创建的呢？这就要从handleResumeActivity流程看起

#ActivityThread

public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,String reason) {

r.window = r.activity.getWindow();

ViewManager wm = a.getWindowManager(); //这里的wm实例对象就是WindowManagerImpl

WindowManager.LayoutParams l = r.window.getAttributes();

wm.addView(decor, l);

}

wm.addView的wm的实例对象就是WindowManagerImpl，其中的参数decor是DecorView对象，在前置知识ViewTree的创建过程中已经提过了。

所以接着看WindowManagerImpl的addView方法做了什么？

#WindowManagerImpl

private final WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance();

@Override

public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {

applyDefaultToken(params);

mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);

}

又调用到 WindowManagerGlobal的addView方法

#WindowManagerGlobal

public void addView(View view, ViewGroup.LayoutParams params,Display display, Window parentWindow) {

ViewRootImpl root;

root = new ViewRootImpl(view.getContext(), display); //创建了ViewRootImpl对象

mViews.add(view); //记录DecorView

mRoots.add(root); //记录ViewRootImpl

Params.add(wparams); //记录WindowManager的LayoutParams

root.setView(view, wparams, panelParentView);

}

到这里可以先小结一下：在ActivityThread.handleResumeActivity()流程中，通过WindowManager（WindowManagerImpl）的 addView() 实现了ViewRootImpl的创建。此时我们应用层窗口 Window就和ViewRootImpl就建立了关联。

从代码中可以看到，除了ViewRootImpl的创建还会把构建出来的ViewRootImpl、DecorView、WindowManager.LayoutParams 记录下来，用几个数组分别存储，它们是一一对应的。

那么，现在应用层窗口 Window就和ViewRootImpl就建立了关联，还剩一个问题是 WMS 和 ViewRootImpl怎么建立关联的呢？

继续往下看源码，进入ViewRootImpl 的 setView 方法，我们就能找到答案了。看看它做了什么？

#ViewRootImpl

final IWindowSession mWindowSession

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {

…

// 控制测量（measure）、布局(layout)、绘制（draw）的开始

requestLayout();

//包括了发送和接收消息的功能封装

mInputChannel = new InputChannel();

//通过Binder调用，进入系统进程的Session，调用WMS的addWindow方法

res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,

getHostVisibility(), mDisplay.getDisplayId(), mTmpFrame,

mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,

mAttachInfo.mOutsets, mAttachInfo.mDisplayCutout, mInputChannel,

mTempInsets);

//创建事件输入处理接收者

mInputEventReceiver = new WindowInputEventReceiver(mInputChannel,

Looper.myLooper());

…

}

mWindowSession.addToDisplay()函数是添加窗口流程，对应的服务端就是WMS，而WMS又是个系统进程，所以这是个Binder跨进程调用方法，最终调用的是WMS的addWindow方法。而参数mInputChannel，它包括了发送和接收消息的功能封装。

至此这里已经验证了我们想要的结果了，ViewRootImpl确实是应用层级Window和WMS的建立了通信的纽带。

小插入：前面提到ViewRootImpl是View绘制的根基。为什么这么说？

可以从setView的requestLayout()看出。在requestLayout()方法，它主要做了两件事情：

检查线程
开始测量（measure）、布局(layout)、绘制（draw）

#ViewRootImpl

@Override

public void requestLayout() {

if (!mHandlingLayoutInLayoutRequest) {

checkThread();

mLayoutRequested = true;

scheduleTraversals();

}

void scheduleTraversals() {

if (!mTraversalScheduled) {

mTraversalScheduled = true;

//在同步信号过来的时候， mTraversalRunnable的run函数将调用

mChoreographer.postCallback(

Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);

}

final class TraversalRunnable implements Runnable {

@Override

public void run() {

doTraversal();

}

void doTraversal() {

performTraversals();

}

private void performTraversals() {

performMeasure(childWidthMeasureSpec, childHeightMeasureSpec)

performLayout(lp, mWidth, mHeight);

performDraw();

}

应用层级的事件分发流程

现在WMS和应用层窗口了已经有了通信的条件。输入事件可以从底层硬件分发到应用层窗口了。发是发过来了，可还需要一个接收者呀。如果你细心的话，或许会在上面代码里有所发现。在setView方法的最后，创建了一个WindowInputEventReceiver对象。它的职责就是接受输入事件的。

final class WindowInputEventReceiver extends InputEventReceiver {

@Override

public void onInputEvent(InputEvent event) {

//将事件加入队列

enqueueInputEvent(event, this, 0, true);

}

void enqueueInputEvent(InputEvent event, InputEventReceiver receiver,

int flags, boolean processImmediately) {

//将事件加入到队列中

QueuedInputEvent q = obtainQueuedInputEvent(event, receiver, flags);

if (last == null) {

mPendingInputEventHead = q;

mPendingInputEventTail = q;

} else {

last.mNext = q;

mPendingInputEventTail = q;

}

事件是接收完了，那要怎么处理呢？

当事件被接收了，按正常的逻辑就应该要开始处理了，也就是说在WindowInputEventReceiver对象创建成功后，就应该要处理。所以推理在该对象成功之后就有这部分处理逻辑。再次查看setView()方法：

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {

// 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;

}

这里它使用了责任链设计模式。对于不同的输入事件需要使用相应的处理方法，而这些处理方法需要有优先级，所以通过责任链模式，把不同的处理阶段通过一条链串起来是一个很优雅的设计实现。

那这些处理阶段都是怎么处理的呢，比如我们挑一个ViewPostImeInputStage来看下：

/**

Delivers post-ime input events to the view hierarchy.

final class ViewPostImeInputStage extends InputStage {

public ViewPostImeInputStage(InputStage next) {

private int processKeyEvent(QueuedInputEvent q) {…}

private int processGenericMotionEvent(QueuedInputEvent q) {…}

private int processPointerEvent(QueuedInputEvent q) {

final MotionEvent event = (MotionEvent)q.mEvent;

尾声

你不踏出去一步，永远不知道自己潜力有多大，千万别被这个社会套在我们身上的枷锁给捆住了，30岁我不怕，35岁我一样不怕，去做自己想做的事，为自己拼一把吧！不试试怎么知道你不行呢？

改变人生，没有什么捷径可言，这条路需要自己亲自去走一走，只有深入思考，不断反思总结，保持学习的热情，一步一步构建自己完整的知识体系，才是最终的制胜之道，也是程序员应该承担的使命。

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

event = (MotionEvent)q.mEvent;

尾声

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

[外链图片转存中…(img-be8WD5Fq-1714359772255)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

2401_84122782

关注

5
点赞
踩
9

收藏

觉得还不错? 一键收藏
0
评论
Android事件分发机制(1)

从布局中可以看到，是个id为content的。到这里我们就可以得到结论：我们在Activity中onCreate()方法里常写的最终会填充到的布局中去。而这个是放在一个竖直方向的里面。那这整个以为最外层的layout要放在哪里呢？//将layoutResource加载到DecorView去从这段代码可以看出，最终会通过addView方法填充到DecorView中去。到这里可以小结一下：在Activity里设置的布局会添加到名为的view上，而会添加到DecorView中，而。
复制链接

扫一扫