石墨文档的云端表格实时压缩策略

多人实时协作是石墨文档吸引人的一大特性之一。使用石墨文档，你可以和同事、朋友同时编写一篇文档或表格，每个人的修改都会实时的同步给其他人。你可以看到每个人光标的跳动，每一个键入的文字。一篇篇运营文案、一份份产品头脑风暴，伴着一杯杯茶与咖啡，就这样在石墨文档上诞生了。

美好的事物背后总是充满艰辛。在技术实现上，多人实时编写会造成许多的冲突，拿表格来说，当用户 Bob 在 B2 单元格编写内容的时候，他的朋友 Jeff 在 B 列的前面又插入了一列，如果两个操作同时发给服务器就会产生冲突。在石墨文档，我们维护了一个数据计算集群通过一套算法计算分析来帮助用户解决冲突。如上面提的例子，最终 Bob 在 B2 单元格编写内容的操作经过服务端的计算会被 transform 成在 C2 单元格的操作发给 Jeff。

为了尽可能地降低多人实时编写的时延，我们付出了非常多的努力来使得这套算法能够在符合语义地解决编写冲突的前提下尽可能地高效。数据统计表明，在石墨文档有将近 90% 的冲突数据计算可以在几毫秒的时间内运算完成。成就这瞬息时间的功臣之一，就是我们这套算法的一个基本原则：运算耗时仅和操作本身相关，与文档（或表格）原始内容大小无关，换句话来讲，就是算法的时间复杂度不能和原始内容大小正相关。

这个基本原则来源于我们对用户体验的直觉感知：随着用户在一篇文档或表格中不断地编写，数据同步的速度不应该随着内容的增多而不断变慢，否则使用者对写作体验的好感会逐渐降低，最终导致用户慢慢倾向于尽量少地在石墨文档上编写内容。

去年 12 月，石墨文档正式对外发布了表格公测版。在上线了一段时间后，表格的性能问题逐渐引起我们的重视。当在表格选择一个范围后，设置表格属性（如对齐方式、字号等）后，程序会为范围内的每个单元格创建一个数据对象来记录这些数据。如果选择的范围很大，数据对象就会变得非常多，影响了网络传输和算法计算的速度。

为了解决这个问题，我们决定引入 Range 的概念来将这些拥有同样属性的邻近单元格通过一个范围矩形来表示。如为 B2-C4 单元格设置了文本右对齐格式，之前的表示方法为：

{
    
  B2: {
     attributes: