2018 年 1 月 16 日，百度 efe团队正式发布了旗下知名开源产品 echarts 的最新大版本 4.0，新版本在产品的性能、功能、易用性等各个方面进行了全面提升，标志着百度在可视化领域又一突破性里程碑的到来。
3月 31日，由百度开发者中心主办、极客邦科技承办、百度创新中心赞助的第 77期百度技术沙龙邀请了来自百度高级技术经理祖明、百度资深前端研发工程师宿爽、百度高级前端研发工程师张雯莉、百度高级前端研发工程师王俊婷、百度资深前端研发工程师沈毅和百度高级前端研发工程师李德清六位讲师，从 echarts 的产品特性、技术实现、可视化实践、开源社区建设等四个维度出发，全面介绍如何更好运用 echarts 来让用户洞察数据，为听众带来一场深入了解 echarts的分享盛宴。
1 echarts开源之路
百度高级技术经理祖明做了开场演讲，他首先介绍了百度开源的 echarts项目的发展史，在 2013年 6月 echarts 1.0 发布到 2018年 1月 echarts 4.0 发布的四年时间里，echarts项目累计迭代了 64个版本，github 关注数达到 26,530，受到了来自业界权威的关注和广泛好评。
2013年 6月，echarts 发布 1.0版本；2014年 6月，echarts发布 2.0版本，在 1.0的基础上使性能有 3+倍的提升，增加直角系全图表，支持大规模数据，新增时间轴、仪表盘、漏斗图、异变地图并且支持 svg扩展；随后，团队根据前端技术发展的趋势及用户的需求，对 echarts整体的技术架构进行了极大的重构优化，在 2016年 1月发布了 echarts 3.0，3.0无论在功能上、性能上、包括产品的样式与交互都有着极大的提升。
今年的 1月 16日，echarts 4.0横空出世，八项新特性，让产品更上一个台阶，echarts 4.0 希望打造一款能让更多的人在更多的场景都能享受到数据可视化带来的价值，帮助人们探索世界、了解真实。
echarts 4.0 最大的亮点是带来了 8 项堪称“黑科技”的全新特性：
千万级数据可视化渲染能力
svg + canvas 双引擎
全新旭日图
数据与样式分离
更扁平的配置项
无障碍访问支持
微信小程序支持
powerpoint 插件
echarts的未来
近日，全球著名开源社区 apache基金会宣布“百度开源的 echarts项目全票通过进入 apache孵化器”。这是百度第一个进入国际顶级开源社区的项目，也标志着百度开源正式进入开源发展的快车道。在未来，echarts团队会持续维护，希望有更多的人来加入，为开发者提供更好的体验。
2 echarts 4.0 核心特性解析
echarts的成功和广泛应用，必然离不开其颠覆性的功能设计和技术特征。echarts资深研发工程师宿爽和张雯莉以 echarts 4.0新的技术特征为起点，介绍新版本在大数据渲染、数据集、跨平台、无障碍访问等多个技术特性的使用场景和设计原理。
大数据量渲染
大数据量渲染在本文中指的是千到千万的数据在浏览器中的渲染和交互，echarts4.0在优化这些事情上下了很大的功夫。数据可视化以浏览器作为一个重要的输出方式，但浏览器在性能上有一定的限制。主要为以下几个方面：
程序执行的时长。在浏览器里面，js的执行会阻塞渲染和用户交互的响应。
内存的占用。大数据的运算可能会引起浏览器崩溃，也有可能会因 gc开销过大导致运行不流畅。
网络加载。对于百兆千兆的数据，文件体积有可能数十甚至上百 mb，如果在网络上展示，则不能在数据全部下载完成才开始渲染。
echarts 对这些做了一系列优化，包括：基于场景特点的优化、程序层面的优化、用户感官的优化、加载的优化：
基于场景特点的优化
以图形的简化为例，讲述了 echarts 是如何基于场景特点进行优化。如下图是一个 k线图，每个图形的复杂结构在渲染时会比绘制简单图形需要更长的时间，导致大数据量时的交互卡顿。而当实际缩放到一定程度时，将这些图形简化成线，则会较大提高渲染效率。
程序层面的优化
主要从程序结构和代码表达入手，从而优化程序运行效率。
例如合并路径，在处理大数据量的时候，主要使用 canvas。canvas提供的 api比较底层，需要进行抽象后才能构筑复杂的、易维护的应用。echarts的底层库 zrender，用面向对象的方式把被渲染和管理的实体抽象成为图形元素，每个图形元素自己负责自己的渲染。抽象的弊端是牺牲了一定性能：渲染时因为每个图形渲染都要先调用 canvas api设置样式，然后构建路径，频繁的状态切换带来了性能的损失。所以可以对大数据的场景，合并图形元素，设置一次样式，构建所有路径。
另外关于内存的使用，程序的 gc时间过长可能会导致渲染的卡顿。
如下面的截图，浏览器花了 5毫秒的时间进行了 10兆的 minor gc，时间听起来不长，实际上如果能保证不卡顿，每一帧的允许时间只有几十毫秒，那么 gc消耗的时间就比较可观了。优化手段，可以是重用对象，减少老生代大对象的频繁回收。也可以使用 typed array或定长 array，从而降低内存占用、减少 reallocation。但是带来的麻烦就是，需要自己管理 array length、扩容、以及手动把多维度数组降为一维。
因此，程序层级的优化是通用的，但是会导致可读性的破坏，程序鲁棒性的降低，所以，这种优化只在必要时使用。
用户感观的优化
看如下 echarts3的渲染流程图，最左边是原始的数据，经过从左到右的过程，进行处理数据，布局，渲染，最后画到屏幕上面。如果出现了交互，就需要重新布局，重新渲染，重走这个过程。在大数据下，整体流程全走完的时间是很可观的。当时间难于减少时，经常的思路就是流，或者说渐进增量的渲染。
如下是 echarts4的一个管线图，最左边是原始数据，会被 echarts自动分片，每一个 chunk从左到右走完整的渲染流程，走完后直接在 svg或者 canvas中被渲染出来。然后按时间线往下，下一个 chunk继续走。这样将任务分片进行而非整块阻塞，使用户觉得并没有卡顿。
数据加载的优化
对于百兆千兆的数据，文件体积有可能数十甚至上百 mb。
优化的手段，首先是可以使用 typed array直接存成二进制文件而非文本文件，这样能极大的压缩数据文件的体积。echarts已支持直接使用 typed array传入数据。
另外，如果在网络上展示，不宜在数据全部下载完成才开始渲染，echarts支持了增量渲染后，使用者可以将文件分片加载，加载的文件直接传入 echarts进行渲染。
数据集
数据集为数据输入方式提供了一个新的选项：直接传入二维表（二维数组或者对象数组）形式的数据，然后通过配置视觉映射（即，哪些行哪些列映射到哪些轴、颜色等）来得到可视化结果。这比较符合数据可视化制作和探索的操作思路：基于一份数据，改变映射规则，发现信息。这也方便了数据和样式的分别管理，从而易于程序开发。
跨平台图形接口
什么是跨平台的图形接口？
对于一个 2d的图形接口而言，通常包括矩形、圆形、路径等这样一些图形元素，而图形元素又包括属性，并且图形元素和元素之间可以进行相互的组合，进行遮罩处理等。我们说 echarts支持跨平台，指的是哪些平台呢？我们考虑了以下几个方面：首先是浏览器，浏览器是基于不同的方式进行渲染的，比如 canvas，svg，vml，这样的场景下不同的分辨率我们可能希望使用不同的布局方式，通过响应式的方式使得空间的利用更加合理。对于特殊平台，比如说像服务端的渲染以及微信小程序端，也对它进行了兼容。除此之外，还对盲人使用的朗读设备进行无障碍访问的设置。
为什么需要跨平台的图形接口？
对于用户，他其实并不关心这个图表是用 canvas做的，还是 svg做的。对他而言，良好的体验才是最重要的，他只希望能够看到正常的图表，并且有良好体验的图形渲染结果。至于这个图形是如何渲染的，他并不关心。而对于开发者而言，他则需要将所有的平台一一实现。
基于这样的场景，就需要对不同的平台进行兼容，并且不同的平台有些设备存在一些性能上的差异。
echarts解决方案——zrender 提供三种渲染器
echarts使用的是 zrender底层渲染器。zrender提供了三种渲染器，分别是 canvas，svg和 vml。它对上提供了一种渲染平台无关的图形接口，对下封装兼容不同平台的实现算法。
1、如何支持多种渲染方式？
百度高级前端工程师羡辙举例说明。首先声明一个矩形，只需要告诉它 x坐标，y坐标，宽度以及高度信息，它的渲染引擎就会根据具体的渲染平台去做不同的渲染底层的实现，底层是一个叫路径代理 pathproxy的类，它会负责记录这个底层的绘制指令。根据不同的渲染器，底层进行不同的实现。通过这样的一种方式，不但可以使用一种统一的方式，还可以对于不同的渲染器进行渲染。它还有一个好处是，假设使用 web worker进行批量化渲染，也可以根据这个数组实现渲染。
2、如何支持事件处理
为了不同的渲染器有相同的事件处理机制，我们对整个图表容器绑定了事件。也就是说，对于 svg、vml 而言，我们不对其 dom 树下的每个元素绑定事件。这样就能和 canvas 有一套统一的事件处理机制。
在判断事件将被哪个图形元素响应的时候，我们会反向循环渲染列表，也就是先判断鼠标是否在位于屏幕前面的图形内。判断的时候，会先将鼠标坐标变换到图形坐标系。这是因为图形可能是经过平移旋转缩放的，甚至图形与图形之间还可能有组合的变换。将鼠标变换到图形坐标系后，我们就可以知道两者的相对关系，然后先根据包围盒做粗略的判断，再根据路径做精确的判断。如果鼠标在该图形内，则让这个图形进行事件分发与冒泡，如果不在，则对位于屏幕后方的元素一一判断。
3、svg渲染如何部分更新
canvas 在渲染的时候会完全重绘，但是它的效率很高。而对于 svg 而言，比如有一千个点的散点图，在 dom 中就有一千个对应的节点。如果每一帧都需要将所有 dom 元素删除再重新添加，那么效率是很低的。
因此，我们维护一个渲染对象列表，每帧将新的渲染对象列表与上一帧的进行 diff，获得新增、修改、删除的渲染对象列表，再根据列表对 dom 相关节点进行调整。
4、svg渲染如何优化效率
以渐变为例，采用复用渐变定义的实现方式
定义一个 svg 中
渐变、遮罩、阴影等继承该类
每一个渐变对象共享一个
更新渲染对象的时候
检查渐变对象是否生成过 dom 节点
如果有，则将 fill 或 stroke 设为该 dom id 对应的 url
如果没有，则生成一个新的 dom，并在渐变对象中引用
更新渲染对象的时候
渲染前将所有渐变标记为未被使用
新增或更新对象时，如果有渐变，将其标记为已使用
更新渐变属性（颜色、位置等）
渲染后未被使用的渐变 dom 将从
echarts解决方案——响应式设计支持
echarts支持三种定位方式：
像素、百分比、位置描述定位
除此之外 echarts还实现了一种响应式的布局方式，也就是可以将图表在不同分辨下，使用不同的配置以及布局。这个是如何实现的，看下方右边这张图，它由两部分组成，一个是 baseoption，一个是 media。baseoption说的是对所有分辨率都会采用的配置项，而 media是一个数组，它的每一项包括代表了一个分辨率的配置情况。每一项包括一个 query和一个 option，query是对每一个分辨率采取这个配置，option是在这个分辨率下使用哪个配置项。query可以包括它的宽度，高度以及长宽比，并且可以使用最大最小值。
echarts解决方案——特殊平台及特殊设备
特殊平台的处理
判断平台
兼容特定方法
无障碍访问
根据图表内容生成描述
提供模板供开发者修改
对于盲人朗读设备使用的无障碍访问，w3c制定了无障碍互联网应用规范集的标准。它的目的就是使网页内容和应用能够被更多的残障人士访问。对于 echarts而言，希望实现的效果是根据一张图，生成关于这个图的数据，并且这个描述不是用户写的，而是根据它的配置项来自动生成的。它会绑定在一个属性 aria-label 上，这个属性会被盲人的朗读设备识别并且进行朗读。但是也会遇到很多难点：不同图表类型的描述方式不同、不同数量、不同形式数据的描述、生成的描述需符合语法规范、需要简明扼要地表达图表内容以及需要支持不同语言。那最终是怎么实现的呢？echarts实现了一套基于模板块的方法，对于不同的图表类型、数据量、数据形式使用不同的模板，不同的语言也可以由用户自定义模板。
3 echarts教你如何选择和设计你的图表
基于可视化理论以及 echarts的数据可视化设计规范和项目经验，百度高级前端研发工程师王俊婷为大家详细的阐述了如何根据不同需求及目的来选择正确的可视化图表类型，以及如何正确合理的使用图表来展现数据。结合实际行业案例总结了数据可视化作品设计的方法和原则，从而帮助大家获得更好的数据展现效果。
选择合适的图表
图表是为数据服务的，数据类型决定了可选择的图表类型。我们首先要从数据本身入手，选择可满足其展示需求的图表类型。按照每个图表类型的功能及适合的数据类型，将图...