Web 技术发展趋势及 U4 内核技术演进招贤纳士我们急需浏览器渲染引擎/Flutter渲染引擎人才，欢迎大牛们加入我们

招贤纳士

我们急需浏览器渲染引擎/Flutter 渲染引擎人才，欢迎大牛们加入我们。

背景

本文作者作为讲师参加了 2020 年上海外滩大会，以下文章来自大会分享内容的整理文稿。

Chromium 重要技术进展

Web 现状

首先我们来看一下这 3 个数字。

不知道大家看到这 3 个数字会有什么样的感受呢？

我最大的感受是：Web 技术的生命力实在是太强大了！在各种新技术层出不穷的今天，Web 经过了 30 多年的发展，除了支撑传统互联网领域的网页搭建，在移动互联网领域也有着非常广泛的应用，比如小程序、信息流、会场这样的业务场景，我们都可以看到 Web 技术的身影。

为什么 Web 能有如此强大的生命力呢？我认为有一点非常重要，就是高度标准化。由于高度标准化，它有着很强的向下兼容性和跨平台兼容性，从而可以非常广泛地应用，而且经久不衰。但是高度标准化也会带来一个问题，就是新特性的落地非常缓慢，一个特性从提出到形成标准，到最终在浏览器中落地，需要经过多年的时间，对于开发者来说，了解浏览器内核的进展更有实际意义。

所以今天我们主要是从浏览器内核的层面，来了解 Web 技术的发展趋势。

全球浏览器内核分布

这里是 statcounter 最近一年对移动端浏览器市场占有率的统计数据。大家可以看到，Chrome 已经遥遥领先，有着超过 60% 的市场占有率。而且这里仅仅是从浏览器维度来统计，如果从内核的维度来看，Opera、UC、QQ 等浏览器都是基于 Chromium 内核，它们总的加起来市场占有率已经超过 70%，可以说 Chromium 已经引领了 Web 技术的发展方向。

接下来我们来看一下 Chromium 的一些重要技术进展。

Chrome 架构优化

首先来了解一下 Chromium 的 3 个大的架构优化：

Onion Soup：它的主要目的是为了解耦 Chromium 内核的组件依赖，使得各种能力可以以服务的方式提供，从而简化复杂的代码结构，提升可扩展性和性能。该项目从 2015 年持续到现在已经有 5 年多的时间，目前还在继续进行中。

Sliming paint：它是渲染流水线的大改造，主要目的是提升渲染正确性和性能，它也经历了 5 年多的时间，目前已经有实验室版本落地，但是正式版还没有发布。

LayoutNG：它是一个新的排版系统，主要是为了抛弃旧排版系统的历史负担，使得新特性的扩展更加容易，而且可以做到可分段和可中断。LayoutNG 历经 4 年的时间，在去年的 m76 版本已经有第一个版本正式上线。但是从我们的实验室测试数据来看，对比旧的排版系统，它并没有明显的性能优势，这方面 Chrome 也在持续优化中，相信随着版本的迭代，LayoutNG 将会逐渐体现出它的技术优势。

看完 Chromium 大的技术架构优化，我们再来看一下 Chromium 的一些重要的功能特性。

PWA

首先是 PWA。它是 Chromium 近几年提出的一个非常重要的概念，从它的名字（渐进式 Web 应用）可以看出，它的主要目标是使得开发者可以利用 Web 技术，逐渐构建出用户体验可以与 native 应用相媲美的 Web 应用。PWA 是各种技术的整合包装，它包括了几个重要特性：Service Worker 提供了离线化访问的能力、A2HS（Add To HomeScreen）提供了添加图标到桌面的能力、Web Push 提供消息推送的能力、Notification API 提供触发手机通知的能力。我们可以看到，一个 Web 页面，有了离线化的访问能力，又可以添加图标到桌面，用户点击图标打开一个应用，几乎分辨不出是 Web 实现还是 native 实现，这就是 PWA 想要达到的效果。除了这 4 个，它还包含了其它的一些特性，这里就不再一一介绍。

Device API

我们再来看一个跟 PWA 目的比较接近的特性 Device API。Device API 也是为了增强 Web 的表现力，但是它是通过开放更多的设备能力给开发者来实现。例如 m67 增加了 Sensor API、m81 增加了 Web NFC，而目前正在开发 Web GPU 等新的 Device API。随着 Device API 的不断增加，Web 对硬件的控制力将越来越强，能力也会越来越强。

WebAssembly

