钉钉表格,从零到一打造在线 Excel | D2 大会分享视频+文章-阿里云开发者社区

开发者社区> AlibabaF2E> 正文
登录阅读全文

钉钉表格,从零到一打造在线 Excel | D2 大会分享视频+文章

简介: 来自钉钉表格应用前端架构师叶斋在第十五届D2前端技术论坛的分享。

作者 | 叶斋

点击查看视频

大家好,我是来自钉钉的叶斋。感谢 D2 组委会,让我有机会在这里分享。我今天分享的主题是《钉钉表格 —— 从零到一打造在线 Excel》。
image.png
我们知道 Excel 是一款有着 30 年悠久历史,功能极为繁多复杂的桌面办公软件。
image.png
近十年来,随着浏览器的进化,在 Web 端出现了一些对标 Excel 的产品,比如 Google Sheets,微软自家的 O365等等。钉钉表格也是其中之一。
image.png
这款产品经过了接近一年的从 0 到 1 的研发,已经完成了 Excel 70% 的功能点,即将正式推出。这次的分享,我将从前端的视角,来谈谈研发这款产品中遇到的一些技术挑战,以及我们的应对策略。
image.png
首先简单地看一下钉钉表格的模块组成,大体上分为五个部分:

  1. 协同引擎,负责与服务器交换数据,保证多人能够在一张表格上工作。

  2. 内核模型,可以理解为表格的本地数据库,提供高性能、正交的数据增删改查。

  3. 控制器,可以理解为 service 层,大部分表格的业务逻辑发生在这里。

  4. 表格组件,一个 React 组件,不包含菜单,工具栏,最主要的部分是由 Canvas 渲染的表格主界面。

  5. 表格应用,最终用户看到的那个钉钉表格。

image.png
接下来我带给大家三个故事:可扩展的表格、协同的表格、高性能的表格。希望能通过这三个故事,带大家一窥究竟。

image.png
第一个故事是,「可扩展的表格」。

image.png
表格最基础,最重要的数据模型,我们称之为「棋盘模型」。棋盘由行和列组成,行列的交点,就形成了一个单元格。非常简单,直观。通常,这个棋盘是由四叉树来实现的,但这里为了不过多展开,我们可以将其视为一个二维数组。
image.png
接下来的问题是:如果我想要为单元格增加样式,比如我想设置单元格的背景色为红色,这时候该对棋盘模型做什么?

一个自然的想法是,直接扩展棋盘中的单元格 cell,为其增加 style.background 属性;同理,我们可能设置单元格的值由公式计算而来,会自然想到在 cell 上增加 formula 属性;我们可能设置合并单元格,会在 cell 上增加 merge 属性,等等。
image.png
接下来,请大家想一下,如果这时用户在表格中插入了两个新列,我们需要做什么?我们需要把两个红色单元格中间新插入的那个单元格设置为红色,因为当插入的单元格两侧具有同样样式的时候,我们需要继承它;同理我们也需要更新公式引用区域的范围;还需要更新合并单元格的尺寸。

大家看,这太麻烦了,不管你增加了什么特性,都得去响应行列操作。因为行列操作在棋盘模型中,是第一公民。你们觉得应该怎么解决这个问题?
image.png
我们仔细观察一下,就会发现不管是样式,公式还是合并单元格,都不是基于单元格组织的,他们本质上是基于棋盘中的一个矩形区域来组织的,这个矩形区域这是 Range。

通过借鉴一些已有的成熟设计,我们引入了一个名为 RangeMan 模块,统一管理和维护 Range。
image.png
不同的功能模块通过 RangeMan 向棋盘模型注入 Range,比如当用户选中两个相邻单元格并设置样式时,其实是为一个 Range 设置了样式;公式与合并单元格也是类似的。

RangeMan 维护的数据,棋盘模型是完全感知不到的。只不过消费数据的时候,会把棋盘和各功能模块的数据组装并渲染。
image.png
然后重点来了:当行列发生增删时,RangeMan 会自动地更新:包括可能改变 Range 的位置和尺寸,甚至删除一些 Range。然后,消费端在渲染时,从各模块获取新的 Range 并体现在界面上。这就是 RangeMan 的原理。

image.png
RangeMan 即简单又强大,它是表格的核心逻辑和业务逻辑间的一道屏障,把两者彻底解耦。绝大部分表格的「业务功能」,包括筛选排序、条件格式等等等等,都是在 RangeMan 的基础上扩展而来的。

image.png
这样,我们的第一个故事,可扩展的模块就讲完了。总结一下:

  1. 首先,棋盘模型是核心,行列操作是第一公民。

  2. 然后,引入 RangeMan 统一管理 Range:注册、更新、销毁。

  3. 最后,基于 RangeMan 扩展表格的各个功能模块。

image.png
第二个故事,是协同的表格。所谓协同,是指我们的表格支持多个用户在同一张表格上工作。
image.png
传统的桌面表格软件是不支持协同的,它的模式非常简单:用户点击「保存」按钮,软件将表格数据写入磁盘。协同表格则要复杂得多,多个用户同时通过 CP 和 OP 与服务端进行数据交换。
image.png
这里的 CP 是 Check Point 的简称,指的是全量的表格数据;OP 是 Operation 的简称,指的是单次表格操作。

