专栏首页码上积木拇指记者打探事件分发机制背后的秘密(上)

拇指记者打探事件分发机制背后的秘密(上)

前言

聊到事件分发,很多朋友就会想到view的dispatchTouchEvent,其实在此之前,Android还做了很多工作。

比如跨进程获取输入事件的方式?在dispatchTouchEvent责任链之前还有一条InputStage责任链?DecorView,PhoneWindow之间的传递顺序?

包括事件分发过程中事件序列的处理方式?ViewGroup和View之间的协调?等等。

这一切,都要从你可爱的小拇指说起...

当你的拇指触碰手机的那一刹那,手机就被你深深的影响了,没错,手机会收到你给他布置的任务。

这个任务可以是:

  • 滑动界面任务
  • 点击按钮任务
  • 长按任务

等等,总之,你向手机传递了这个任务信息,接下来就是手机的处理任务时间。

我们可以假设手机系统就是一个大的公司(Android公司),而我们触摸手机的任务就是一个完整的项目需求,今天就和大家一起深入Android公司内部,打探事件分发的那些私密。

在此之前,我也列出了问题和大纲:

硬件部门和内核部门

首先,我的拇指找到了Android公司,说出了自己的需求,比如:点击某个View并滑动到另外的位置。

Android公司首先会派出硬件部门,和我的小拇指进行会谈,接收到我的需求之后,硬件部门生成简单的终端,并传递给内核部门。

内核部门将任务进行加工,生成了内部事件——event,并添加到公司内部的一个管理系统/dev/input/目录下。

这样做的目的是把外来的需求转化成内部通用,都能看懂的任务。

任务处理部门(SystemServer进程)

当任务记录在公司管理系统上后,就会有专门的任务处理部门对这些任务进行处理,他们做的事情就是一直监听/dev/input/目录,当发现有新的事件就会进行处理。

那这个任务处理部门到底是何方神圣呢?

不知道大家还记不记得在SystemServer进程中启动了一系列系统有关的服务,比如AMS,PMS等等,其中还有一个不是很起眼的角色,叫做InputManagerService

这个服务就是用来负责与硬件通信,接受屏幕输入事件。

在其内部,会启动一个读线程,也就是InputReader,它会从这个管理系统也就是/dev/input/目录拿到任务,并且分发给InputDispatcher线程,然后进行统一的事件分发调度。

分配给具体的项目组(InputChannel)

然后任务处理部门需要把任务交给 专业处理任务的项目组了,这就涉及到跨部门沟通了(跨进程通信)。

大家都知道跨部门沟通是个比较麻烦的事情,谁来完成这个事情呢?InputChannel

让我们回到ViewRootImplsetView方法:

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
    synchronized (this) {
      //创建InputChannel
      mInputChannel = new InputChannel();
      //通过Binder进入systemserver进程
      res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
                  getHostVisibility(), mDisplay.getDisplayId(),
                  mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
                  mAttachInfo.mOutsets, mInputChannel);
    }
}

在该方法中,创建了一个InputChannel对象,并且通过Binder进入systemserver进程,最终形成socket的客户端。

这里涉及到socket通信的知识,比较重要的就是c层的socketpair方法。

socketpair()函数用于创建一对无名的、相互连接的套接子。如果函数成功,则返回0,创建好的套接字分别是sv[0]和sv[1];这对套接字可以用于全双工通信,每一个套接字既可以读也可以写。

通过这个方法,就生成了socket通信的客户端和服务端:

  • socket服务端保存到system_server中的WindowState的mInputChannel;
  • socket客户端通过binder传回到远程进程的UI主线程ViewRootImpl的mInputChannel;

感兴趣的可以看看gityuan对于input分析的博客,文末有链接。

所以小结一下就是,在App进程创建了一个对象InputChannel,通过Binder机制传入了SystemServer进程,也就是WindowManagerService中。然后在WindowManagerService中创建了一对套接字用于进程间通信,而传过来的InputChannel就指向了socket的客户端。

然后App进程的主线程就会监听这个socket客户端,当收到消息(输出事件)后,回调NativeInputEventReceiver.handleEvent()方法,最终会走到InputEventReceiver.dispachInputEvent方法。

