最近參與了一個微信小程序項目，里面需要做一個圖表，故事就這么開始了。。。

圖表組件支持的少

搜了一圈組件，發現 圖表類組件在小程序生態里面好殘缺 。。。像 echarts 這類豐富的圖表組件庫還沒有適配小程序，能夠想得到的原因大概有：

1. 小程序運行機制有限制，比如：window 對象不能直接訪問等
2. 事件監聽機制不一樣，小程序里要使用 bindxxx 函數來實現，和原生的事件監聽接口有比較大的差別

最終，我們是在 wx-charts 這個組件上進行了一些二次開發才完成的圖表組件。

js 執行效率低

除了社區支持不足的問題以外，還遇到了 js 執行效率低 的問題。

需要說明的是，我們要在圖表上實現拖拽圖表滾動的效果，wx-charts 并不支持，團隊里的小伙伴自己擼了一個。可是同樣的代碼，在 iPhone7 上運行流暢程度勉強可以接受，但是在我的 iPhone6 上神卡。小程序開發工具在真機 profiling 方面的支持基本沒有，只能用 log 大法來定位問題。

要說拖拽功能的開發套路：主要就是監聽 touch 事件，在 touchstart 事件里，記錄手指的起始位置，在 touchmove 事件里計算手指位置的偏移，根據偏移重新畫一幀。跟蹤性能的方法就是使用日志記錄下來每一幀的繪制時間。

實測發現， iPhone6 上平均每幀要 100~120 ms，也就是說只能達到 8~10 fps。。。可不就是卡嘛。。。

大概想了一下，性能問題應該出在以下幾處：

1. canvas 接口本身性能問題
2. 繪制圖表時 canvas 中繪制的內容太多
3. 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 次，代碼大概如下：

const LIMIT = 40;
let prev = 0;

function onTouchMove(e) {
  const now = new Date();
  const duration = prev - now;
  if (duration < Math.floor(1000 / LIMIT)) {
    return;
  }

  prev = now;
  // draw canvas...
}

其他問題

除了上面提到的 canvas 圖表問題，做一次小程序之后還發現了一些問題，希望大家開發的時候提前準備好應對措施：

• 很多組件要手動引入到小程序代碼當中
• 由于小程序的限制，一些開源組件需要手動修改里面的一些代碼才能在小程序當中使用
• 兼容性問題，在 PC、Android、iOS 上表現不一致。比如想讓在 canvas 上使用 transform: rotate(90deg) ，PC 上沒有問題，但是 iOS 上不起作用