基于 Flutter 的 Web 渲染引擎「北海」正式开源！

简介： 阿里巴巴历时 3 年自研开发的 Web 渲染引擎北海（英文名：Kraken）正式开源，致力打造易扩展，跨平台，高性能的渲染引擎，并已在优酷、大麦、天猫等业务场景中使用。

做者 | 染陌
来源 | 阿里技术公众号

阿里巴巴历时 3 年自研开发的 Web 渲染引擎北海（英文名：Kraken）正式开源，致力打造易扩展，跨平台，高性能的渲染引擎，并已在优酷、大麦、天猫等业务场景中使用。

官网：https://openkraken.com
Github：https://github.com/openkraken...

一 背景

互联网业务如火如荼地发展离不开跨平台技术，而最成熟的跨平台技术就是你们熟悉的浏览器了，它与生俱来的跨平台能力、开放的标准以及强大的生态使它成为煊赫一时的容器之一。而因为其自己不是为了性能而设计的，而且历史包袱重、兼容性、厂商更新慢等问题，浏览器在移动端的表现并不突出。尽管网络以及硬件的发展带来了足够多的性能红利，可是日益复杂的业务总能把已有的性能吃透。

过去也有不少对跨平台方案的探索与实践，新的技术方案也随着历史的浪潮不断地发展。从最先的 H5 方案到 Hybrid 方案，以及后来的 Weex/React Native 方案，到如今如火如荼的 Flutter。

Flutter 因为其精简的渲染管线，高效的布局渲染能力，以及自绘渲染的特性，一跃成为这两年跨端届的新宠。而在 Flutter 出现以前，主流的方案仍是用 React Native（Weex）的，这套方案的底层调用了原生的 View。正是由于如此，致使这套方案很难保证彻底的多端一致性，由于原生 View 自己就存在一些限制，有限的能力不能知足开发者全部的需求，因此在实现 W3C 标准时有些牵强。而 Flutter 基于更底层的 Skia 作自绘渲染，能够很好地保证多端一致性。

熟悉 Flutter 的同窗确定知道 Flutter 是用 Dart 语言以及 Widget 来开发的，虽然说 Dart 语言对熟悉 JavaScript 的前端同窗来讲上手成本并非很高，对于 Widget 这种基于状态驱动的开发模式也已是很是熟悉，可是总体上与已有基建与前端生态割裂的矛盾是没法接受的。再者，动态化能力对于互联网业务来讲简直就是刚需，而目前来看 Flutter for Web 并不理想。

毕竟，引入一项新技术的第一步是解决引入这项新技术的成本问题。因此咱们积极探索一种向上对接前端生态，向下使用原生渲染的跨平台方案。

因而诞生了这款基于 W3C 标准的高性能跨终端渲染引擎——北海（Kraken）。

二 基于 W3C 标准

Kraken 最终要服务的用户仍是前端开发者，那么如何下降前端开发者的学习熟悉成本以及如何将老项目快速地迁移到 Kraken 之上呢？咱们并不想从新创造一套新的 DSL 做为研发框架来给开发者用，若是须要的话，那 Flutter 自己的 Widget + Dart 已经作得很不错了。前端开发者多是用 Rax，也有多是用 Vue 或是 React 的，咱们都指望 Kraken 的用户可以作到“零成本”的快速接入。那么，就须要依赖一套开发者很是熟悉的标准来实现 Kraken。

W3C 标准是互联网最重要的标准之一，也是前端开发者很是熟悉的标准，基于 W3C 标准来实现渲染引擎，对于熟悉浏览器的前端开发者能够作到近乎“零成本”的快速上手。同时，咱们能够摈弃一些沉重的历史包袱，使得 Kraken 的渲染效率更高。

三 强大的前端开发者生态

受益于基于 W3C 标准来开发，在 Kraken 上前端开发者彻底可使用目前熟悉的庞大的前端生态。

首先，在研发框架的选择上，不管开发者使用的是 Rax 或者 Vue ，仍是 React 或者 Angular 的，均可以保证在 Kraken 上很好地完成渲染。

再次，前端拥有很是繁荣的生态，社区海量的 NPM 包均可以在 Kraken 项目上直接使用，大量成熟的模块保证了业务开发的效率。

除此以外，开发者平时在开发项目使用的各式各样的工具，均可以在 Kraken 项目上直接使用，无需任何额外的熟悉以及学习成本。

经过对接了 Chrome DevTools Protocol，使开发者能够直接使用很是熟悉的 Chrome DevTools 来调试所开发的页面。不管开发者须要修改 CSS 样式，仍是查看 DOM 结构，或者是经过断点调试 JavaScript 代码，都能保证跟 Web 开发一致的调试体验。

四 渲染一致性

Kraken 的渲染能力是对其 W3C 标准的，因此能够保证跟 Web 渲染的结果彻底一致。

五 比 Web 更好的体验与能力

那么到这里会有同窗想问了，除了与目前前端开发一致的开发及调试体验，以及渲染一致性，那么最终到底能获得怎么样的能力，以及跟浏览器比，到底能够得到哪些收益呢？

1 无限滚动列表

在业务开发中，有时开发者会遇到一些没法用分页却又大量数据的「无限滚动列表」。在客户端开发中有 RecyclerView/UITableView 来实现滚动回收的布局容器，而 Web 标准上尽管也有不少前端侧的优化方案来处理这个问题，但也一直是个难题。Kraken 尝试在容器侧解决了此问题，增长 CSS Display 属性值——sliver。

当 Sliver 容器中的子元素滚动出该容器的 Viewport 时，能够将该子元素中用于渲染的 renderobject 回收以达到节省内存占用的目的。当子元素从新出现时，根据 DOM 描述从新生成 renderobject。