dispachInputEvent,处理输入事件,感觉离我们熟知的事件分发比较近了。

没错,到此,任务已经分配到了具体的项目组,也就是我们所使用的具体APP中了。

小组中任务第一次分发(InputStage)

当任务到达了项目组,首先组内会对这个任务进行分发,这里会涉及到第一次责任链分发模式

为什么强调是第一次呢?因为还没有到达我们熟知的view事件分发阶段,在此之前,还会有一次事件分类的责任链分发工作,也就是InputStage处理事件分发。

//InputEventReceiver.java
private void dispatchInputEvent(int seq, InputEvent event) {
    mSeqMap.put(event.getSequenceNumber(), seq);
    onInputEvent(event); 
}

//ViewRootImpl.java ::WindowInputEventReceiver
final class WindowInputEventReceiver extends InputEventReceiver {
    public void onInputEvent(InputEvent event) {
       enqueueInputEvent(event, this, 0, true); 
    }
}

//ViewRootImpl.java
void enqueueInputEvent(InputEvent event,
        InputEventReceiver receiver, int flags, boolean processImmediately) {
    adjustInputEventForCompatibility(event);
    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();
    }
}

兜兜转转,没想到还是到了ViewRootImpl这里,所以ViewRootImpl不仅负责了界面的绘制,也负责了事件分发的部分处理工作。

这里的enqueueInputEvent方法中,有涉及到一个QueuedInputEvent类,这个类就是一个封装了InputEvent的事件类,然后经过赋值调用到doProcessInputEvents方法:

   void doProcessInputEvents() {
        // Deliver all pending input events in the queue.
        while (mPendingInputEventHead != null) {
            QueuedInputEvent q = mPendingInputEventHead;
            mPendingInputEventHead = q.mNext;
            deliverInputEvent(q);
        }
    }

    private void deliverInputEvent(QueuedInputEvent q) {
        InputStage stage;
        if (stage != null) {
            stage.deliver(q);
        } else {
            finishInputEvent(q);
        }
    }

    abstract class InputStage {
        private final InputStage mNext;

        public InputStage(InputStage next) {
            mNext = next;
        }

        public final void deliver(QueuedInputEvent q) {
            apply(q, onProcess(q));
        }

到这里逻辑好像慢慢清晰了,QueuedInputEvent是一种输入事件,InputStage是处理输入事件的责任链,next字段则表示责任链的下一个InputStage

InputStage到底干了哪些事情呢?返回到ViewRootImpl的setView方法再看看:

    public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
        synchronized (this) {
        // Set up the input pipeline.
        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;
         }
    }

可以看到在setView方法中,就把这条输入事件处理的责任链拼接完成了,不同的InputStage子类,通过构造方法一个个串联起来了,那这些InputStage到底干了啥呢?

  • SyntheticInputStage。综合处理事件阶段,比如处理导航面板、操作杆等事件。
  • ViewPostImeInputStage。视图输入处理阶段,比如按键、手指触摸等运动事件,我们熟知的view事件分发就发生在这个阶段。
  • NativePostImeInputStage。本地方法处理阶段,主要构建了可延迟的队列。
  • EarlyPostImeInputStage。输入法早期处理阶段。
  • ImeInputStage。输入法事件处理阶段,处理输入法字符。
  • ViewPreImeInputStage。视图预处理输入法事件阶段,调用视图view的dispatchKeyEventPreIme方法。
  • NativePreImeInputStage。本地方法预处理输入法事件阶段。

小结一下,事件到达应用端的主线程,会通过ViewRootImpl进行一系列InputStage来处理事件。这个阶段其实是对事件进行一些简单的分类处理,比如视图输入事件,输入法事件,导航面板事件等等。

事件分发完成后,会告知SystemServer进程的InputDispatcher线程,最终将该事件移除,完成此次事件的分发消费。

我们的view手指触摸事件就是发生在ViewPostImeInputStage阶段了,具体来看看:

    final class ViewPostImeInputStage extends InputStage {
        @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);
                } 
            }
        }
    
    private int processPointerEvent(QueuedInputEvent q) {
            final MotionEvent event = (MotionEvent)q.mEvent;
            boolean handled = mView.dispatchPointerEvent(event)
            return handled ? FINISH_HANDLED : FORWARD;
        }

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

