文档介绍：【四】Chrome的UI绘制
1. Chrome的窗口控件
Chrome提供了自己的一个UI控件库，相关文档可以参见这里。用Chrome自己的话来说，我觉得市面上的七荤八素的图形控件库都不好用，于是自己倒腾倒腾实现了一套。。。
广告虽距离，为其始乱终弃埋下了伏笔。Chrome在WebKit上封装了一层，称为 WebKit Glue。Glue层中，大部分类型的结构和接口都和WebKit类似，Chrome中依托WebKit的组件，都只是调用WebKit Glue层的接口，而不是直接调用WebKit中的类型。按照Chrome自己文档中的话来说，就是，虽然我们再用WebKit实现页面的渲染，但通过这个设计（加一个间接层…）已经从某种程度大大降低了与WebKit的耦合，使得可以很容易将WebKit换成某个未来可能出现的更好的渲染引擎。。。
重用
在《梦断代码》中，有一坨调侃重用的文字。他觉着软件重用的困难一方面来自于场景本身很多变，很难设计出一套包罗万象的东西；另一方面来自于人，程序员总是瞅着别人写的代码不顺眼，总喜欢自己写一套。。。
于是，解决重用这个问题也就只有两种，写最NB人见人服无所不能的代码，或者是有很多很多NB代码共君任选。Google无疑在这两个方面做得都不错，Map/Reduce，Big Table之类的一套东西，强大到可以适合太多的场景，大大简化了N多上层应用的开发。而对开源的利用使用，使得其可以随意挑一个巨人站到他肩膀上跳舞，每看到这种场景，MS估计都会气得拍着胸口吐血。。。
Google本身在服务端的基础底层，有很深积累，随着Chrome，Android等等客户端应用的开发，客户端的积累也逐步提升，也许，拥抱开源才是
MS的正道？。。。
当你键入一个Url并敲下回车后，Chrome会在Browser进程中下载Url对应的页面资源（包括Web页面和Cookie），而不是直接将Url发送给Render进程让它们自行下载（你会越来越发现，Render进程绝对是100%的名符其实，除了绘制，几乎啥多余的事情都不会干的…）。与各个Render进程各自为站，各自管好自己所需的资源相比，这种策略仿佛会增加大量的进程间通信。之所以采用，按照这篇文档的解释，主要有三个优点，一个是避免子进程与网络通信，从而将网络通信的权限牢牢握在主进程手中，Render进程能力弱了，想造反干坏事的可能性就降低了（可以更好控制各个Render进程的权限…）；另一个是有利于Cookie等持久化资源在不同页面中的共享，否则在不同Render进程中传递 Cookie这样的事情，做起来更麻烦；还有一点很重要的，是可以控制与网络建立HTTP连接的数量，以Browser为代表与网络各方进行通信，各种优化策略都比较好开展（比如池化）。。。
当然，在Browser进程中进行统一的资源管理，也就意味着不再方便用WebKit进行资源下载（WebKit当然有此能力，不过再次被Chrome抛弃了…），而是依托WinHTTP来做的。WinHTTP在接受数据的过程中，会不停的把数据和相关的消息通过IPC，发送给负责绘制此页面的Render进程中对应的RenderView。在这里，路由消息中的那个ID值起了关键的作用，系统依照此ID，能够准确的将相关的消息发送到相关的Vi