简介：阿里巴巴历时 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 我的项目中去，大家一起共建
原文链接
本文为阿里云原创内容，未经容许不得转载。