2013 年 7 月初,百度商业前端数据可视化团队发布了开源 JavaScript 图表库 ECharts 的 1.1.0 版本,引起了广泛关注。 ECharts 基于 HTML5 Canvas,是一个纯 Javascript 图表库,提供直观,生动,可交互,可个性化定制的数据可视化图表。
经 ECharts 开发者介绍,InfoQ 编辑整理了一些有关这个图表库的相关信息,分享给大家。
ECharts 的目的
ECharts 的开发是为了解决数据可视化的问题。它是一个 web 前端数据可视化的解决方案,面向前端开发人员使用,可以输出具有可交互图形用户界面的数据可视化图表。
数据可视化一路发展过来,从简易图表阶段(缺乏视觉表现力),到注重视觉表现力的信息设计阶缺段(乏对数据的深入理解,往往产生视觉误导),再到今天大家看到的很多冲击力极强的数据可视化作品(如 TED 的无数作品,数据分析与视觉表现力充分结合),这显然不会是终点。数据可视化在国际上正在进入一个新的阶段,深度数据交互,在这个阶段将打破平面的视觉效果,实现了人机互动式的跨平台操作,真正的将数据带入到任何工作场合中,帮助人更好的掌握数据价值。业界领先的 Tableau 就是个很好的例子,或者如初创企业 zoomdata 所做的也能说明这一趋势,而 ECharts 也正朝着这个目标出发。
ECharts 的思路
如维克托 • 迈尔 - 舍恩伯格教授的《大数据时代》所述,大数据时代有几个特点需要人们转变思维或适应变化,其中很重要的一点就是“社会需要放弃它对因果关系的渴求,而仅需关注相关关系”。人们更需要关注“数据是什么”。ECharts 的特性设计正是以此为出发点,呈现数据真实的一面,并且提供了一些直观、易用的交互方式以方便用户对所展现数据进行挖掘、提取、修正或整合,通过系列选择、区域缩放、数值筛选等不同方式让用户可以更加专注于他们所关心的地方,可以有更丰富的呈现方式解读数据。
ECharts 的实现
ECharts 的实现,表面上是 canvas,但 ECharts 内在的技术特征应该是数据驱动和基于消息的耦合剥离。通过底层 canvas 类库 ZRender ,ECharts 代码里几乎可以无视 canvas 的存在。
熟悉 KineticJS、EaselJS 或者 oCanvas 的朋友应该对 canvas 基础库的概念不陌生。ZRender 是一个轻量级的 canvas 类库,MVC 封装,数据驱动,提供类 Dom 事件模型。这个 canvas 类库让开发者写起 canvas 应用时就像写 web 页面一样。此外,css style 的样式属性定义,层叠,MVC 架构(CURD、render & refresh),promise 式的动画接口,也都是如此设计。
ZRender 同样是百度商业前端数据可视化团队的作品,里面也有很多有意思的东西。
虽然说大数据的含义并不是“数据量大”,但大数据强调的考察对象从“随机样本”到“总体”的转变趋势不可避免的带来了需要展现大量数据的需求。这或许是 ECharts 技术选型上为什么是 canvas 而不是 svg 的重要原因,在有限区域内显示尽可能多的数据,ECharts 的大规模散点图充分利用了 canvas 的像素处理能力,这或许已经达到了现有 web 呈现能力的极限,而显示性能跟显示一张图片无异。抛开像素处理能力不说,同样呈现普通的图形,你很难想象浏览器创建 10 万个 svg DOM 会有多么吃力,而用 canvas 渲染 10 万个圆仅需 500ms 左右(chrome)。
在 ECharts 中涉及的一些技术细节:
- 依赖 excanvas 兼容 IE8-。
- 遵循 AMD 模块化标准,图表按需加载。
- 地图由基于 svg 格式的矢量数据生成,底层 ZRender 会转换成 canvas 的路径。
- 旋转、平移、动画的实现,被转成矩阵运算来解决。
- 反复渲染的性能问题,采用了分层刷新和 dirty flag 进行了优化。
- 基于包围盒和纯数学方法解决同时大大优化了图形 hover 判断。
- 图表和控件间采用消息中心进行通信协作。
ECharts 的接口方法很简单,但有一个很庞大的配置项集合。为了让设置合理,牺牲了很多实现成本。ECharts 团队认为,接口设计的合理比起实现成本重要得多。
评论