金泉网 网站建设,中国发展在线网站官网,wordpress 空间安装,asp图片网站源码导读#xff1a;本文主要阐述了 Docs 在线表格为打造极致渲染性能所做的关键优化和过程思考#xff0c;作为首个在在线电子表格领域自研基于WebGL渲染引擎的「吃螃蟹」者#xff0c;整个过程面临诸多不确定性与挑战#xff0c;Kola2d 的整体设计在此期间也经历了几轮推倒重…导读本文主要阐述了 Docs 在线表格为打造极致渲染性能所做的关键优化和过程思考作为首个在在线电子表格领域自研基于WebGL渲染引擎的「吃螃蟹」者整个过程面临诸多不确定性与挑战Kola2d 的整体设计在此期间也经历了几轮推倒重来最终的落地方案经过了多番探索与实践希望给到对WebGL渲染引擎及高性能表格感兴趣的同学一些参考。
一、背景
Docs 电子表格是一款快手效率工程出品的自研协同办公产品在快手内部被广泛使用 这类在线表格通常对性能有极高要求需要面临以下挑战 多人实时协作在线电子表格通常支持多用户同时编辑这意味着系统必须能够快速处理多个用户的操作并实时更新界面确保所有用户看到的数据是一致的。 海量数据团队有大量数据存储在在线表格上在线表格需要能够高效地加载、渲染和操作这些数据。例如进行复杂的计算、排序和筛选等操作时性能要求就更高。 复杂功能现代在线表格通常集成了类 Excel 丰富的功能如公式计算、图表生成、权限管理等。这些功能对系统性能提出了更高的要求因为它们需要实时计算和渲染。
为提高 Docs 在线表格渲染性能在前期我们已经做过很多努力和尝试其核心渲染引擎也由最初的基于 DOM 的渲染变更为了 Canvas 2D 渲染这在一定程度上提高了 Docs 在线表格的渲染性能但随着用户数据的增长和使用场景的扩充我们依旧收到不少用户反馈 Docs 在线表格卡顿特别是大表格、多人协同场景。
为彻底解决 Docs 在线表格的渲染卡顿问题追求极致的渲染性能使电子表格可以适配更多数字作业场景我们对在线表格进行了深度改造并自主研发了 WebGL 渲染引擎 Kola2d最终使得 Docs 在线表格能以 50FPS 的帧率渲染拥有百万单元格的超大表格。为打造下一代高性能电子表格配置了「核动力」。
当前在线表格通常采用 DOM 或 Canvas2D 进行渲染但 DOM 渲染已基本被淘汰。Kola2d 渲染引擎创新性地引入了 WebGL这在在线表格渲染领域尚属首创并在此基础上设计了多种性能提升策略。本文将深入探讨 Docs 在线表格的内部揭示 Kola2d 在提升渲染性能方面的关键策略和技术实现。
二、为什么是WebGL
Canvas 2d 有自己的性能瓶颈在大量级数据渲染上很显吃力。经过调研我们将目光聚焦到另一种方案WebGL。WebGL 在渲染大量级数据的优势这主要体现在以下方面 硬件加速WebGL 是基于 OpenGL ES 的它可以直接利用 GPU 的强大计算能力进行渲染。因此它能够处理更复杂的图形和更高效的图形渲染而 Canvas 2D 则主要依赖于 CPU 渲染性能相对较低。 并行处理WebGL 可以利用 GPU 的并行处理能力能够同时处理大量的顶点和片元这对于需要大量图形计算的应用如游戏、数据可视化等非常重要。Canvas 2D 则通常是顺序处理效率较低。
在前期做也对 WebGL 渲染做了可行性测试结果显示 WebGL 渲染性能显著强于 Canvas 2d 10万单元格 100万单元格 WebGL 60FPS 60FPS Canvas2d 10FPS 卡死
通过分析市面上的 WebGL 框架优缺点我们最终决定自研 WebGL 渲染引擎 Kola2d。 三、Kola2d
Kola2d 职责范围
在设计 Kola2d 渲染器之前我们对 Docs 在线表格的整体业务做了下梳理将 Docs 在线表格分为了两层这使得 Docs 在线表格有清晰的职责划分
业务层业务层专注业务封装渲染层渲染层专注渲染渲染层即 Kola2d 业务层数据转换 业务层和渲染层相对隔离业务层的数据需要做转换然后提交给 Kola2d。我们将业务层提交的数据起了一个名字显示对象树。当然业务层不仅仅显示对象的生产者同时它需要有一个合理的结构方便后续进行维护和扩展。
业务层结构
业务层被进一步细分秉持单一数据流原则更好控制内容的变更 基础数据表格基础数据 数据模型将基础数据做转换后会生成数据模型 视图模型数据模型的变更会触发视图模型的变更 显示对象树视图模型变更后会触发更新显示对象树它就是业务层的最终产出后面会提供给 Kola2d 消
显示对象树结构
显示对象树即表格内容的抽象呈现表格内容大体可分为视图、装饰、插件这几类每个类下面又有具体的细分 将视图、装饰、插件做抽象得到三大业务类将业务类做组装并形成显示对象树的结构 Grid 即显示对象树Grid 主要由视图层和装饰层组成 视图层有多个视图每个视图内可以嵌入多个插件 装饰层有多个装饰每个装饰可以嵌入多个插件
Grid 目前只是一个基础的骨架我们还需要给里面填充内容Grid 的内容分为两种 内置内容Grid 初始化时就会自动订阅视图模型然后生成内容 嵌入内容由外部通过插件的形式嵌入进 Grid 里
看到这里你也许会疑惑难道我们可以随意自定义显示对象树吗答案当然是否定的
Kola2d 内部提供以下基础的显示对象几乎表格页面的所有内容都可以用这些对象表示 业务层生成的显示对象要么继承自这些对象要么直接使用这些对象所以它才能被 Kola2d 识别并最终渲染出来。
Kola2d高效渲染的原理
Kola2d 的核心目标是能以 50 FPS 的标准渲染百万单元格级的大表格同时满足其多人协同场景下的流畅性。 处理百万单元格
我们前面做的性能测试显示 WebGL 底层是完全能扛住 100 万单元格的压力的但我们的开销并不仅仅是在 GPU 上 CPU 也要处理大量的前置工作比如排版、生成各种数据模型等这往往会耗费很大的开销让页面长时间处于无响应状态。前面提到 Kola2d 的角色仅仅是渲染它并不负责排版这些前置操作想要真正实现渲染 100 万单元格需要业务层和渲染层共同协作。
其实不管是大表格还是多人协同场景下的表格用户的关注点都在视图区内如果视图区内的内容能够快速的呈现出来那么对于用户来说页面就是流畅的。那么可以换一种思路虽然要渲染 100 万单元格但我们是否只用在页面真正需要呈现这些内容时才去做对应的前置操作
答案是可以的只要业务层能确定目前视图区应该展示什么内容那么就可以只准备视图区内的数据。但是想要确定视图区应该展示什么内容就必须要先对就要对内容做排版然后才能确哪些内容应该展示到视图区。Kola2d 虽然不直接负责排版但是它对外提供了一个 FormattedText 的文字排版包而文字排版又是页面排版最复杂的部分它可以轻松实现文字的度量和排版它内部会缓存排版结果遇到样式相同的文字时会直接使用缓存结果进而加快排版速度 业务层可以直接调用 FormattedText 做文字排版有了这个排版包的协助业务层就可以轻松计算视图区排版结果。
但是视图区外的数据会影响视图区内数据的相对位置比如现在我在第 100 行的位置时前面的数据会影响我后面的相对位置 因此业务层启用了一个新的策略视图区外的行列使用默认宽高当它需要展示到视图区时再区排版它的真实宽高然后将排版结果缓存。
我们最终吐给 Kola2d 的数据是视图区内的单元格。当然我们也可以将 100 万单元格数据吐给 Kola2dKola2d 内部也有对应的优化策略它内部也提供了一套剔除机制会将不在视图区的单元格剔除仅渲染视图区部分 但我们并不鼓励给 Kola2d 吐太多的数据Kola2d 内部也有 CPU 计算光是循环 100 万条数据CPU 耗时就能达到 10ms 左右我们希望尽量减少 CPU 的消耗这样 CPU 可以做更多其它的事情 处理多人协同
多人协同场景下的表格内容变更会非常频繁假设有几百个人同时编辑表格那么页面将疲于奔命去处理这些变更所以我们需要尽可能的去减少单次变更所需要的时间。
页面上用户看到的内容就是一个个像素页面的变更到最终变成为对应的像素数据有更专业的称呼光栅。
对于渲染引擎来说光栅的开销是非常大的就拿 Chrome 来说所谓的硬件加速就是把光栅的操作交给 GPU 来执行 尽管有 GPU 做光栅但这还远远不够Chrome 做了大量工作来减少每次光栅的数量 由 main 线程对对页面的绘制做分层生成多层的绘制指令 由 impl 线程做合成分片等对光栅区域做优先级区分优先光栅高优的区域同时光栅后结果是会做缓存的避免重复光栅 如果页面变动可以根据前面已经生成的结果做计算然后仅光栅需要光栅的部分
从 Chrome 得到启发kola2d 的核心架构思路即 尽量减少光栅 尽量使用 GPU 做光栅 尽量利用光栅缓存
到这里或许你会有一个疑问既然借鉴浏览器内部设计那为什么不直接用 DOM
其实最初表格就是直接用 DOM 渲染的小表格还好一旦遇到数万行甚至数十万行表格时浏览器就显得吃力同时多人协同时频繁变更 DOM 使得页面卡顿非常严重。因此后期做了一版优化将 DOM 改 Canvas2d 渲染。
但这并不代表浏览器不行而是在我们表格的这个场景下浏览器比较吃力而已。Kola2d 吸收了 Chrome 内部的一些优秀的设计理念引入了诸如分片、光栅结果缓存等概念同时结合表格自身的使用场景设计了诸如剔除、视图区光栅等功能。
减少光栅的策略
对于减少光栅我们不得不提到 Chrome 的分片Chrome 分片主要用于以下 减少光栅页面做分片后仅对有内容变更的分片需要做光栅 控制内存分片可以帮助控制内存对于不在视图区的分片或者离视图区比较远的分片如果内存告急的时候可以被释放掉
Kola2d 的分片思想也是借鉴了 Chrome但 Kola2d 的分片跟 Chrome 略有不同Chrome 是排版完整个页面后再以页面维度做的分片而 Kola2d 仅以单元格维度做的分片 Kola2d为什么以单元格维度做分片 表格的最小变更范围为一个单元格以单元格维度做分片就能保证假如一个单元格内容发生变更那么就仅仅重新光栅化这一个单元格。
这在多人协同场景下十分有利我们可以最大化的减少需要重新光栅的分片的数量提高渲染性能。
同时由于业务层只关注视图区就算多人协同修改了视图区外的数据这也不会影响到视图区内进一步减少了额外的损耗。
有了分片我们可以仅光栅内容变更的单元格其它单元格直接用缓存的光栅数据就可以了。
但假设协同人数实在太多那么单位时间要处理的变更也就越多就算我们把性能做得再极致那么还是会出现卡顿。因此来自协同者的变更我们并不会立马处理而是把它放入一个队列中然后定时到消息队列里取一批消息做处理 光栅的过程
当某个分片内容发生了变更我们需要对它重新做光栅Kola2d 的位图系统应运而生。位图系统会把分片转换成对应的绘制指令并最终转换成像素数据存到资源管理器。 WebGL 只能绘制点、线、三角形这意味着页面的所有内容都需要做对应的转换。对于图形这种方式还好但是对于文字来说这种方式就变得比较吃力比如下面的字体需要解析其路径信息然后绘制路径并描边 Chrome GPU 加速的本质就是把图形绘制操作交给在 GPU 进程的 Skia 来绘制那么也引发了一个思考我们是否也可以调用 GPU 上的 Skia 来做图形和文字绘制
其实目前很多主流浏览器都支持对 Canvas 2d 做硬件加速 Chrome 13 Firefox 4 Internet Explorer 9 Opera 11 Safari 5
所以我们可以使用 Canvas 2d 当作一个媒介前面所说的绘制指令最终都会变成 canvas 绘制指令最终由底层的 GPU 将绘制指令转换成像素然后把 Canvas 2d 当作纹理上传给 GPU。
Canvas 2d 不支持 GPU 光栅怎么办
浏览器并不一定会对 Canvas 2d 做硬件加速这种情况下我们仍然可以使用 Canvas 2d 做光栅由于我们实现了分片以及光栅化结果缓存即使 Canvas 2d 不支持 GPU 加速我们也可以借由缓存来极大减少页面需要光栅化的数量从而提升性能。
光栅管理
前面提到光栅缓存我们为Kola2d 设计了一个专门的类用于管理这些光栅后的数据即资源管理器它主要提供以下功能 资源代表每个分片需要的内存已经内存对应的像素数据。
位图管理器在对分片做光栅化的时候会先计算分片需要多少资源内存然后向资源管理器做申请对应的大小当光栅化完毕后就会将像素数据写入到对应的内存地址。资源管理器会对它名下的所有资源做统一的管理本小节不会对资源管理器 API 做讲解反之会重点介绍它内部的管理功能。
资源优先级管理
资源管理器的空间是有限的而众所周知像素占用的内存又比较高我们需要及时清理那些不需要的资源。Chrome 为了实现这一点将分片加了优先级 越靠近视图区那么分片所属的资源优先级就会越高。
Kola2d 资源管理器不会对资源做这么细力度的控制而是在每一次 requestAnimation 周期里如果执行了渲染那么 updateId 就会更新这样的计算机制可以保证离视图区越近那么其优先级就越高对于那些非视图区的资源会根据优先级及时做释放 资源内存管理
资源管理器的内存使用率需要保持在一个合理的水平内存不够就要及时清理内存。由于资源的优先级是被计算好的当内存告急时很容易就知道那些资源需要被清理。
一个分片会占据一个资源内存处于 Viewport 里的显示对象所拥有的资源内存 updateId 值最高离 Viewport 越远 udpateId 越低在每一个渲染周期里会清理这些 updateId 低的资源 资源权限管理
Kola2d 资源管理器对资源的更新有严格的限制比如你申请了 16 X 16 的像素区域的资源时你写入像素的范围就不能超过这个大小这是为了防止误操作到其它资源。
因此每一次像素写入操作都必须先申请写入权限操作完毕后关闭权限关键代码如下 这样做还有另外一个好处即可以追踪哪些资源被更新了然后仅将变更的资源上传到 GPU。
页面合成
通过前面的处理现在分片有了分片的光栅化数据也有了我们需要把这些光栅化的数据做组装然后将它提交给 GPU 最终显示到页面上Kola2d 的着色器就专门负责这项职能 每个单元格分片都有一个对应的 Draw QuadDraw Quad 包含了单元格分片的屏幕位置以及它对应的像素位图的内置地址这些 Draw Quad 会被放进一个 Array Buffer 中然后提交给 GPU最终展示给用户。
得益于 WebGL我们可以直接跟 GPU 打交道这块儿的耗时几乎可以忽略不计。
四、额外优化
通过上文我们对 Kola2d 是如何实现高效渲染有了初步的认知。为了进一步提升渲染性能我们还做了很多额外的工作结合实际业务场景精细地设计各种策略其基本原则是尽可能的最小化更新任务每次只变动真正需要重新的部分。
对象复用
由于我们只会渲染视图区域内的随时有可能出现一部分单元格需要新增一部分单元格需要删除比如在滚动或者增删行列的场景下。创建单元格和销毁单元格都有一定开销为此删除的单元格会被回收到回收池里下次需要创建单元格时会优先复用回收池里的单元格。 对象合并
样式相同的对象虽然形状不一样但是可以做合并处理减少显示对象树的体积同时减少排版时间。 排版优化
在整个渲染过程中除了真正的绘制任务还有很大一部分耗时在排版阶段 排版的主要任务是根据行列信息滚动位置等确定单元格在屏幕中的位置。由于单元格是有内容的其展示的真实行高与模型行高可能不一致我们需要对单元格内部的文字进行排版才能得到最终的高度。这个过程非常耗时为此我们也采用了一系列的手段来优化排版性能。
精准标脏
导致表格重新渲染的原因很多频率也很高然而并非所有操作都需要触发排版也可能只需要局部排版而非全局排版。考虑到排版是一个耗时较长的任务。我们借鉴浏览器的实现结合表格实际业务场景设计了一套标脏更新机制在不同场景下进行精准标脏。每次绘制前会检查脏区以避免任何不必要的更新。 同样标脏也是一种惰性更新策略只有真正需要使用数据的时候才会执行任务避免了大范围频繁操作下贪婪更新可能会造成的性能影响。
异步分片
一个在线表格可能有数十万乃至百万单元格为了保证性能我们默认只会排版并绘制视野范围内的单元格。然而在滚动等场景下会有大量新的单元格不断出现在视野中需要执行排版任务会延长页面真正显示的时间造成卡顿掉帧。
针对这一问题我们借鉴经典的异步分片的思想将排版任务拆分到行利用浏览器运行的空闲时间异步执行并缓存排版计算过程中的关键结果排版后的内容会取消标脏在后续滚动过程中无需再次执行排版任务。 文本排版优化
最后让我们来到文本排版任务本身看看有没有优化的空间
文本排版主要发生在自动换行场景下其算法可概述为 根据 unicode 断行算法找到断行可能发生的位置 逐个检查断行位置计算文本累积的宽度如果可用空间不够就开始新的一行。 该过程的主要耗时在文本测量阶段在非 dom 场景下我们依赖 ctx.measureText 方法测量文本宽度。由于字符在不同组合下的宽度是不一致的不能单独将宽度相加必须以组合的形式进行测量。目前比较普遍的优化方案是采用二分法如 Konva Text 但二分过程中会存在重复测量情况且测量耗时是跟文本长度成正比的在文本较长时表现也不够好。这里我们借鉴了 Chrome 浏览器的实现结合表格实际场景进行了如下的优化 根据可能发生断行的位置预先对文本进行分词缓存分词以及单词宽度测量的结果以便在后续排版任务中复用。 当单词仅含有单个中文字符时是等宽的可以使用预设标准字符的测量结果也无需重复测量。 由此我们大大减少了文本排版耗时经评测相较于 Knova Kola2d 文本排版在长文本及中文场景下有明显的性能优势。 最后我们会对单元格变更原因也进行归类力求做到最小化精准排版 当排版无关属性如单元格背景色发生变更时不会触发文本排版任务。 当排版相关属性如单元格layout发生变更时分词和测量结果均从缓存中读取仅重新进行排版计算。 当单元格内容发生变更时重新进行分词、测量和排版复用部分缓存的测量结果。 本文作者快手效率工程部
