苹果电脑numbers怎么合并单元格看这里!语雀在线表格自研之路

作家：柳春

转发链接：

背景介绍

鱼鸟是蚂蚁金融体验技术部的创新产品，目前已经商业化。

面向个人和组织提供知识创作，组织，交流服务。如果你或者你的团队有知识管理的需要，可以尝试使用语雀。语雀一直很看中创作体验，所以我们在编辑器这个领域一直持续的投入研发，不断迭代，今天要介绍的就是我们自主研发的在线电子表格：

在准备这个分享的时候，我特意去看了下代码的第一次提交记录，是去年的5月29日，刚好一年的时间，在分享的前面，先给大家介绍下语雀电子表格这一年的研发时间表：

2019年

5月：立项
8月: beta版上线，具备基本的行列操作，基本样式，合并单元格，筛选排序，支持插入链接，图片，附件，checkbox，下拉选项等
9月：导入功能，多sheet，公式，统计栏，增加日期、货币、时间类型
10月：格式刷，图片复制粘贴，支持附件预览，边框功能上线
11月：导出功能上线，实时协同上线，单元格保护功能
12月：图表功能上线，选择性粘贴

2020年：

1～3月：稳定性，兼容性，性能，体验优化
4月：条件格式，下拉选项优化
5月：表格模版，筛选优化，颜色筛选

有兴趣的同学可以到语雀的更新日志里了解更多详情。

经过一年的研发，语雀已经能够满足 80～90% 普通 Excel 用户的功能需求，以下是目前我们的功能集，接下来我们会控制新功能的上线节奏，会专门针对已有功能做深度优化，我们希望这些最基础的功能，能够给用户带来喜悦。

通过上述介绍，希望大家能对语雀目前的状态有一个整体的了解。

接下来会分三部分介绍语雀的自研历程：Why, How, What

在语雀团队以及体验技术部，不管做什么，我们都会多问自己几个为什么，想透为什么做往往比去思考怎么做更重要。

Why：介绍我们在做表格前期的思考。

How：讲的是怎么做，以及研发过程中的一些方法和技术选型。

What: 谈一谈关于自研的一些心得。

WHY

这一部分我会介绍两个问题：

为什么做在线电子表格
为什么选择自研

为什么做在线表格

电子表格起源

提到电子表格，大家可能最先想到的是 Excel，我们的一些用户在向我们咨询问题的时候也有的说“你们语雀的Excel做的怎么怎么样”，我觉得这是 Excel 这么多年来在大家心里形成了根深蒂固的影响，认为表格就是Excel，但其实 Excel 并不是第一个电子表格软件。第一个电子表格要追溯到 1978 年，美国的一个大牛 Dan Bricklin，在大学实验室做的一款叫做 VisiCalc 的程序。

这是首次利用行列布局来完成数字的录入和计算的软件，虽然简单，但已经具备了如今电子表格最核心的行列模型，当时人们做生意都是用笔记在账本上，一条条记录，到了月底要做汇总对账，效率非常低，而且容易出错，一旦出错就得重头算，所以 VisiCalc 一面世就获得人们的喜爱。这款软件当时就是安装在苹果2代的个人电脑上。

就是靠这款软件，当时苹果电脑 2 代打开市场，大卖特卖，乔布斯当年接受采访时说电子表格促进了产业发展，VisiCalc 促成了苹果的成功。

电子表格关键历程

1985年：

Excel 1.0 面世，这版 Excel 是微软专门为苹果开发的软件，后来盖茨觉得给人写软件不过瘾，就搞出来windows。这里面还有一段乔布斯和盖茨的一段恩怨故事。

1988年：

求伯君在小黑屋里写了14个月开发出来的一个国产办公软件 WPS，为国内程序员所敬仰。

1993年：

微软推出Office办公套件，将 Excel 捆绑进来，再后来就是 Excel 一骑绝尘，不断迭代，几乎没有对手。

2006年：

出现了一个新鲜事物 Google Docs，所有程序员都看呆了，原来在网页上可以实现客户端办公软件的能力，这也一定程度掀起了前端行业的逐步繁荣。

2007年：

苹果开发了自己的电子表格 Numbers, 这是一款体验很棒的电子表格，不改苹果一贯的简单风格，但藏在里面的有非常强大的功能，目前还不支持在线协同。

2011年：

微软开始关注在线办公体验，推出在线版的 Office 365, 在线版的Excel体验真的很一般。

2013年：

Airtable 出现，人们开始意识到，原来的电子表格可以这么玩，这就是后面要说到底同构表。

2016年：

