这是我用浏览器录制的性能报告里面整理出来的调用栈，长的像个手机系统systrace。举例的这个还是少的，只不过用时最长。
mousemove → e.trigger → e._drag → t.dispatchToElement → ondrag
↓
e.refresh → e.refreshImmediately → e._flush → e.flush → t.setOption
↓
jK → UK → rY → oY (ECharts 内部渲染函数)
然后对比源代码检查，除去一些看上去必要的调用，一眼登出来的不合理大概就是反复下面的流程
setOption()
↓
ECharts 内部 diff 算法对比新旧配置
↓
计算需要更新的元素
↓
重新计算所有曲线数据（getAggregateLineData）
↓
SVG DOM 操作（创建/更新/删除元素）
↓
浏览器重排重绘
或者说，是echart的一些插件不适合嵌入式平台，在I5 12500cpu电脑上，每次鼠标事件触发都需要40ms左右甚至更多，
而一次一秒不到的拖动鼠标就能触发30次鼠标事件
在rk3562上面，一次鼠标事件得有1000ms左右，所以一拖动就卡，卡到拖动鼠标一次，只能触发2到3次鼠标事件。
（响应式ui设计看来只适合pc了，主频不够缓存不够咋能这么搞，也许还有其他差异导致的表现悬殊，但那就没必要深挖了