经过一系列分发,最终会执行到mView的dispatchTouchEvent方法,而这个mView就是DecorView,同样是在setView中进行赋值的,就不细说了。

至此,终于到了我们熟悉的环节,dispatchTouchEvent方法。

大佬之间的任务整理(DecorView)

确定了任务的分类,接下来就开始组内任务讨论整理了,这个阶段发生在几个大佬之间的谈话,这几个大佬分别是DecorView、PhoneWindow、Activity/Dialog

//DecorView.java
    @Override
    public boolean dispatchTouchEvent(MotionEvent ev) {
        //cb其实就是对应的Activity/Dialog
        final Window.Callback cb = mWindow.getCallback();
        return cb != null && !mWindow.isDestroyed() && mFeatureId < 0
                ? cb.dispatchTouchEvent(ev) : super.dispatchTouchEvent(ev);
    }


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

//PhoneWindow.java
    @Override
    public boolean superDispatchTouchEvent(MotionEvent event) {
        return mDecor.superDispatchTouchEvent(event);
    }

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

可以看到,从DecorView开始,事件依次经过了Activity、PhoneWindow、DecorView

有点奇怪哈,为啥是这样一个顺序呢?而不是直接ViewRootImpl交给Activity,再交给顶层View——DecorView?而是转来转去,缘起和从呢?

  • 首先,为什么ViewRootImpl不直接把事件交给Activity?

因为界面上不止Activity一种形态呀,如果界面上存在Dialog,而Dialog的Window属于子Window,是可以覆盖应用级Window的,所以总不能把事件直接交给Activity吧?都被覆盖了,所以这时候应该把事件交给Dialog。

为了方便,我们用到了DecorView这个角色来充当分发的第一元素,由他来找到当前界面window的所持着,所以代码中也是找到mWindow.getCallback(),其实也就是对应的Activity或者Dialog。

  • 其次,交给Acitivity后,为什么不直接交给顶层View——DecorView开始分发事件呢?

因为ActivityDecorView之间并没有直接关系。DecorView怎么来的?通过setContentView被创建出来的,所以在Activity中是看不到DecorView身影的,DecorView的实例保存在PhoneWindow中,由Window所管理。

所以Activity的事件肯定是交给Window来管理,之前也说过PhoneWindow的指责就是帮助Activity管理View,所以事件分发交给它也是它的职责所在。而PhoneWindow的处理方式,就是交给顶层的DecorView来处理了。

这样,一个事件分发的链条就形成了:

DecorView——>Activity——>PhoneWindow——>DecorView——>ViewGroup

接下来就是View层级之间的事件分发,内容有点多,没赶完,所以下期见了。

总结

拇指记者的探访还在继续...

参考

https://wanandroid.com/wenda/show/12119 http://gityuan.com/2016/12/31/input-ipc/ https://juejin.cn/post/6844903926446161927 https://www.jianshu.com/p/b7f33f46d33c

感谢大家的阅读,有一起学习的小伙伴可以关注下公众号—码上积木❤️ 每日一个知识点,建立完整体系架构。