国内才陆续出现在线电子表格的产品，其中wps, 石墨在这块做的比较早，再后来腾讯和飞书等大厂也开始跟进。

从上述持续40几年的历史长河中，电子表格始终保持着旺盛的生命力，功能不断完善，从客户端软件走向线上，足以证明人们对数据处理的需求始终旺盛。

语雀与 DIKW 模型

再说回来，为什么语雀要做电子表格，这得从一个词来说起，那就是“知识”，知识怎么定义。

语雀的产品定位是云端知识库，我们内部一直有一个有意思的讨论就是：“什么是知识”，知识和数据之间又有什么关系，直到我们发现这个模型，早在1888年，就有人在思考这个问题，托马斯·斯特尔那斯·艾略特在一本《The Rock》书中思考过知识，智慧，咨询之间的关系，后来学者们逐步完善这样一个模型，DIKW模型

数据层：数据是最原始的素材，这一层的关键任务是记录，数据本身也具备信息属性，但反应的更多的是过去，比如杭州市2019年每天的气温，湿度，降雨等数据。
信息层：从数据层中提炼一些浓度更高的信息，或者根据数据的关系进行统计分析，发现一些规律性，比如杭州的年平均气温，几月份最热，几月份最舒服，这些信息已经足够精炼，也已经具备了一定参考价值。
知识层：通常信息层已经具备生活和生产的指导性了，但信息层的信息还比较零碎，知识层则是结合更多维度的信息，有针对性，有目的性的将零碎的信息进行归类，连接，产出一些更全面的信息，比如把全球近100年的气象数据进行分析，就会发现地球温度在上升，于是结合数据之间的关系，发现了温室效应，经过验证发现，二氧化碳是造成温室效应的原因，这种知识的价值就更大了，所以：知识就是来源于生活，被大众认可，最终能够帮助人们作出决策的东西。
智慧层：随着对知识的运用，人们通过收集到的数据就可以预测未来会怎样发展，这就是智慧。

在这个模型中，可以很清楚的看到，要形成知识，人们首先要从数据处理中产出信息，在这一步表格就发挥了非常重要的作用。文档则是从信息到知识的进一步整理，所以，作为要打造专业的云端知识库，我们在整个知识的产生过程中，自然不能缺失数据处理这一环。

为什么自研

为什么选择自研，我记得小米有品的一个营销负责人有一句话说的很好：“生活中99%的产品都值得被重新创造一次”。

作为电子表格这样一款几十年历史的产品，如何重新创造？Airtable 给出了他的答卷，他更像一个在线版的 Database。其实，语雀曾经也在集团内部推出过一版类似 airtable 的同构表格，是基于 spreadjs 来做的，发现用户并不是很买账这个新鲜事物，加上后续的一些变故，我们停止继续研发，因为总有一种手脚被束缚的感觉。

2018年，我们开启了全面自研，先是 kindEditor 的作者隆昊老师的加盟, 语雀的文档编辑器开始全面自研，上线后，性能上有了明显的提升，而且后期的研发和维护效率非常高。用户提的很多问题我们都能第一时间响应，快速解决，这次自研给我们团队带来了很大的信心，我个人也是从文档表格开始进入编辑器领域。

2019年5月我们决定重启表格的研发，抛开 Spreadjs, 全面自研，自研给我们带来的底层的可控性，拓展性，而且从长期看，自研的综合成本效率都很优，选择自研你要慎重的考虑以下几个因素：包括：模型，体验，性能，研发，维护，业务等各种要素。

模型：数据模型是业务发展的根本，也是所有功能实现的基础，掌握数据模型的设计，才有可能更好的满足未来的业务和功能需要，自研可以完全掌控模型的设计。
体验：广义的体验包含很多方面，包括性能，服务，这里主要指狭义的体验：交互体验，自研可以更大程度的按照业务的需要来设计体验，技术实现更加融为一体，而不是在别人的功能上打补丁。
性能：掌握模型就可以在关键性能的地方通过数据结构的优化来解决，架构也可以做针对性的设计
研发：从长期来看，自研的研发成本反而更低
维护：由于对底层掌控性，遇到问题修复起来更快。也不会遇到因为底层的缺陷而无法修复的问题
业务：自研可以根据业务需要来设计模型。更有拓展性。

HOW

用了什么技术
一些技术方案选型的案例

用了什么技术

首先是表格的前端架构图，这是一个非常经典的 MVC 架构，Model 层处理数据，View 层有渲染部分以及工具栏和面板等 UI 部分，渲染部分采用原生的 Canvas 进行绘制，UI 层用了 React,组件库是anTd,图表用了antv，UI 层的事件收敛到 control层，handler去处理事件的参数以及准入规则，然后就交给 command 去执行数据操作，command里会有一个history对象去维护一条条命令，包含执行这条命令的参数以及执行中需要携带的快照数据，方便撤销并通过 websocket 协同服务将命令同步到其他用户端，架构很简单，在选择技术方案上，语雀一直追求实用与简单。