我们再来看一个最近比较受关注的特性——WebAssembly，WASM。WASM 是由 Firefox、Chrome、Microsoft Edge、Safari 4 个大浏览器厂商一起提出的新的浏览器语言标准。它以二进制的格式存在，可以直接运行在 JS 引擎上面，而且它是 AOT 编译的，不需要经过复杂的 JIT 编译流水线就可以直接执行，拥有更高的性能。WASM 的另一个特点是可移植，也是它存在的一个主要目的，我们可以通过编译工具，直接将 native 代码编译成 WASM 运行在浏览器上面，节省开发移植的成本。例如，前段时间 bilibili 分享了他们的一个应用，他们将用 C++ 实现的 FFmpeg 音视频解码库直接编译成 WASM，运行在浏览器上面。随着直播、AI、AR、VR 等新的业务场景崛起，WASM 得到越来越多的关注，它的高性能以及可移植可以很好地应用于这些场景。但是 WASM 也存在一些问题，例如不支持多线程、调试不够友好等，目前 Chromium 在持续优化该特性。

Houdini

接下来我们再来看一个大家不太熟悉的项目——Houdini。Houdini 没有像 WebAssembly 那么出名，但是它对开发者来说，也是一个非常重要的项目。简单来说，Houdini 主要是向开发者提供一系列控制排版渲染流水线的 API 和 CSS 特性，使得开发者可以更容易构建效果酷炫的页面。它主要包括了像 Worklets、CSS parse API、CSS Layout API 等一系列技术标准，目前大部分标准 Chrome 已经支持。例如 CSS Paint API，开发者可以写一段绘制图片的 JS 代码，然后添加到 Worklet 去运行，接下来在 CSS 的 background-image 属性中引用这个 worklet，从而实现用 JS 绘制元素的背景图片。从这个例子我们可以看到，Houdini 的目的是开放出更多浏览器内核能力给开发者，让开发者可以更方便地控制整个排版渲染流水线，从而可以更高效地实现一些复杂的效果，使整个 Web 开发体验更加友好。

Performance API

除了功能和性能方面的优化，我们再来看另外一个重要的特性——Performance API。

Performance API 主要是提供一系列 API 帮助开发者更精确衡量线上页面性能，比如加载时间、事件响应时间、内存占用等等，从而可以更有针对性地做优化，提升线上页面的体验。

Web 技术发展趋势

前面我们了解了 Chrome 近期一些核心的技术演进。从这些技术演进中，我们可以看到 Web 技术的 2 个大的发展趋势，一个是从 Web 应用本身效果来看，Web 的表现力正在越来越接近原生应用，无论是 PWA，还是 Device API，都是在朝着这方面去推进；

第二个是从开发者角度来看，整个 Web 的开发体验也在变得越来越好，无论是 Houdini、Performance API 还是开发者工具平台的完善，都是在使得开发者构建优质的 Web 应用越来越简单高效。

在这 2 个大的发展趋势下面，我们 U4 内核又有着怎样的技术优化呢？接下来我们进入第二部分。

U4 内核技术优化介绍

Ali Web Platform

首先我们来看一下 U4 内核在阿里集团的位置。U4 内核之前主要是通过 UC 浏览器为大家所熟悉，经过这几年的发展，它已经从一个浏览器内核逐渐演变为一个 Web Platform，服务了像支付宝、手淘、天猫、UC、钉钉、飞猪等阿里的大部分 APP，U4 内核是阿里集团中 Web 生态非常重要的组成部分。

我们从一个传统的浏览器内核演变为一个 Web Platform，遇到了那些挑战，又是怎么应对的呢？

Ali Web Platform 遇到的挑战

这个过程我们遇到了 2 个最大的挑战，一个是稳定性、一个是安全性。

稳定性主要体现在 2 个方面：

随着我们的应用场景及机型覆盖面更加广泛，我们遇到的设备及API兼容性问题会更多，导致影响内核的稳定性；
阿里的业务场景非常复杂，对内存、性能提出了更高要求。

安全的挑战主要是跟业务的形态有关，阿里的大部分业务都跟钱有关，例如我们的电商业务、支付业务。跟钱有关，对安全的要求就会非常高。这也对我们 U4 内核也提出了更高的要求。

那么我们是如何应对这 2 个挑战的呢？

U4 内核多进程架构

这里我们做了一件最重要的事情，就是进行进程架构的大改造——从一开始的单进程架构，逐步演进到现在的多进程架构模型。

为什么多进程架构可以应对这 2 个大挑战呢？这里主要体现在3个方面：

多进程架构可以将一些子模块的崩溃隔离到子进程，从而避免影响主进程，引起整个 APP 的崩溃，并且子进程在崩溃后是可以自动恢复的，用户可以在几乎无感知的情况下正常浏览网页；
通过把一些模块放到子进程里，可以有效地缓解主进程虚拟内存空间不足的压力，从而减少 OOM 崩溃。因为对于 32 位应用，Android 每个进程只有 4G 的虚拟内存空间，在复杂的场景下很容易出现虚拟内存空间不足的 OOM 崩溃；
我们做了一个沙箱 Render 进程，沙箱进程是一个权限受限的进程，JS 引擎也是运行在 Render 进程中。通过把 Render 进程隔离到一个权限受限的沙箱进程里面，就算 JS 引擎出现安全漏洞，也可以有效地防止主进程受到攻击，或者核心用户数据遭到窃取。

下面我们来看一下多进程改造后的效果。

首先我们的稳定性有了非常大的提升，主进程崩溃降低 90%+，其中 OOM 更是下降了 97%+。

另外它可以做到子进程崩溃快速自动恢复，使得用户可以在几乎无感知的情况下，恢复页面的浏览。

我们来看一下这个视频。左边是云真机上面运行的支付宝蚂蚁森林，右边是一个命令行终端，我们通过 shell 命令，kill 掉它的 GPU 进程，模拟 GPU 进程发生崩溃的场景。我们可以看到左边的画面，基本看不到任何异常变化。在 GPU 进程被 kill 之后，进程会快速自动恢复，用户在无感知的情况下，继续正常浏览 H5 页面。

打造更好的 Web 平台

解决了稳定性和安全性的 2 大挑战之后，我们就可以成为一个很好的 Web Platform 吗？答案肯定是否定的。

为了打造一个更好的 Web Platform，我们还做了更多的功能优化。首先来看一个我们比较有特色的功能——混合渲染。

混合渲染

混合渲染主要是想解决这样的一个业务痛点：

某些业务之前是用 native 实现的，后面想用 Web 去实现，但是使用的部分第三方组件只有 native 版本。如果使用 Web 重新开发第三方组件，成本会比较高，而且效果也会打个问号。最典型的一个场景就是地图控件。

为了解决这个痛点，我们实现了混合渲染方案。该方案提供了在页面中嵌入 native 组件的能力，将页面和 native 组件无缝地融合起来，并且保证整体效果和交互非常自然，业务不需要做额外的适配。

这里我们来看 2 个视频：第一个视频是之前支付宝上面的 OFO 单车小程序。它的地图是用 native 实现的，而覆盖在地图上面的小控件和文字，都是用 H5 实现的。我们可以看到，整个交互非常自然，用户完全无法区分哪些是 native 组件，哪些是 H5 组件，实现了 native 与 H5 的完美融合；第二个视频是我们的一个 AR 相机的 DEMO，它的相机画面是用 native 技术呈现的，上面的卡片特效是用 H5 呈现的，这里完美地结合了高性能的 native 相机和高动态化的 H5 卡片，很好地融合了 Web 技术与 native 技术的优点。

混合渲染的应用场景非常多，目前已经广泛应用在小程序和各种业务场景中，成为 U4 内核最重要的一个功能特性。

接下来我们再看另外一个比较有特色的功能：游戏模式。

游戏模式

游戏模式是为了解决 Web 游戏性能偏低的痛点。通过我们的调研发现，目前大部分的游戏引擎，都是使用 Canvas 进行游戏画面的渲染，如果可以提升 Canvas 的渲染效率，整个游戏的性能就可以大幅度提升。因此我们开发了一个游戏模式，让 Canvas 的内容可以通过一个精简的渲染流水线，直接输出到一个独立的 SurfaceView 上面，然后再将 Surface 的内容与 WebView 内容进行合成，形成最终的画面输出到屏幕，这样就可以大幅提升游戏的性能。除了高性能和省电之外，我们的游戏模式适配成本也非常低，只需要业务开发者通过 JS API 设置一个标志位就可以开启，无需修改到游戏引擎。

从实验室的测试数据可以看到，我们的游戏模式的帧率和耗电都是处于一个非常优秀的水平，即兼顾了性能又兼顾了功耗。

直接光栅化&直接合成

游戏模式只是提升了特定场景下的渲染性能，对于通用场景的渲染性能，我们有没有什么办法可以优化呢？

在解答这个问题之前，我们先简单了解一下 Chrome 的渲染架构。这个图对渲染流水线做了一个非常简化的抽象，一个网页从文本的形态，最终输出到屏幕被用户看到，主要经历3个阶段：

Blink 对页面内容做解析，排版、绘制，生成一系列绘制指令，输出到子合成器 Layer Compositor；
Layer Compositor 再将 Layer 进行分块、光栅化和纹理上传，生成 Compositor Frame 输出到它的父合成器 Display Compositor；
最后再由 Display Compositor 将 Compositor Frame 翻译成GL绘制命令，将内容绘制到 Window 对应的 Surface，显示到屏幕上面。

