年度人物

上图是浏览器当时渲染的各个线程的任务分布。是多进程架构，上图中的end和end表示不在同一个进程中。线程是内核的主线程，负责解析、排版、执行JS。因为主要是渲染，所以非渲染任务(黄框中)是重点。大多数与渲染相关的任务都在(合成)线程中运行(图中的红色方框代表与渲染相关的任务)。那么早起有什么问题呢？我们先来分析一下这个框架存在的问题：

渲染器线程是一个非常繁忙的线程，浏览器核心的大部分任务都是在这个线程中执行的。光栅化是渲染中非常耗时的任务。如果放在渲染器线程中，会与同一线程中的其他任务争夺运行时间片，相互影响。这样光栅化会比较慢，排版和JS执行的响应会因为渲染任务的插入而延迟。

因为光栅化应该放在渲染器线程上，所以在光栅化之前，有必要将网页分成块，并决定哪些块应该首先去光栅化。也就是说，管理块的功能必须在渲染器线程中。这就导致了一个很麻烦的问题。为了确保快速响应和显示，滑动和缩放处理必须在合成线程中进行。在这种情况下，比如你下滑了一定距离，浏览器需要及时重绘后面的页面块(如果不及时，用户会看到白屏或者白块)。决定光栅化哪些块的逻辑在渲染器线程中。渲染器太忙，所以通常很难等到管理块算法运行并且用户执行下一个操作。或者用户的最后一个操作还没有栅格化，然后他再次执行操作。反正就是各种东西赶不上，总不确定光栅化哪些块。这边渲染器线程举步维艰，另一边排字器线程情况又变了。

还有一点就是页面内容更新产生的脏块和需要用户操作补充的块。应该先画哪个？根据chromium代码中的概念，大型机和implFrame哪个优先级更高？这件事也很纠结，很难判断。

以上缺点带来的不良影响主要体现在用户缩放和滑动场景上。PC上的这些缺点可能是可以容忍的。但是用户在手机上操作频繁，移动终端的性能比PC差很多，所以这些问题比较严重。在chromium开源项目中，为了解决这些问题，开始了渲染架构的调整计划，名为impl-side-painting。顾名思义，把画图，也就是光栅化，放在impl-side的一边。在Chromium的概念中，rendererthread也叫mainthread，compositorthread也叫implthread。也就是说栅格化会移到合成线程。

二、安卓4.4之前的系统webview

在介绍impl-side-painting之前，我们先来看看手机终端的安卓平台(苹果在ios上不允许自己的内核，这是IOS系统内核)。安卓4.0之后进入硬件加速时代，包括浏览器进入硬件绘制阶段(chrome一直都是硬件加速)。在安卓4.x上，另一批来自Googleandroid的人制作了另一个基于WebKit - androidwebview的浏览器内核，这是安卓的系统浏览器。和铬开源项目没关系。当时，安卓系统上自带内核的国产浏览器是基于安卓系统的webview内核进行优化的。与chromium内核相比，该内核代码更简单，渲染架构更高级高效。其渲染任务分布如下：