Chrome高性能的秘密：对Mobile平台的优化

跨平台的资源加载

跨平台也是 Chrome 网络模块的一个主要考量，包括 Linux， Windows, OS X, Chrome OS, Android, 和 iOS。 为此，网络模块尽量实现成了单进程模式（只分出了独立的 cache 和 proxy 进程）的跨平台函数库， 这样就可以在平台间共用基础组件(infrastructure)并分享相同的性能优化，更有机会做到同时为所有平台进行优化。

了解一下代码结构可以帮助我们理解它的能力结构。比如：

• net/android 绑定到 Android 运行时(runtime) [译注(Horky):运行时真是一个很烂的术语，翻和没翻一样。]
• net/base 公共的网络工具函数。比如，主机解析， cookies, 网络转换侦测(network change detection)，以及 SSL 认证管理
• net/cookies 实现了 Cookie 的存储、管理及获取
• net/disk_cache 磁盘和内存缓存的实现 net/dns 实现了一个异步的 DNS 解析器(DNS resolver)
• net/http 实现了 HTTP 协议 net/proxy 代理(SOCKS 和 HTTP)配置、解析(resolution) 、脚本抓取(script fetching)， …
• net/socket TCP sockets,SSL streams 和 socket pools 的跨平台实现
• net/spdy 实现了 SPDY 协议
• net/url_request URLRequest, URLRequestContext 和 URLRequestJob 的实现
• net/websockets 实现了 WebSockets 协议上面每一项都值得好好读读，代码组织的很好，你还会发现大量的单元测试。

Mobile 平台上的架构和性能

移动浏览器正在大发展，Chrome 团队也视优化移动端的体验为最高优先级。先要说明的是移动版的 Chrome 的并不是其桌面版本的直接移植，因为那样根本不会带来好的用户体验。移动端的先天特性就决定了它是一个资源严重受限的环境，在运行参数有一些基本的不同：

桌面用户使用鼠标操作，可以有重叠的窗口，大的屏幕，也不用担心电池。网络也非常稳定，有大量的存储空间和内存。 移动端的用户则是触摸和手势操作，屏幕小，电池电量有限，通过只能用龟速且昂贵的网络，存储空间和内存也是相当受限。

再者，不但没有典型的样板移动设备，反而是有一大批各色硬件的设备。Chrome 要做的，只能是设法兼容这些设备。好在 Chrome 有不同的运行模式(execution models)，面对这些问题，游刃有余。

在 Android 版本上，Chrome 同样运用了桌面版本的多进程架构——一个浏览器内核进程，以及一个或多个渲染进程。但因为内存的限制，移动版的 Chrome 无法为每一个 tab 运行一个特定的渲染进程，而是根据内存情况等条件决定一个最佳的渲染进程个数，然后就会在多个 tab 间共享这些渲染进程。

如果内存实在不足，或其它原因导致 Chrome 无法运行多进程，它就会切到单进程、多线程的模式。比如在 iOS 设备上，因为其沙箱机制的限制，Chrome 只能运行在这种模式下。

关于网络性能，首先 Chrome 在 Android 和 iOS 使用的是各其它平台相同的网络模块。这可以做到跨平台的网络优化，这也是 Chrome 明显领先的优势之一。所不同的是需要经常根据网络情况和设备能力进行些调整， 包括推测优化(speculative optimization)的优先级、socket 的超时设置和管理逻辑、缓存大小等。

比如，为了延长电池寿命，移动端的 Chrome 会倾向于延迟关闭空闲的 sockets (lazy closing of idle sockets)， 通常是为了减少信号(radio)的使用而在打开新的 socket 时关闭旧的。另外因为预渲染(pre-rendering,稍后会介绍)会使用一定的网络和处理资源，它通常只在 WiFi 才会使用。

关于移动浏览体验会独立一章，也许就在 POSA 系列的下一期。