最近参与了一个微信小程序项目，里面需要做一个图表，故事就这么开始了。。。
图表组件支持的少
搜了一圈组件，发现图表类组件在小程序生态里面好残缺。。。像 echarts 这类丰富的图表组件库还没有适配小程序，能够想得到的原因大概有：
小程序运行机制有限制，比如：window 对象不能直接访问等
事件监听机制不一样，小程序里要使用 bindxxx 函数来实现，和原生的事件监听接口有比较大的差别
最终，我们是在WX-charts这个组件上进行了一些二次开发才完成的图表组件。
js 执行效率低
除了社区支持不足的问题以外，还遇到了js 执行效率低的问题。
需要说明的是，我们要在图表上实现拖拽图表滚动的效果，wx-charts 并不支持，团队里的小伙伴自己撸了一个。可是同样的代码，在 iPhone7 上运行流畅程度勉强可以接受，但是在我的 iPhone6 上神卡。小程序开发工具在真机 profiling 方面的支持基本没有，只能用 log 大法来定位问题。
要说拖拽功能的开发套路：主要就是监听 touch 事件，在 touchstart 事件里，记录手指的起始位置，在 touchmove 事件里计算手指位置的偏移，根据偏移重新画一帧。跟踪性能的方法就是使用日志记录下来每一帧的绘制时间。
实测发现， iPhone6 上平均每帧要 100~120 ms，也就是说只能达到 8~10 fps。。。可不就是卡嘛。。。
大概想了一下，性能问题应该出在以下几处：
canvas 接口本身性能问题
绘制图表时 canvas 中绘制的内容太多
js 本身的执行效率
期初都没怀疑 js 的效率问题。先是怀疑问题出在第二点上，因为我们要做的是一个左右滑动的图表，在显示区域以外的数据点还是很多的，所以先是优化了 canvas 接口的调用次数，不在显示区域里面的数据点全部都过滤掉。优化之后看结果，性能确实有提升，但是也就是能提升到 12~15 fps 的水平，性能提升不明显。
赶巧那段时间，有人在讨论 Node.js v8.0 上 forEach 的性能提升。再看 wx-charts 里面用了大量的 forEach/map 方法。抱着试一试的态度，把里面最关键的部分全都改写成普通的 for 循环。结果惊人地发现，每帧的绘制时间降到了 30~40 ms。
结论，实际测试发现：在 iPhone6上，forEach/map 方法的性能问题还是比较明显的。平时做一些普通的功能开发看不出来，但是如果是在 canvas 图表这类对性能要求比较高的场景下，问题就很明显了。
touch 事件大量积压
除了 js 执行效率问题外，我发现小程序的 touch 事件有明显的延迟现象。准确的说是：事件触发的时间间隔低，如果事件回调函数执行时间长的话，touch 事件不会被丢弃而是会大量积压。像上面说的情况，每次 touchmove 时间回调要执行 100+ ms 可是 touchmove 事件目测不超过 20ms 就会触发一次。所以如果快速滑动屏幕，图表就跟上了发条一样，会延迟绘制很多次。
上面虽然优化了性能，但是还不能避免事件积压的问题。最终是加了一个控制逻辑，将 touch 事件的频率降低到每秒 40 次，代码大概如下：
其他问题
除了上面提到的 canvas 图表问题，做一次小程序之后还发现了一些问题，希望大家开发的时候提前准备好应对措施：
很多组件要手动引入到小程序代码当中。
由于微信小程序的限制，一些开源组件需要手动修改里面的一些代码才能在小程序当中使用
兼容性问题，在 PC、Android、iOS 上表现不一致。比如想让在 canvas 上使用 transform: rotate(90deg) ，PC 上没有问题，但是 iOS 上不起作用。