由于 Chrome 除了需要渲染网页内容，它还需要渲染 UI 界面，或者是支持像 offscreen canvas 这样的特性，所以它有多个子合成器，跑在不同的进程里面，例如这里的 UI Compositor。

为了提升网页的渲染性能，以及减少渲染过程的内存消耗，我们对 Chromium 渲染流水线做了大改造，实现了直接光栅化和直接合成。这里主要做了 2 件事情：

我们去掉了Layer Compositor之外的子合成器，简化了合成器架构；
去掉了分块的逻辑，将网页的内容直接光栅化到一个surface上面，这样可以节省分块缓存带来的内存消耗，效率也会更高。

改造后的渲染架构如这幅图所示，我们去掉了不需要的子合成器，去掉了分块逻辑，然后将 Display Compositor 放到了 Render 进程，实现了直接光栅化和直接合成。我们的直接光栅化和直接合成，带来了很多的好处。

第一是节省了GPU内存的消耗，降低了15%+；

第二对于Motion Mark动画及首屏渲染性能，也有了明显的提升。

但是直接光栅化也存在一些问题，由于没有分块缓存，在一些低端机或者特别复杂的场景，页面惯性滚动帧率有轻微下降。为了解决这个问题，我们实现了混合光栅化方案，可以根据业务场景复杂度，内核自动切换异步光栅化或者直接光栅化，更好地兼顾了帧率跟内存。

V8 JS引擎优化

除了渲染引擎的优化，我们还对 V8 JS 引擎做了很多优化，这里列举 3 点比较重要的优化：

我们实现了自己的 V8 code cache，相对官方版本，提升了 code cache 的覆盖面，使得 JS 性能提升了 22%；
我们利用 LLVM 改造了 V8 代码生成后端，使得 JS 整体性能提升 20% 以上；
为了方便集团业务方接入 JS 引擎，我们标准化了 JS 引擎接口，做了一个 JSI SDK 封装，使得 JS 引擎集成效率大幅提升。

U4 配套开发平台

除了引擎层面的优化，我们也在不断完善配套平台与工具，针对开发中、开发后以及线上后 3 个关键节点，做了全流程的工具支持，分别提供了 UC 开发者工具、鲁班尺以及 Web 高可用监控平台，帮助开发者更好地开发出高质量的 Web 应用。

UC 开发者工具是基于 Chrome Remote Inspector 定制优化的开发者工具。我们将 remote inspector 做成了独立桌面应用，除了修正了原生的一些调试问题，我们还增加了特有的调试功能，使得开发者可以通过 UC DevTools 更好地调试我们的 U4 内核；
鲁班尺是及我们基于 Chrome LightHouse 打造的线下自动化诊断平台，可以对开发后的应用做自动化诊断分析，得出评分和优化建议，帮助开发者发现页面问题，协助进行页面优化，非常适合作为发布卡口测试工具；
Web 高可用监控平台是我们与内部 iTrace 平台合作打造的线上问题监控诊断平台。目前类似的 APM 平台非常多，但是我们的 Web 高可用监控平台与内核深度结合，使得监控面更广、数据更加准确，实现了很多有特色的监控项，例如白屏监控。出现问题的时候，我们可以关联加载瀑布流数据、JS 错误信息等，提供有效的数据供开发者分析问题。除了白屏监控，我们还有黑屏监控、内存监控、JS 异常等，有效地帮助业务发现和解决了多个线上重大问题。为了更好地服务 Web 开发者，我们的 Web 高可用监控平台，目前也包装成对外的产品，叫“岳鹰”，大家有兴趣可以了解和接入使用。

未来展望

刚才也说到，浏览器内核已经从传统的浏览器内核，逐步演变为 Web Platform，应用到更多的业务场景。在未来，我认为它将继续往 App Platform 去演进。那么 Web Platform 跟 App Platform 有什么区别呢？

Web Platform 主要是强调它应用的广度，App Platform 除了要有更广的应用，它的体验也要达到可以媲美 native 的水平，无论是在性能体验还是在开发体验。

为了实现打造一个 App Platform 的目标，浏览器内核还需要不断地去做优化，包括架构的优化、性能的优化以及更多新标准的支持，从而去增强 Web 应用的性能体验；另外从开发者的角度，也需要不断去完善开发者工具和平台，开放更多浏览器内核的数据和设备的能力，使得开发者可以更高效地开发出一个高质量的 Web 应用。

我们相信，Web 将是移动互联网领域最重要的技术之一，我们也会持续投入，打造一个更好的 App Platform，我们的目标是让 Web 无所不能！

以上就是我的分享，谢谢。

===========================================================================

U4 内核致力于打造性能最好、最安全的 web 平台，让 web 无所不能。

关注公众号请搜索 U4内核技术，即时获取最新的技术动态

Web 技术发展趋势及 U4 内核技术演进