数据可视化之美

简介

本文是《数据可视化之美》的阅读笔记，解构并重组了其原本的组织形式，剔除了部分具体的可视化案例（如词云、纽约地铁、美国民航以及本书后期的大量具体案例）。目的是从中分析和总结一些可视化设计的原则和方法论，以指导未来的可视化设计和开发。

《数据可视化之美》主要讲述了可视化的一些设计准则，如何通过数据可视化来讲述故事，以及一个可视化项目的执行流程，并通过具体案例了解可视化探索的过程和一些有趣的发现。

其中，大多数信息可视化的原始驱动力在于对数据的探索和描述，推动其发展的主要是一些出版机构（如《纽约时报》、《连线》）。可视分析的推动者多为非营利组织或学术组织，而在一些科学可视化和可视化软件中则可以看到商业组织的身影。

基于Dom的无限画布实现方案

针对无限画布这个场景，在业界figma的画布交互体验是公认的比较好的。不过figma采用的是canvas方案。本文介绍基于Dom的无限画布实现方案。

主体结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<!-- 画布容器 -->
<InfiniteCanvas>
  <!-- 渲染器 -->
  <Renders>
    <!-- 布局器 在合适的位置渲染元素渲染器 -->
    <Layouter>
      <!-- 元素渲染器 -->
    	<ItemRender/>
    </Layouter>
  </Renders>
  <!-- 设计器 -->
  <Designer>
    <!-- 已选中元素的指示器 -->
    <SelectedBox/>
    <!-- 布局提示线 -->
    <LayoutHintLine/>
    <!-- 右键菜单 -->
    <ContentMenu/>
    <!-- 刷选框 -->
    <SelectBox/>
    <!-- 拖拽添加元素时的蒙板 -->
    <DragOverMask/>
  <Designer/>
  <!-- 控制器 -->
  <Controller/>
</InfiniteCanvas>

核心属性

1
2
3
4
5
6
7
8
9
10
11

// 画布的移动属性 
canvasTransform: {
  // 缩放比例
  scale: 1,
  // 画布由于平移引起的 偏移量
  translateX: 0,
  translateY: 0,
  // 画布由于缩放引起的 偏移量
  canvasOffsetX: 0,
  canvasOffsetY: 0,
}

完全基于云服务的Web应用开发过程

这里介绍一种完全基于云服务的Web应用开发过程，各云服务基本都包含免费方案。对于一些小型的非商业化Web应用完全可以基于云服务0成本开发、部署、落地。

过程 & 工具

Demo	开发	源码管理	测试	部署	数据存储 对象存储	CDN

Web Components 现状及发展趋势

笔者之前参与过两个低代码项目，大屏编辑器，图表编辑器。其表现形式均为通过拖拽和配置表单来编排物料，进而生成交付产物。其中物料的丰富程度、可复用程度又是重中之重。如果物料本身依赖某一种框架，比如React或Vue在大时间跨度下必然会产生迁移成本。届时面对海量的待升级的基础物料，如何迁移就会变成一个非常麻烦的问题。

Web Components提出了一种无需任何库或框架即可运行的组件化方案。用于将物料解耦具体前端框架十分合适。本文尝试从Web Components的发展历史、现状、优缺、趋势等方面尝试判断现在是否合适将已有的物料迁移至Web Components。

NodeJs性能分析

这里提出一种面向NodeJs的基于Chrome Dev Tools的性能分析方法。

核心思路

• 基于console.profile记录性能描述信息，输出.cpuprofile文件。
• 基于Inspector记录内存占用信息， 输出.heapsnapshot文件。
• 基于Chrome读取.cpuprofile和.heapsnapshot文件分析性能问题。

效果

JS执行情况

内存占用情况

由SVG引起的大屏性能问题排查及优化方案

背景

某大屏项目主视觉在增加其他辅助图表之后帧率下降较为明显，本文尝试分析导致帧率下降的原因以及可能的优化空间。

原始

在交互触发时也基本可以稳定60帧左右。

新增图表等其他页面元素后

普遍仅能维持在30帧左右

背景

针对在如何在图表编辑器场景下快速索引图元所对应的方案，我们得到了ECharts图元拾取方案。本文介绍两种方案去提示用户当前拾取到的图元。

背景

针对在如何在图表编辑器场景下快速索引图元所对应的方案，我们得到了ECharts图元拾取方案。但图表场景通常具有很多【线条】类型的图元，这些图元宽度普遍不高，通常为【1-2】个像素宽度。这就给通过交互的方式来拾取图元造成了一定的困扰，不容易选取、很容易移出热区。本文探究一种图表元素拾取扩大热区范围方案。

算法的复杂度通常会使用BigO来表述，但会相对比较抽象，本文会结合算法实例以及图像相对具象的去表述时间复杂度这个概念。

BigO主要有以下几种表达式来描述时间复杂度：

• O(1)：常量时间
• O(n)：线性时间
• O(log n)：对数时间
• O(n^2)：二次方时间
• O(2^n)：指数时间
• O(n!)：阶乘时间

每种时间复杂度有所不同，下面我们一起来详细了解这几种时间复杂度。

背景

降低图表开发成本的几大节点

1. D3.js的诞生

D3的核心概念：Data-Driven Documents，以数据去驱动视图的渲染，使开发者摆脱了繁琐的视图渲染细节。不再需要手动增删改具体的svg节点，以及其内置的优秀布局算法。极大的降低了图表开发的门槛(体现在布局算法层面)，以及提高图表的开发效率(不再需要去维护具体视图)。

2. ECharts

ECharts通过配置式的方式去创建图表并搭配完善的文档，先天性的就会比D3编码式的图表绘制方式门槛要低、效率要高。并且ECharts将图表的开发逻辑做了一个倒置，从由图元组合形成图表(绘制点线面、图例、提示框来组合成一个完善的图表)，改为了从图表的可配置项中选择一些合适的搭配（选择显示X轴、Y轴图例等）。进一步降低了图表开发的心智负担同时规范了图表样式。

3. 各类图表编辑器的出现

DataV，easyv，chartcube等图表编辑器的出现，将图表的配置项进一步抽象成了一些可见、可读的、GUI化的配置表单。用户通过拖拉拽以及点点点的方式来生成图表。这里将文档阅读、以及编码测试两个流程优化了出去。进一步降低了图表开发的门槛与成本。

4. AI生成

近年来随着AIGC的大规模应用，以Chat-GPT为代表的AI通过其巨大的语料库以及优秀的语言模型，基本已经做到了的通过自然语言来生成绘制图表的代码，将图表的生产方式从UI交互提升到了自然语言描述。但由于AI的不稳定性，由AI生成的图表普遍不能直接应用于生产，仍然需要一定量的微调，这就又对开发者的编程技巧有了一定的要求。