image.png
举个例子,当我们新建一个表格时,表格里什么都没有,这是一个空的 CP,版本是 v0。设置 [0,1] 单元格背景色就是一个 OP,版本是 s0。当 CP v0 执行了 OP s0,表格对应的状态,[0,1] 格就被染色了。我们可以接着执行一个 OP s1,在第一行后插入一行,表格状态也会发生变化。当积累的 OP 足够多(我们现在是每 50 个),或者用户手动保存了,或者用户一段时间没操作,我们会生成一个新的 CP,后面的 OP 就在新 CP 上累加了。
image.png
OP 和 CP 的存在,是为了多人协同。具体协同是怎样做的呢?我再举个例子,假设现在有 A / B 两个用户,同时编辑一张空表格。A 作出了一个操作 OP1,设置 [0,1] 的背景色;B 作出了一个操作 OP2,在第一行后插入一行。由于 B 的网络比较好,OP2 先同步到了服务端,服务端执行了 OP2;这时候 A 的 OP1 也同步过来了,我想请大家思考下,你会怎么办?
image.png
一个做法是,直接打回,告诉 A 你这个 OP 已经过时了。这时 A 会生成一个逆 OP1,恢复 [0,1] 的背景色。同时服务端会把 OP2 同步给 A,接着 A 会执行 OP2。然后,关键的一步来了:A 会基于 OP2 变换 OP1,也就是基于「在第一行后插入一行」这么一个 OP,去变换「设置 [0,1] 的背景色」这个 OP,得到新的 OP3,是设置 [0,2] 的背景色,然后再执行。当然,OP3 会依次同步给服务端和 B。

这个算法叫做 GOT,好处是逻辑比较简单,但是有一个问题,在大规模密集协同下,打回率很高,OP 密集到一定程度时,可能一个网络稍微差一点的客户端,就一直在处理打回的 OP,无法收敛。
image.png
接下来,我们介绍另一种算法:还会到刚刚的位置,当 A 的 OP1 同步到服务端时,有没有什么更好的做法?
image.png
更好的做法就是:在服务端直接做变换,基于 OP2 变换 OP1,生成 OP3(也就是设置 [0,2] 的背景色),同时同步给 B。在客户端 A 呢,基于 OP1 变换 OP2,注意这里反过来了,我们基于设置背景色操作,去变换插入行操作。由于设置背景色对插入行操作是完全无影响的,所以得到的 OP4 依然是「在第一行后插入一行」,和 OP2 是完全等价的。A 执行 OP4,得到最终的结果。

这个算法叫做 COT,它的上限更高,但是代价就是需要服务端和前端同时运行一份 OP 变换的逻辑。
image.png
我想再问大家一个问题,协同算法里最重要的部分是什么?其实最重要的,就是图里蓝色的「OP 变换」,Operation Transformation,简称 OT。GOT 只在客户端运行 OT,而 COT 则要求在服务端和客户端同时运行 OT。

在这个例子里面,我们只有 2 种 OP,那么其实是有 4 种 OT 算法。这是一个大的 switch case,每两种 OP 碰到一起,如何变换,都是需要通过硬编码来实现的。

随着 OP 的种类越来越多(比如目前表格已经有 15 种 OP 了),OT 算法的规模会以平方级增长。运行在服务端的 OT 由 Java 同学实现,前端 OT 则由前端技术栈实现,如何保障一致性呢?
image.png
WebAssembly,对,就是 WebAssembly。总之,我们用Rust来编写OT 算法,然后编译成 Assembly,同时分发给服务端和客户端,这样就保证了双端的一致。产品迭代过程中,如果产生了新类型的 OP,也只需要在 Rust 中单独实现,重新编译和分发。
image.png
这样,第二个故事,协同的表格,就讲完了。总结一下:

  1. 首先,OT 是协同的关键。

  2. 上限更高的 COT 调度需要 OT 同时运行在服务端和前端。

  3. 使用 Rust + WSAM 编码 OT 算法,保障一致性。

image.png
最后一个故事是,高性能的表格。
image.png
高性能是什么?我的理解是:长时间,高强度使用,用户感觉不到卡顿。而浏览器里的卡顿,通常和渲染相关。我们知道 DOM 是渲染 Web 应用的首选方案,但是最终我们决定使用 Canvas 来渲染表格的主界面。大家知道为什么吗?
image.png
因为表格和普通网页的形式存在很大的差别,很多 DOM 模型支持的能力,表格是用不到的。这意味着,如果你用 DOM 来渲染表格,就会有很多开销不可避免地浪费在浏览器中的 DOM 渲染管线中。几十年来 DOM 标准的不断迭代,使得浏览器的 DOM 渲染管线成了一个极复杂,兼容性极强的模块,支持从内联 元素到 float 布局等诸多古老特性。这些东西,表格是完全用不上的。
image.png
所以我们使用 Canvas,我们内部有一个「表格渲染管线」,基于 Canvas 实现。我们来看看管线内部的结构。
image.png
首先管线内部是分层的,首先分为网格层,内容层和选区层,内容层内又分背景、文本、装饰三层,文本层前面是排版引擎。每一层可以单独渲染,然后再合成起来,输出到主界面。虚线是管线中流淌的数据流,马上出现的实线是控制流。

  1. 首次渲染,需要重新排版,三层中的每一层都需要重新绘制。

  2. 用户拖拽选区时,只有选区层需要重绘,因为选区的渲染很简单,此时开销是很小的。

  3. 当用户改了单元格的值,需要重新排版(当然是增量的),内容层需要重绘。

  4. 表格滚动的时候,每一层都需要重绘;但不需要重新排版。

