可视化布局模块开发分享

3,399 阅读6分钟

在历经两年多的迭代后,Odeon大数据平台在底层能力建设上已经相当丰满。最近大半年来在数据可视化方面也投入了很大的精力,目前自助 BI 产品也已经成功上线并稳定运行了一段时间,今天小剧就来分享下我们在数据可视化中的一些经验。

今天的分享主要围绕 可视化布局模块 的一些工作,布局模块是承载可视化图表的一块画布,是用户用来组织业务逻辑的重要手段之一。先来体验下 在线demo 或者看下面的效果图:

图一:可视化布局模块效果图

效果图

一、为什么要开发可视化布局组件 ?

其实不管是在数据可视化,还是在一些自助发布的运营平台,自助布局一直是一个难以跳过的问题。在项目开始之初这个问题也同样在困扰着我们,是我们开发几套预置模版让用户挑选,还是开发一套让用户可拖拽配置的布局模块?

前者实现上非常简单,也很容易设计的非常精美,但是缺少了很多灵活性,很容易千篇一律。后者用户在使用上自由度非常高,可以拖拽出更符合自己预期的界面,但是开发成本相对较高,并且想要达到稳定、易用、高辅助性却比较难。

综合考虑上面的这些问题,我们对制定的几套方案均不满意,最终还是决定自己动手实现一个可以辅助用户进行拖拽布局的组件。

二、我们是怎么做的 ?

经过设计,我们对交互模型做了梳理,设计了卡片、图表两层结构。在此基础上对数据模型做了整体设计,结合上面效果图和 在线 demo 可以更加容易理解下面的划分。

首先是局部范围内单例的 Map 类,用来描述整个 dashboard 布局,以及其他数据存储。

其次是 Widget 类,用来定义卡片信息,包含卡片的尺寸、位置信息,以及更详细的卡片标题、卡片类型、脚注、图表ID 等信息。

最后是 Chart 类,用来定义图表信息。为了布局与图表模型分离,这里的图表信息放置较少,仅仅存储了必要的 id 等字段,图表本身实现由外部 slot 插槽来完成。

图二:数据模型

数据模型

三、交互如何处理 ?

数据模型构建好了,接下来就是着手设计拖拽交互了。

出于响应式考虑,同时为了减少用户操作的随意性,在布局设计上我们放弃了像素单位,而是针对节点尺寸设计了虚拟的 12 栅格切分,在初始化、缩放、移动时都严格参照此栅格布局。

为了保障用户拖拽体验的顺畅,使布局保持整齐,我们在遵循卡片自动调整逻辑的基础上,设计了卡片的重绘流程,这一点在后面会有详细的介绍。

为了提供更好的拖拽体验,我们额外设计了虚拟卡片用来辅助用户进行布局,用户随时可以预览松开鼠标后卡片处在的位置及大小,效果如下图阴影处所示。

图三:拖拽预览效果图

辅助布局

四、有哪些困难点 ?

有上面的数据模型设计,其实一大半的困难已经被解决了。难点主要体现在辅助布局过程中易用性上的一些处理,总结下来有以下几点。

1、碰撞检测如何处理

其实单纯的碰撞检测是很容易解决的,毕竟所有卡片只是二维矩形而已,这一点并不是难事,困难的是碰撞后被接触的卡片需要腾出位置进行让位,我们需要找到所有被碰撞到的卡片,以及受此卡片影响的所有后续卡片,这是一个较为困难的点。

图四:碰撞检测布局重绘过程

拖拽碰撞检测

2、自动吸顶效果如何实现

在设计布局的过程中,用户可能会把卡片拖得七零八落,而且在上面提到的碰撞检测的处理过程中,也会导致相邻卡片受影响。初期的交互在体验后发现,拖拽过程中用户需要花很长时间来重新整理布局,因此为了保证布局排列紧密,必须要有一个方法,能够将所有处于悬空状态的卡片依序吸顶处理。

图五:自动吸顶布局重绘过程

拖拽碰撞检测

五、如何处理这两个问题 ?

上面提到的这两个困难点,在移动、缩放这两个拖拽交互中都存在,并且逻辑上是一致的,因此在拖拽布局过程中我们抽象出了一套重绘逻辑,按顺序整理如下:

  • 1、碰撞检测,找出拖拽过程中与当前卡片相重叠的卡片,可能会多个卡片与之接触;
  • 2、圈选影响范围,也就是图四左侧所示,递归找到受碰撞的卡片影响的所有卡片,去重处理;
  • 3、临时让位,如图四右侧所示,所有将受影响的卡片做相同幅度向下移位处理,用来容纳被拖拽的卡片;
  • 4、自动吸顶,图五部分所示,需要自动处理所有卡片,逻辑是卡片上方如有可用空间,则自动吸附上去。

因为拖拽需要实时预览效果,上面这四步重绘逻辑会被频繁触发。为了避免在布局过程中反复污染真实的位置数据,我们为卡片位置我们引入了 previewOffset 字段,用来存放预览效果时的垂直偏移量。

可能会有同学会产生一个疑问:这里是业务上的重绘逻辑,如此高密度的修改数据会不会在性能上表现比较差 ?

其实这个问题的解决得益于 Widget 类 的数据模型设计,在从碰撞检测到自动吸顶等一系列处理过程中,被频繁计算、修改的仅仅为相对单位的 position 对象,而界面布局使用的是绝对单位的 screenPosition 对象。数据与表现是分离的,仅当一个重绘流程结束之后才去触发 screenPosition 的更新,如此设计使得界面更新节奏更可控,界面更稳定,避免了视觉上卡片位置的闪烁的问题。

按照此重绘逻辑,既避免了 dom 层冗余的重绘开销,提高了整体性能,又在界面布局的易用性上得到大大提升,操作体验上也更加稳定、流畅。


本文主要从可视化布局模块的交互逻辑的设计上展开,并未涉及到具体代码实现,作为 Odeon 大数据平台在可视化布局模块的一些思路,相信通过本文您已经有了初步的了解。

如果您对文中提到的碰撞检测、让位处理、吸顶效果以及辅助布局中等具体实现细节感兴趣,欢迎私下进行探讨,可能的话我会另开一篇文章详细展开来聊。


相关链接