Chromium网页输入事件处理机制简要介绍和学习计划

       用户在阅读网页的时候，需要与网页进行交互，经常使用的操作如滑动、捏合网页，和点击网页中的链接等。这些交互操作也称为用户输入事件，阅读器需要对它们作出迅速的响应，例如及时更新网页内容或打开新的网页等。阅读器能够对用户输入事件作出迅速的响应是相当重要的，由于这关乎到用户阅读网页时的体验，特别是在用户滑动和捏合网页时。本文接下来就扼要介绍Chromium对用户输入事件的处理机制，和制定后续的学习计划。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

       在任何1个平台上，用户输入事件都是由系统捕获和分发的，1般就是分给给当前激活的利用程序。利用程序接下来又会根据本身的UI结构找到产生输入事件的位置所对应的控件，然后将输入事件交给该控件处理。在Android平台上，用户输入事件的捕获和分发进程可以参考前面Android利用程序键盘（Keyboard）消息处理机制分析1文。

       阅读器作为1个利用程序，它的用户输入事件一样也是系统捕获后分发给它处理的。从前面Chromium多进程架构扼要介绍和学习计划这个系列的文章可以知道，基于Chromium的阅读器是多进程架构的，它主要有Browser、Render和GPU3种进程。其中，Browser进程负责创建阅读器的UI结构，Render负责加载网页内容，GPU进程负责将网页内容渲染在阅读器的UI上。这些知识点可以参考Chromium硬件加速渲染机制基础知识扼要介绍和学习计划、Chromium网页加载进程扼要介绍和学习计划和Chromium网页渲染机制扼要介绍和学习计划这3个系列的文章。

       以Chromium自带的Content Shell APK为例，它的Browser进程创建的UI结构如图1所示：

图1 Content Shell APK的UI结构

       Browser进程创建的阅读器窗口由1个ContentShellActivity描写。这个ContentShellActivity包括了1个ShellManager。这个ShellManager又包括了1个Shell。注意，这里的ShellManager和Shell都是属于1个Layout元素。 

       1个Shell由1个Toolbar和1个ContentView组成。其中，Toolbar用来输入URL，ContentView用来展现URL对应的网页的内容。ContentView内部包括了1个SurfaceView，网页的内容实际上是渲染在这个SurfaceView上的。

       用户与网页进行交互时，所产生的输入事件就会分发给ContentView处理。整体的处理进程如图2所示：

图2 用户输入事件处理进程

       ContentView运行在Browser进程中，它接收到输入事件后首先会在Browser进程进行处理，主要就是检查手势操作，例如连续的输入事件是不是产生了滑动和捏合事件。接着Browser进程再将产生的输入事件及其产生的手势操作通过1个类型为InputMsg_HandleInputEvent的IPC消息发送给Render进程处理。

       Browser进程发送给Render进程的InputMsg_HandleInputEvent消息，首先会被Compositor线程截获。Compositor线程主要是检查消息里面是不是包括了滑动和捏合手势操作。如果包括的话，那末就将它们利用在CC Active Layer Tree中。其它的输入事个将会转发给Main线程处理。Main线程主要将输入事件交给WebKit处理，也就是将它们利用在WebKit保护的DOM Tree中。关于Render进程中的Compositor线程和Main线程的详细介绍，可以参考前面Chromium网页渲染机制扼要介绍和学习计划1文。

       接下来我们以Touch事件为例，扼要描写Browser进程和Render进程的Compositor线程、Main线程处理输入事件的进程。

       Browser进程处理Touch事件的进程如图3所示：

图3 Browser进程处理Touch事件的进程

       当产生Touch事件时，ContentView类的成员函数onTouchEvent就会被Android系统调用。从前面Chromium硬件加速渲染的OpenGL上下文绘图表面创建进程分析1文可以知道，Java层的每个ContentView对象在C++层都对应有1个ContentViewCore对象。当Java层的每个ContentView对象取得1个Touch事件以后，就会将该Touch事件分发给C++层与它对应的ContentViewCore对象处理。这是通过调用ContentViewCore类的成员函数OnTouchEvent实现的。

       C++层的ContentViewCore对象取得从Java层传递过来的Touch事件以后，就会分别通过1个Gesture Dector和1个Scale Gesture Detector检查这个Touch事件是不是产生了滑动（Scroll）和捏合（Pinch）手势操作。如果产生了，那末它们就会打包在1个Gesture Packet中。这个Gesture Packet又进1步通过1个InputRouter对象封装在1个InputMsg_HandleInputEvent消息中发送给Render进程处理。

       注意，原始的Touch事件同时也会被上述InputRouter对象封装在另外1个InputMsg_HandleInputEvent消息中发送给Render进程处理。这意味1个Touch事件在产生了手势操作的情况下，Browser进程向Render进程发送了两个InputMsg_HandleInputEvent消息。其中1个描写的是1个手势操作，另外1个描写的是原始的输入事件。

       Render进程在启动的时候，会注册1个类型为InputEvent的Filter，用来拦截Browser进程发送过来的输入事件消息，如图4所示：

