本篇内容主要讲解“Andriod事件分发事件怎么来的”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Andriod事件分发事件怎么来的”吧!事件分发一直以来都是一个android知识的重点。从应用开发角度和用户的交互就是在处理事件。事件分发一般情况都会讲view的分发过程，他的过程缩略起来就可以这样表示。这里就有一个问题，最早的事件是从哪里来的。根据Android的视图模型知道最外层的view就是DecorView ,而它的外面是一个PhoneWindow。所以最初的事件就是从PhoneWindow进入了view的事件分发，而PhoneWindow的事件又是Activity中来的.那么问题又来了，activity的事件是哪里来的呢。熟悉Android的Window创建流程的话就知道ViewRootImpl是所有view的最顶层。也是ViewRootImpl在setView中实现了View和WindowManager之间的交互。这个方法里有一个在Window创建流程的时候没有关注的InputChannel，事件真正的来源就是它，在从名字也能猜出mInputEventReceiver就是接收事件的对象了，这是一个ViewRootImpl的内部类看下它的实现。如果processedEvents不为空都是调用了enqueueInputEvent，不然就直接调用finishInputEvent。这里判断了是否要立即消费，如果立即消费doProcessInputEvents，不然调用scheduleProcessInputEvents。而scheduleProcessInputEvents很简单就是handle发送了一个异步消息。最后handle执行的时候还是会调用到doProcessInputEvents。所以就来详细看下doProcessInputEvents。可以看到真实的处理都是deliverInputEvent来处理。在deliverInputEvent中出现了stage，这就是在setView初始化的那些处理器，处理通过stage.deliver(q)来实现。 InputStage 还是ViewRootImpl的一个内部类。熟悉okhttp的话很容易就发现这里也是一个责任链模式。从setView中 InputStage 子类的初始化也能看到，其中和view相关的是ViewPostImeInputStage。ViewRootImpl的事件就交给mView来继续分发了，这里mView是DecorView，也是在setView中传进来的。这里通过dispatchTouchEvent将事件交给了Window.Callback，而这里的Window.Callback就是Activity，兜兜转转终于回到了Activity的dispatchTouch免费云主机域名Event中。通过这个流程可以知道，事件的流程是WMS->ViewRootImpl->DecorView->Activity->PhoneWindow->DecorView，这里有一个疑问就是为什么不直接从DecorView开始分发。我猜测是为了方便在应用层重写Activity中的onTouch来消费没有view处理的事件。到此，相信大家对“Andriod事件分发事件怎么来的”有了更深的了解，不妨来实际操作一番吧！这里是百云主机网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
相关推荐: vue中的vue-router query方式和params方式实例分析
今天小编给大家分享一下vue中的vue-routerquery方式和params方式实例分析的相关知识点，内容详细，逻辑清晰，相信大部分人都还太了解这方面的知识，所以分享这篇文章给大家参考一下，希望大家阅读完这篇文章后有所收获，下面我们一起来了解一下吧。一种是…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
