版本：V5.1.1

背景

饼图、折线图、柱状图、矩形树图等图表都可能采用标签来展示详细数据。但在大数据量下针对不同的图表可能存在(包含但不仅限)如下情况:

1. 饼图要防止标签的位置已存在标签，需要对当前待绘制的标签移动位置以防止重叠。
2. 折线图数据间隔过短导致标签重叠，需要间隔显示。
3. 矩形树图数据块太小无法容纳标签需要隐藏。

面对上述情况应该如何应对？我们尝试从ECharts的源码中来一探究竟。

结论

饼图

饼图的label防重大致步骤如下：

1. 根据饼图的半径,指示线的长度初步计算标签的位置。
2. 分左右处理标签的重叠问题
3. 在垂直方向将标签在可用空间内无重叠分布
4. 如果无重叠分布后所需空间大于可用空间则均匀分布
5. 分上下分别计算所需空间与标签半径(饼图的半径加指示线的长度)的大小以较大的作为长轴，标签半径作为短轴构建椭圆。
6. 将标签均匀分布在椭圆方程上
7. 渲染时候如果标签仍会与已有标签重叠则隐藏该部分标签，如果标签文字的长度大于标签的空间大小则对标签文字进行截断

折线图与矩形树图

折线图与矩形树图则相对简单，只经过了对标签的简单布局以及LabelManager.ts中对仍重叠的标签的隐藏处理，即饼图防重中的步骤7。

作为已在成都定居的非知名蓉吹 ，初见此问题我的内心深处是拒绝的。我一定要为成都翻身！

然而…..

该问题下的统计结果
在成都面前，所有的城市都均沦为了长尾 。

静态图标主要用于传达信息、动效则赋予了它更多的功能。例如：引导用户进行下一步操作、将用户的目光聚焦到重要的信息上、使用户的操作得到更好的反馈、提升产品的品牌形象。

SVG元素Path标签的d属性同样可以使用transition来实现平滑过度、本文简单介绍如何使用transition来平滑过度path标签的路径，有那些限制，以及如何解决。

版本：V5.0.2

背景

ECharts在大规模数据渲染下采用了多层画布技术，对于背景元素、数据元素、交互提示类元素做分层处理对于样式稳定的元素单独绘制，不再重绘。用于性能优化。

ECharts如何去实现多层画布的？我们尝试从ECharts的源码中来一探究竟。

背景

ECharts在大规模数据渲染下性能表现优秀，基于现有的知识体系我们猜测可能应用了：

1. 数据抽取策略，在已确认的小画布大数据，数据无法完全展示的场景下对数据做采样仅展示关键帧数据。
2. 离屏渲染一种比较常见的针对复杂场景、重复元素的canvas性能优化解决方案。
3. 多层画布对于背景元素、数据元素、交互提示类元素做分层处理对于样式稳定的元素单独绘制，不再重绘。

ECharts应用了哪些性能优化方案？如何去实现的？我们根据宿爽 - 16毫秒的挑战_图表库渲染优化尝试从ECharts的源码中来一探究竟。

版本：V5.0.2

背景

使用ECharts的lazyUpdate模式多次执行setOption,仅对最终的option渲染一次。ECharts是和React一致自己单独实现了一套任务管理机制，还是基于setTimeout或Promise做的异步渲染？我们尝试从ECharts的源码中来一探究竟。

结论

代码挺好跟，但涉及到Even loop深入理解起来会相对困难。简单说明就是采用lazyUpdate更新图表的话，图表会在下一个 animation frame 中更新而在下一个animation frame之前执行的setOption会根据notMerge参数来判断是合并option还是采用最后一次option直接渲染。

ECharts版本：V5.0.2 ZRender版本 V5.1.1

背景

Canvas作为一个单独的DOM元素，内部是用一维数组来存储的像素数据，也就意味着无法和HTML一样直接对其内部的元素做事件绑定。如何去做Canvas内部的事件响应以及，一旦Canvas中的元素多起来如何去做性能优化。我们尝试从ECharts的源码中来一探究竟。

这里放了一个具有一千个元素(扇形)的饼图，我们通过该示例来跟踪源码探究ECharts是如何实现的。

结论

总体来说ZRender对于Canvas内部的事件判断的方式为单独构建了一套事件系统。对于每一个图形，ZRende会检测一个事件的位置坐标(x, y)是否在图形的包络盒中，对于Path类的图形ZRende会在命中包围盒后多做两次判断是否命中多边形的边框或内部区域。ZRende对于巨量元素的事件判断在性能上的优化方式为构建外围包围盒，在命中包围盒后再判断坐标是否再图形内部减少了大量计算。

Type-Challenges

这里记录一些基于type-challenges的一些挑战题目来学习的typescript type笔记

背景

1
2
3
4
5
6
7
8
9
10
11
12
13

// 以下这三个类型均来源于 '@type-challenges/utils' 这些类型将会在接下来用于判断挑战的结果。这里简单介绍以下这三个类型 
import { Equal, Expect, NotAny } from '@type-challenges/utils'
// Expect 是一个泛型 接受一个参数 类型T 类型T要继承自true即类型T要为true否则会报错 如此就实现了判断类型是不是true的方法。
type Expect<T extends true> = T
// 这个可化繁一下
// export type Equals<X, Y> =
//    (<T>() => T extends X ? 1 : 2) extends
//    (<T>() => T extends Y ? 1 : 2) ? true : false;
// 这里做了个延迟判断
// 简单来说就是 Ts本身在给定X，Y之前无法确定T类型就延迟判断， 给定X，Y了之后(<T>() => T extends X ? 1 : 2) extends (<T>() => T extends Y ? 1 : 2)整理要为true即T同时具有X和Y的属性，如果T不同时具有X和Y的属性即整体为false。这样就是延迟判断。
type Equal<X, Y> = <T>() => T extends X ? 1 : 2 extends <T>() => T extends Y ? 1 : 2 ? true : false
// 做了一个简单的判断 T 为any类型的话会报错
type NotAny<T> = true extends IsAny<T> ? false : true

版本：V5.0.2

背景

ECharts基于笛卡尔坐标系的折线图，柱状图。默认自适应的Y轴普遍都很整齐美观(间隔，最大值是默认是整数且通常为10的倍数，对人类友好)。这是如何实现的呢？我们尝试从ECharts的源码中来一探究竟。

结论

总体来说要实现友好的间隔(niceTicks )和范围(niceExtent)，首先要根据原始的值的范围和分段数量来获取每个分段的大小，在对这个数字进行美化，具体美化规则见上文代码，大体思路为判断数字的首位距离1,2,3,5,10谁更近就将其作为数字的首位并抹去其余位的数字。获得美化后的分段大小后再根据分段的大小和原始范围来确定分段的个数。这部分的理论依据见Nice numbers for graph labels - heckbert 1990.pdf · Yuque。