这是一个上万个节点的 demo，左边是 overflow: scroll 的容器，而右边是 display: sliver 的容器，能够看到 sliver 容器在「无限滚动列表」场景下滚动明显流畅不少。左上角有 FPS 的数据，能够看到 display: sliver 的容器 FPS 一直维持正常水平，而 overflow: scroll 的容器 FPS 明显降低。此外，在内存方面也有较大收益。

2 同步光栅化

在浏览器中，光栅化是异步进行的，进行惯性滚动时，会出现白屏，这个是 WebView 始终没法避免的问题。而借助 Flutter 足够高效的同步光栅化实现，Kraken 能够作到长列表快速滚动不白屏。

3 加强的手势能力

Kraken 经过对经常使用手势进行内置，使业务开发者使用手势能力的时候，不再须要引入一个 JavaScript lib 以劫持 Touch event 来作开发了。

以轻扫手势“swipe”为例，开发者只须要经过如下方式就能够得到一个 element 上默认提供的手势能力。直接使用内置加强的手势能力，可以更快速地开发复杂的可交互应用。

element.addEventLisenter('swipe',(gestureEvent) => {
///...
})
加强的手势能力解决了 Web 下本来须要频繁传递事件的性能问题以及 JavaScript 处理手势占用 UI 线程的问题。此外，经过容器内部实现的竞争场能力，能够解决 Web 下手势穿透等问题。

而内置的标准化手势能力，也保证同个容器的不一样应用下，手势交互能力的标准化以及统一性。

4 插件化能力

除了上面的那些超越 Web 的体验与能力之外，Kraken 很是重要的一个特性就是插件化能力，插件化能力提供给前端工程师从新定义浏览器能力的机会，开发者只须要编码一个 Flutter plugin，就能够扩展 Kraken 自己的能力。

经过插件化能力，开发者能够在内部实现许多自定义的标签（譬如说 Camera 或者自定义的视频播放器等），也能够基于性能的考虑将经常使用的业务组件（譬如说 Slider）下沉到容器层。因为浏览器厂商开发以及标准制定每每是滞后的，用插件化能力开发者能够快速地自定义各类渲染能力，使业务开发能够用到最新的或者加强的各类能力。

除了扩展渲染能力，开发者还能够扩展手势能力，扩展手势能力能够将以往须要在前端劫持 Touch Event 实现的能力下沉到容器自己，除了加强了交互体验，也给交互提供了更多可能性。

六 稳定性保障

渲染引擎很是复杂，常常出现改一个 Bug 牵一发而动全身，因此须要高覆盖率的自动化测试来保障渲染引擎的稳定性，每次修改后都须要保障已有的 case 没有问题。经过自动化测试来保障每一个 case 与修改以前的结果作对比，若是有差别，能够经过 case 以及差别的 diff 来修改 Bug。

这套自动化测试系统保证了 Kraken 每次修改先后获得的 case 结果的一致性，以确保渲染引擎自己的稳定性。

目前已经有近 3000 个测试用例，将来还会根据更多的场景继续增长，以此来保证 Kraken 的稳定性。

七 业务落地

讲了那么多 Kraken 的能力，确定有同窗想知道 Kraken 在实际生产场景的表现如何。

目前 Kraken 在 C 端场景移动设备以及低性能 IoT 设备均有相关业务接入，彻底可使用在实际生产场景。

在优酷 APP 中，Kraken 已经落地了大量业务。如下方所示身份详情页为例，Kraken 改造后启动有了一个质的提高，相较于同个页面的 原方案，首屏渲染提高28.4%，帧率提高 8.3%。

在 IoT 设备上，咱们的天猫 U 先业务在线下低性能的 IoT 设备上，Kraken 也有很是不错的表现。在线下相对较复杂的 Slider 等场景下，动画以及交互性能都表现较好，长时间运行应用，内存稳定并没有明显增加，保证线下 IoT 应用的稳定性。

image.png

八 社区协做机制

kraken 团队指望经过一种良好的社区协做机制，来与社区的众多开发者一块儿共建 Kraken 底层能力及生态。

kraken 团队指望经过协做者的方式来参与 Kraken 功能迭代以及 issue 讨论等工做。同时，经过由一部分协做者组成的技术委员会（TSC）来肯定技术方向、发布以及定制标准等工做。

kraken 团队指望经过一种公平良好的协做机制，让社区的开发者可以更好地参与到对 Web 标准的容器技术的演进中去，让每一个人的声音都能被听到，共同促进 Kraken 以及行业的发展。

查看更详细的协做机制能够移步github。

九 将来展望

以往咱们在作前端性能优化的时候，每每优化到浏览器层面就优化不动了，很难向下进行进一步的优化。而 Kraken 的出现，给予了前端工程师新的机会与挑战，它提供了前端工程师一个从新定义浏览器的能力的机会，拥有很是大的想象空间：

超越 Web 的能力，比肩 Native 的性能与体验。

比浏览器厂商更快地实现标准，站在标准的前沿定义问题，经过实现的能力去反推标准，促进行业的发展。

能够自顶向下看整个渲染链路的优化及体验，经过全链路的手段去优化性能以及定义一些新的渲染能力。

目前日益复杂的前端应用致使 JS bundle 的已经显得愈来愈臃肿，开发者也能够把经常使用能力抽象复用并下沉到容器层面，渲染与公用能力的复用再也不只依赖于 NPM，能够经过下沉通用能力来作更多事情。

经过“云+端”的结合，也有机会去探索面向将来的新一代渲染技术。

基于 Kraken，探索更多的可能性......

最后，指望 Kraken 能给你们带来更好的体验及能力，也但愿你们能够积极参与到 Kraken 项目中去，你们一块儿共建
原文连接本文为阿里云原创内容，未经容许不得转载。