同构还是异构

我想分享的第一个选型是在设计模型时需要考虑的问题，关于产品的选型，也就是前面大家听到的，同构表还是异构表

同构表：每一列数据具备相同的数据结构，比如文本，日期时间，这些在列头定义，一旦定义好，整列的数据都会按这个数据结构来处理，所以他的数据格式属性只需要定义在列头即可
异构表：每一个单元格都可以设置自己的数据格式，整个表格更像一个行列布局的画布，每个单元格可以设置公式，会更加灵活。

可以看出，他们各自有自己的优势和劣势，在数据处理上的实现差异也特别大。

该如何选择，我们最终还是去看用户的需求，会发现两类非常经典的场景，一种是信息结构化，一种是数据处理，这两种场景都非常重要

数据处理不用多说了，肯定要满足。那信息结构化是什么，就是利用表格天然的行列布局，让信息布局更合理，更容易理解。而信息结构化本身也是前面我们提到的，是知识形成过程中重要的环节，有时候结构化布局也是知识的展现形态的一部分。有些信息必须通过表格才能更好的展现，比如元素周期表，而我们知道同构表是没法做合并单元格的，在信息布局能力上存在较大的缺陷，所以我们最终选择了异构表。

多人协同编辑

多人实时协同一直是编辑领域最大的难题，表格编辑也同样会遇到，而且会更加复杂，我们先从多人协同的模型说起：

两个人同时基于一条基线开始编辑，当这两条指令O1,O2,传递到对方那里的时候，要进行变换(OT)，这里是最细颗粒的OP，而通常对于表格操作，比如移动行列，可能会有上千条OP, 如果刚好另外一个用户也做了类似的批量操作，那么瞬间产生的大量OP传递到服务端，服务端需要花费很长时间来做OP转换，这就是导致响应延迟，那么用户会进一步产生OP，造成更多的计算和延迟，形成拥塞。

对于表格的操作，我们可以看这张图：

一个大的数据对象，执行一条command, 产生数条op, 如果同步op对性能有太大的挑战，是否可以直接同步command？我们可以对比看两种模型的差异性：

通过对比两种方案：

我们最终选择了基于 command 来做数据同步，每一条 command 会携带这条命令需要的参数值，传递到其他端，服务端不需要做操作变换，客户端收到 command 后会直接运行，整个过程非常快，通常一条指令从发出到接收到指令可以在100ms以内甚至更快完成，我认为快速将指令同步到各端，是减少冲突的最好办法。

我们知道，通常单元格编辑的指令并不会存在冲突，只有在做行列位置变换或者增减行列时才有可能出现冲突，那么我们需要考虑的问题是：在 100ms 以内同时操作行列的概率有多大，从实际场景来看，这个概率非常小。我们再配合一些冲突后禁止撤销等策略来防止数据的混乱。最终我们采用了一个权衡的方案，同步 Command。从使用效果看，已经能够满足大多数的协同场景。

单元格数量上限

做电子表格过程中会遇到很多极限边界，比如最大的可计算的数，日期的可识别范围等，接下来我们说说表格最大能支持多少单元格数量。

我们首先看看几个有明确限制的竞品，Google明确支持500w单元格，超过就会报警。飞书是50w，腾讯文档是25w。Google是将数据存储在服务端，运算也在服务端，所以其实理论上可以支持更大的数量，所以看上去只是单元格数量上限的差异，却引来一个很重要的架构选型：数据运算在客户端还是服务端。但其实选择起来也不难，还是要回归业务本身，在线电子表格的大多数场景都不会有那么大的数据量，再基于两个考虑点：

充分利用客户端计算资源
保持架构简单

我们选择客户端计算，就是将数据一次性加载到客户端，在用户的浏览器中进行计算，那么这种模式下我们能支持到的最大单元格数量是多少呢？

我们做一个这样的计算，以最小的存储单元格，存储一个十位数的数值，这里只考虑存储值，如果再加上格式，样式，一个单元格大概需要20～200个字符，为了做本地的临时存储，我们采用了localstorage，上限是5M，（当然，有同学说可以使用 IndexedDB, 还是考虑简单原则，IndexedDB的异步模型会使整个编程模型变复杂，能不用复杂的方案，我们尽量不用），利用 localstorage，可以支持的单元格数量上限是25w（10000行25列）。