本文分享自微信公众号 - 码上积木(Lzjimu),作者:积木zz

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-04-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 拇指记者打探事件分发机制背后的秘密(下)

    上一期跟随拇指记者,发现了Android公司在指派具体的人之前的种种机制,今天就继续探索,看看任务具体的处理消费逻辑。

    码上积木
  • QQ的成功,远没有你想象的那么顺利和轻松

    如果QQ是一个人,看似风光,其实从出生到成长,过程饱经错荡,堪算坎坷。它的人生历程确实也够励志的了。

    JackJiang
  • QQ的成功,远没有你想象的那么顺利和轻松

    如果QQ是一个人,看似风光,其实从出生到成长,过程饱经错荡,堪算坎坷。它的人生历程确实也够励志的了。

    JackJiang
  • 大屏时代的生态变迁,看平板手机的拇指热键与界面布局

    iPhone出现之后的几年,手机屏幕的尺寸基本都保持在4英寸以下(以对角线计算),非常便于单手操作。然而,随着大屏手机不断涌入市场,到2014年年中,已经有将近...

    博文视点Broadview
  • 脑机头条 第38期| 能玩"剪刀石头布"的脑机!密歇根大学开发由大脑意识精密控制的假肢

    几日前,美国密歇根大学的研究人员在《科学》子刊《科学转化医学》发表了脑控假肢领域一篇重磅文章。文章介绍了研究人员通过一种新的神经接口技术,开发出一款由意识精密控...

    脑机接口社区
  • 想搭上“人工智能”顺风车,李彦宏的未来医疗还需完善这几个方面

    镁客网
  • 这些网站,99%人用过都说是神器,还不收藏!

    —— 由谷歌开发的一个基于AI分析并猜出你要画什么的平台,是原先“你画我猜”的升级版,让你从现有图库里找出最符合脑中形象的图案。

    黑泽君
  • “携程泄密”原因技术拆解

    叶亚明万万没有想到,他在携程网大干快上的技术改造升级给其OpenStack团队造成巨大压力。这位携程网新任技术副总裁自上任始,便对整个技术构架进行大刀阔斧的...

    静一
  • 能玩“剪刀石头布”!密歇根大学开发科幻假肢,可由大脑意识精密控制

    3 月 5 日,《科学》子刊《科学转化医学》发表了脑控假肢领域一篇重磅文章,来自美国密歇根大学的研究人员通过一种新的神经接口技术,开发出一款由意识精密控制的假肢...

    大数据文摘
  • 密码发展史之古典密码

    密码(Cryptology)是一种用来混淆的技术,它希望将正常的、可识别的信息转变为无法识别的信息。密码学是一个即古老又新兴的学科,密码学一词源自希腊文“kry...

    安智客
  • 每天220亿人使用的一个小功能,Facebook点赞按钮的设计门道

    一年前,Facebook点赞按钮发布更新。一年后的今天,Facebook小小的点赞按钮因为Ted刚发布的一段演讲掀起波澜。设计一个像FB点赞按钮那么小的东西很难...

    BestSDK
  • 秘密共享—隐私计算和区块链共识中的榫卯

    2018年5月正式生效的GDPR是欧盟“史上最严”条例,是数十年来数据安全和数据隐私法规方面最重要的一次变化。随后,2019年生效的加州CCPA,对个人数据及信...

    绿盟科技研究通讯
  • Unity3D游戏开发初探—2.初步了解3D模型基础

      简而言之,3D模型就是三维的、立体的模型,D是英文Dimensions的缩写。

    Edison Zhou
  • 慢工出细活,Facebook点赞按钮设计中的门道

    一年前,Facebook点赞按钮发布更新。一年后的今天,Facebook小小的点赞按钮因为Ted刚发布的一段演讲掀起波澜。设计一个像FB点赞按钮那么小的东西很...

    奔跑的小鹿
  • 4G催生下的移动视频行业新“热点”

    每一波技术浪潮到来,洗牌、颠覆、破局都会上演。4G就是这样的技术浪潮。大流量应用将爆发,视频App首当其冲。对视频App来说,4G是机遇,也是挑战。搜狐...

    罗超频道
  • EKT多链技术谈 | 数学:区块链里的精密元件

    前言:数学在人类文明的发展中起着非常重要的作用。牛顿当年通过数学计算预见了发射人造天体的可能性;爱因斯坦相对论的质能公式从数学论证的角度预示了原子能时代的来临;...

    风中凌乱的靓仔
  • 维基解密再爆猛料:CIA利用漏洞入侵全球数十亿个人电子设备

    大数据文摘
  • 机器人如何才能更像人?关键在于它

    据Futurism报道,对于人类来说,特别是从事制造业工作的人,打个结、剥离电缆线外皮、将销子插入孔中或使用钻头工具等行为都很常见。它们看起来似乎都很简单,但同...

    机器人网
  • 下暴雨出不了门?这有27部优秀的黑客纪录片

    大数据文摘

扫码关注云+社区

领取腾讯云代金券