可以看到,渲染管线在发生不同的操作时,只重绘那些必要的图层,以此来保障性能。

其实分层是任何渲染系统作性能优化时的一个最基本的手段。即使分层了,我们这个表格在滚动时的重绘开销依旧比较客观。因为单元格的数量是比较多的,每个格子里面的文本有可能是换行的,甚至还有富文本出现,导致绘制文本的次数非常多。
image.png
所以我们对文本层又专门作了优化:就是「双缓冲画布」的渲染方案。

我们会准备两块缓冲画布,每一块都比视窗要大一圈,视窗里的内容,比如现在的 D2 区域,是从缓冲画布中裁剪出来的。

image.png
如果这时候发生了滚动,视窗从 D2 区域缓缓向 D1 滚动,我们不需要重绘,只需

要从缓冲画布中裁剪新的区域过来就可以。
image.png
当滚动到一个阈值时,我们会在缓冲画布 2 上以 D1 区域为中心进行重绘,然后把视窗从缓冲画布 1 挪到缓冲画布 2,再清空第一块画布,这样就恢复到了初始状态,完成了一个循环。

双缓冲画布的优势是,重绘的频率大大降低了,但单次重绘的开销却变大了。所以我们在有条件的浏览器中,把缓冲画布的渲染封到 web-worker 里,这样就比较好了。

在表格渲染管线中,我们还遇到一个挑战,就是如何去对文本作排版。在 DOM 中,排版是浏览器替我们完成的:你在 div 里放一段文本,设置好 div 的宽度,浏览器会自动去折行,去对齐。使用 Canvas 之后,你就得自己手动做这件事了。我们表格内有一个小型的排版引擎,还挺有意思的,不妨也分享一下。
image.png
首先我们看一些基础知识。我们在 Canvas 中去画形状,比如画一个矩形的时候,是非常明确地知道,将要在哪一块区域绘制的,因为绘制的参数宽高就给出了答案。但是绘制文本的时候,你必须通过一些手段才能知道这些信息。通过对文本的测量,你才能知道文本你绘制的原点在哪,文本占据的怎样一块区域。

image.png
有了这些知识,就可以进行排版了。假设我们现在要把这么一段文本排进上面这个单元格,首先根据单元格的宽度去把文本拆成若干行。这里是有分词的,第二行开头,Windows 的前几个字母可以排进第一行的,但是因为整个单词排不进去,就会被划到第二行。
image.png
拆成三行之后,会根据水平对齐和垂直对齐,比如图里的水平对齐是靠右对齐,垂直对齐是底部对齐,根据对齐方式测量出每一行文本的原点,原点的坐标就传给 fillText 方法来绘制了。

image.png
这就是整个排版和绘制的原理。这样,我的第三个故事,也就讲完了。总结一下:

  1. 选择 canvas 渲染表格主界面。

  2. 分层的表格渲染管线,减少重绘。

  3. 双缓冲画布支持流畅滚动。

  4. 自研小型排版引擎,支持单元格内折行、分词、对齐等样式。

image.png
这样,三个故事就全部讲完了。其实说了这么多,钉钉表格,从 0 到 1 的研发,究竟走了一条怎样的路呢?其实也很简单:

  1. 向上,吸收和借鉴桌面软件的已有成熟设计,比如 RangeMan,渲染管线的思想,分词和排版算法。

  2. 向下,整合前端领域最先进,最主流的技术,包括 WebAssembly,Worker,Canvas 等等。

把它们聚合在一起,共冶一炉,锻造出钉钉表格这样一个超级复杂的 Web 应用。


🔥第十五届 D2 前端技术论坛 PPT 集合已放出,马上获取

image.png
关注「Alibaba F2E」
回复 「PPT」一键获取大会完整PPT

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
AlibabaF2E
使用钉钉扫一扫加入圈子
+ 订阅

阿里经济体前端技术最新内容汇聚在此,由阿里经济体前端委员会官方运营。我们的愿景是建立全球一流的前端团队,链接商业,让数字世界触手可及是我们的使命。阿里经济体前端委员会致力于加强技术前瞻性、推进集体成长、提升国际影响力。同时我们运营着阿里经济体前端的官方公众号:Alibaba F2E,欢迎关注。

官方博客