图4 Compositor线程处理滑动和捏合手势操作的进程

       Filter拦截IPC消息的进程，可以参考前面Chromium的IPC消息发送、接收和分发机制分析1文。

       InputEvent Filter拦截到Browser进程发送过来的InputMsg_HandleInputEvent消息以后，会分给Compositor线程处理。Compositor线程进1步检查这个InputMsg_HandleInputEvent消息是不是是1个滑动手势操作或捏合手势操作。如果是的话，就将它们利用在CC Active Layer Tree中。否则的话，就将拦截到的InputMsg_HandleInputEvent消息转给给Main线程处理。

       从前面Chromium网页渲染机制扼要介绍和学习计划这个系列的文章可以知道，CC Active Layer Tree是通过激活CC Pending Layer Tree得到的，而CC Pending Layer Tree又是通过同步CC Layer Tree得到的。理论上说，Compositor线程应当将滑动和捏合手势操作利用在CC Layer Tree上，然后再同步到CC Pending Layer Tree中，最后再将CC Pending Layer Tree激活为CC Active Layer Tree。这样就能够保证这3个Tree的状态1致性。但是如果这样做的话，会触及到以下4个操作：

       1. 重新绘制CC Layer Tree。

       2. 将重新绘制的CC Layer Tree同步到CC Pending Layer Tree中。

       3. 将CC Pending Layer Tree激活为CC Active Layer Tree中。

       4. 对CC Active Layer Tree进行渲染。

       这个处理进程太漫长了，达不到快速响利用户输入的目的。CC Active Layer Tree描写的是用户当前在屏幕上看到的网页的内容，当用户滑动或捏合网页的时候，网页的内容并没有产生实质的变化，只不过是位置或缩放因子产生了变化，这完全可以通过当前使用的CC Active Layer Tree来处理。这样就能够省掉上述的前3个操作，因而就能够快速发响利用户输入了。从这里我们也能够看出，为何Chromium要用3个Tree来描写同1个网页了，实际上就是为了能够快速地响利用户输入，提高网页阅读的用户体验。

       但是，如果只将滑动和捏合手势操作利用在CC Active Layer Tree上，就会致使它的状态与CC Layer Tree不1致，这是不允许的。为了解决这个问题，Compsitor线程同时会要求调度器履行1个Commit操作。这个Commit操作将会触发Main线程重新绘制CC Layer Tree。Main线程在绘制CC Layer Tree之前，会搜集之前利用在CC Active Layer Tree上的滑动和捏合操作，并且将它们利用在行将要绘制的CC Layer Tree之上。这样就能够保证它的状态与CC Active Layer Tree保证1致了。注意，将滑动和捏合手势操作利用在CC Active Layer Tree上和重新绘制CC Layer Tree分别产生在Compositor线程和Main线程中，它们是并发履行的。

       对那些不是描写手势操作的InputMsg_HandleInputEvent消息，Compositor线程将会转发给Main线程处理，如图5所示：

图5 Main线程处理Touch事件的进程

       从前面Chromium网页Frame Tree创建进程分析1文可以知道，Main线程在加载网页的内容之前，会在WebKit里面创建1个WebViewImpl对象。我们可以将这个WebViewImpl对象理解为WebKit对外提供的1个接口。通过这个接口，Chromium可以操作WebKit为它所加载、解析和渲染的网页。

       Main线程接收到Compositor发送过来的InputMsg_HandleInputEvent消息就会调用上述WebViewImpl对象的成员函数handleInputEvent，用来通知WebKit对该InputMsg_HandleInputEvent消息描写的输入事件进行处理。在我们这个情形中，这个输入事件即为1个Touch事件。

       WebKit接收到Touch事件通知后，所做的第1件事情是做Hit Test，也就是检测Touch事件产生在哪个网页元素上，然后再将接收到的Touch事件交给该网页元素处理。注意，这里说的网页元素，指的是网页DOM Tree中的节点，也就是DOM Node。1旦找到这个目标网页元素，那末WebKit就会调用它的成员函数dispatchTouchEvent，让它处应当前产生的Touch事件。

       现在最重要的事情就是在DOM Tree中找到目标DOM Node。每个输入事件都关联有1个位置，所有在该位置上的DOM Node都多是目标DOM Node。如果输入事件产生的位置没有DOM Node，或只有1个DOM Node，那末事情就好办。但是常常这个位置上有多个DOM Node，因此就需要将其中1个设置为目标DOM Node。1般来讲，在Z轴上位置最高的DOM Node，就是要找的目标DOM Node。

       DOM Tree记录了每个DOM Node的Z-Index值。理论上说，通过这些Z-Index值，就能够肯定1个输入事件的目标DOM Node，也就是仅仅通过DOM Tree就能够肯定1个输入事件的目标DOM Node。但是从前面Chromium网页Graphics Layer Tree创建进程分析1文可以知道，1个DOM Node的Z-Index值其实不能终究决定它在Z轴上的位置，还与这个DOM所在的Stacking Context的Z-Index值有关。例如，假定有两个Stacking Context，SC1和SC2。其中SC1的Z-Index值等于0，SC2的Z-Index值等于1。SC1包括了1个DOM Node，它的Z-Index值等于9，SC2包括了1个DOM Node，它的Z-Index值等于6。终究的效果是Z-Index值为6的DOM Node位于Z-Index值为9的DOM Node之上。这是由于前者所在的Stacking Context的Z-Index值比后者所在的Stacking Context的Z-Index值大的原因。

       WebKit保护的Render Layer Tree记录了网页所有的Stacking Context的信息，因此WebKit在做输入事件的Hit Test时，不能通过DOM Tree来肯定目标DOM Node，而是要通过Render Layer Tree来肯定。

       以上就是Chromium处理输入事件的整体进程概述，它触及到Browser进程，和Render进程中的Compositor线程和Main线程。Browser进程负责手势操作检测，Compositor线程将手势操作利用在网页的CC Active Layer Tree中，Main线程负责将输入事件分发给WebKit处理。为了更好地理解Chromium的输入事件处理机制，接下来我们将依照以下3个情形进行详细分析：

       1. Browser进程处理输入事件的进程分析；

       2. Compositor线程处理输入事件的进程分析；

       3. Main线程处理输入事件的进程分析。

       敬请关注！更多的信息也能够关注老罗的新浪微博：http://weibo.com/shengyangluo。