Mobile平台上的架构和性能 移动浏览器正在大发展，Chrome团队也视优化移动端的体验为最高优先级。先要说明的是移动版的Chrome的并不是其桌面版本的直接移植，因为那样根本不会带来好的用户体验。移动端的先天特性就决定了它是一个资源严重受限的环境，在运行参数有一些基本的不同: 桌面用户使用鼠标操作，可以有重叠的窗口，大的屏幕，也不用担心电池。网络也非常稳定，有大量的存储空间和内存。 移动端的用户则是触摸和手势操作，屏幕小，电池电量有限，通过只能用龟速且昂贵的网络，存储空间和内存也是相当受限。 再者，不但没有典型的样板移动设备，反而是有一大批各色硬件的设备。Chrome要做的，只能是设法兼容这些设备。好在Chrome有不同的运行模式(execution models)，面对这些问题，游刃有余！ 在Android版本上，Chrome同样运用了桌面版本的多进程架构- 一个浏览器内核进程，以及一个或多个渲染进程。但因为内存的限制，移动版的Chrome无法为每一个tabl运行一个特定的渲染进程，而是根据内存情况等 条件决定一个最佳的渲染进程个数，然后就会在多个tab间共享这些渲染进程。 如果内存实在不足，或其它原因导致Chrome无法运行多进程，它就会切到单进程、多线程的模式。比如在iOS设备上，因为其沙箱机制的限制，Chrome只能运行在这种模式下。 关于网络性能，首先Chrome在Android和iOS使用的是 各其它平台相同的网络模块。这可以做到跨平台的网络优化，这也是Chrome明显领先的优势之一。所不同的是需要经常根据网络情况和设备能力进行些调整， 包括推测优化(speculative optimization)的优先级、socket的超时设置和管理逻辑、缓存大小等。 比如，为了延长电池寿命，移动端的Chrome会倾向于延迟关闭空 闲的sockets (lazy closing of idle sockets), 通常是为了减少信号(radio)的使用而在打开新的socket时关闭旧的。另外因为预渲染(pre-rendering,稍后会介绍)会使用一定的网 络和处理资源，它通常只在WiFi才会使用。 关于移动浏览体验会独立一章，也许就在POSA系列的下一期。 Chrome Predictor的预测功能优化 Chrome会随着使用变得更快。 它这个特性是通过一个单例对象Predictor来实现的。这个对象在浏览器内核进程(Browser Kernel Process)中实例化，它唯一的职责就是观察和学习当前网络活动方式，提前预估用户下一步的操作。下面是一个示例： 用户将鼠标停留在一个链接上，就预示着一个用户的偏好以及下一步的浏览行为。这时Chrome就可以提前进行DNS Lookup及TCP握手。用户的点击操作平均需要将近200ms,在这个时间就可能处理完DNS和TCP相关的操作, 也就是省去几百毫秒的延迟时间。 当在地址栏(Omnibox/URL bar) 触发高可能性选项时，就同样会触发一个DNS lookup和TCP预连接(pre-connect)，甚至在一个不可见的页签中进行预渲染(pre-render)! 我们每个人都一串天天会访问的网站, Chrome会研究在这些页面上的子资源, 并且尝试进行预解析(pre-resolve), 甚至可能会进行预加载(pre-fetch)以优化浏览体验。 除了上面三项，还有很多.. Chrome会在你使用过程中学习Web的拓扑结构，而不单单是你的浏览模式。理想的话，它将为你省去数百毫秒的延迟, 更接近于即时页面加载的状态. 正是为了这个目标,Chrome投入了以下的核心优化技术: DNS预解析(pre-resolve) 提前解析主机地址,以减少DNS延迟 TCP预连接(pre-connect) 提前连接到目标服务器,以减少TCP握手延迟 资源预加载(prefetching) 提前加载页面的核心资源,以加载页面显示 页面预渲染(prerendering) 每一个决策都包含着一个或多个的优化, 用来克服大量的限制因素. 不过毕竟都只是预测性的优化策略，如果效果不理想，就会引入多余的处理和网络传输。甚至可能会带来一些加载时间上的负体验。 Chrome如何处理这些问题呢? Predictor会尽量收集各种信息，诸如用户操作，历史浏览数据，以及来自渲染引擎(render)和网络模块自身的信息。 和Chrome中负责网络事务调度的ResourceDispatcherHost不同，Predictor对象会针对用户和网络事务创建一组过滤器(filter): IPC channel filter用来监控来自render进程的事务。 每个请求上都会加一个ConnectInterceptor 对象，这样就可以跟踪网络传输的模式以及每一个请求的度量数据。 渲染进程(render process)会在一系列的事件下发送消息到浏览器进程(browser process), 这些事件被定义在一个枚举(ResolutionMotivation)中以便于使用 (url_info.h): enum ResolutionMotivation { MOUSE_OVER_MOTIVATED, // 鼠标悬停. OMNIBOX_MOTIVATED, // Omni-box建议进行解析. STARTUP_LIST_MOTIVATED, // 这是在前10个启动项中的资源. EARLY_LOAD_MOTIVATED, // 有时需要使用prefetched来提前建立连接. // 下面定义了预加载评估的方式，会由一个navigation变量指定. // referring_url_也需要同时指定. STATIC_REFERAL_MOTIVATED, // 外部数据库(External Database)建议进行解析。 LEARNED_REFERAL_MOTIVATED, // 前一次浏览(prior navigation建议进行解析. SELF_REFERAL_MOTIVATED, // 猜测下一个连接是不是需要进行解析. // <略> … }; 通过这些给定的事 件，Predictor的目标就可以评估它成功的可能性, 然后再适时触发操作。每一项事件都有其成功的机率、优先级以及时间戳，这些可以在内部维护一个用优先级管理的队列，也是优化的一个手段。最终，对于这个队 列中发出的每一个请求的成功率，都可以被Predictor追踪到。基于这些数据，Predictor就可以进一步优化它的决策。 Chrome网络架构小结 Chrome使用多进程架构，将渲染进程同浏览器进程隔离开来。 Chrome维护着一个资源分发器的实例(a single instance of the resource dispatcher), 它运行在浏览器内核进程，并在各个渲染进程间共享。 网络层是跨平台的,大部分情况下以单进程库存在。 网络层使用非阻塞式(no-blocking)操作来管理所有网络任务。 共享的网络层支持有效的资源排序、复用、并为浏览器提供在多进程间进行全局优化的能力。 每一个渲染进程通过IPC和资源分发器(resource dispatcher)通讯。 资源分发器(Resource dispatcher)通过自定义的IPC Filter解析资源请求。 Predictor在解析资源请求和响应网络事务中学习，并对后续的网络请求进行优化。 Predictor会根据学习到的网络事务模式预测性的进行DNS解析, TCP握手，甚至是资源请求，为用户实际操作时节省数百毫秒的时间。 了解晦涩的内部细节后，让我们来看一下用户可以感受到的优化。一切从全新的Chrome开始。 |
