事件分发，真的一定从Activity开始吗？
前言很高兴遇见你~
事件分发，android中一个老生常谈的话题了。基本的流程我们也都知道是从Activity开始分发，但有一个关键问题是：事件是如何到达Activity的 ？
你以为我接下来要开始讲源码、系统底层了？不不不，本文不讲这些，而是着重于android框架层对于触摸机制的设计，更好地理解整一个android在框架层的事件分发，理解整体的流程是怎么回事。
android的view管理是以window为单位的，每个window对应一个view树。Window机制不仅管理着view的显示，也负责view的事件分发。关于window的本质，可以阅读笔者的另一篇文章window机制。研究事件分发的来源，需要从window机制入手。
本文是笔者android触摸事件系列文章的开篇，主要的内容是分析Android Framework层是如何处理触摸事件。不会纠结于源码与底层，而是把触摸事件来源的大体流程呈现出来，便于对事件分发体系有个更加完整的理解。
管理单位：window首先了解一个概念：view树。
我们的应用布局，一般是有多层viewGroup和view的嵌套，如下图：
而他们对应的结构关系如下图所示
此时，我们就可以称该布局是以一个LinearLayout为根的一棵view树。LinearLayout可以直接访问FrameLayout和RelativeLayout，因为他们都是LinearLayout的子view，同样的RelativeLayout可以直接访问Button。
每一棵view树都有一个根，叫做ViewRootImpl ，他负责管理这整一棵view树的绘制、事件分发等。所以可以说，事件分发是从viewRootImpl开始的。
我们的应用界面一般会有多个view树，我们的activity布局就是一个view树、其他应用的悬浮窗也是一个view树、dialog界面也是一个view树、我们使用windowManager添加的view也是一个view树等等。最简单的view树可以只有一个view。
android中view的绘制和事件分发，都是以view树为单位。每一棵view树，则为一个window 。系统服务WindowManagerService，管理界面的显示就是以window为单位，也可以说是以view树为单位。而view树是由viewRootImpl来负责管理的，所以可以说，wms（WindowManagerService的简写）管理的是viewRootImpl。如下图：
对上图做个简单解释。
wms是运行在系统服务进程的，负责管理所有应用的window。应用程序与wms的通信必须通过Binder进行跨进程通信。
每个viewRootImpl在wms中都有一个windowState对应，wms可以通过windowState找到对应的viewRootImpl进行管理。
了解window机制，跟事件分发有什么关系呢？我们要知道，window机制管理的，不仅是view的显示逻辑，事件分发也是其中的一个重要部分。了解window机制的一个重要原因是：事件分发并不是由Activity驱动的，而是由系统服务驱动viewRootImpl来进行分发 ，甚至可以说，在框架层角度，和Activity没有任何关系。这将有助于我们对事件分发的本质理解。
那么触摸信息是如何一步步到达viewRootImpl、viewRootImpl如何对触摸信息进行分发处理的呢，这是我们接下来要讨论的。
触摸信息是如何到达viewRootImpl的？我们都知道的是，在我们手指触摸屏幕时，即产生了触摸信息。这个触摸信息由屏幕这个硬件产生，被系统底层驱动获取，交给Android的输入系统服务：InputManagerService，也就是IMS。
IMS会对这个触摸信息进行处理，通过WMS找到要分发的window，随后发送给对应的viewRootImpl。所以发送触摸信息的并不是WMS，WMS提供的是window的相关信息。
这一部分涉及到系统底层的逻辑，不是本文的重点，感兴趣的读者推荐阅读gityuan博主的文章Input系统-事件处理全过程。这里不展开讲解。大体的过程如下图：
当viewRootImpl接收到触摸信息时，也正是应用程序进程事件分发的开始。
viewRootImpl是如何分发事件的？前面我们讲到，viewRootImpl管理一棵view树，view树的最外层是viewGroup, 而viewGroup继承于view。因此整一棵view树，从外部可以看做一个view。viewRootImpl接收到触摸信息之后，经过处理之后，封装成MotionEvent对象发送给他所管理的view，由view自己进行分发。