? ? 近期做了兩個移動BI項目，大量用到了Echarts來繪制圖表，中間碰到一些實現上的問題，或者針對移動優(yōu)化的經驗，記錄一下。
1，按需加載
????移動端相對PC，是一個更加性能敏感的環(huán)境，所以對于資源請求的頻率和大小、動畫和計算的消耗會要求更高。所以第一點就是，根據業(yè)務需要，按需加載Echarts組件，而不是整體引入。這個沒什么好贅述的，可參考官方文檔
2，使用SVG渲染圖形
????Echarts在v4.0版本，在默認canvas繪制的基礎上，新增了svg的圖形渲染方式。在不少場景中，SVG 具有重要的優(yōu)勢：它的內存占用更低（這對移動端尤其重要）、渲染性能略高、并且用戶使用瀏覽器內置的縮放功能時不會模糊。當然canvas的優(yōu)勢在于更復雜的圖形或者炫酷的動效，這個主要還是需要根據業(yè)務場景來做選擇。大部分情況來說，移動端用svg渲染，顯然是更合理的選擇。具體可參考官方說明。
? ? 但是，我自己項目在做整體替換svg渲染模式時，出現了一個小問題，那就是tooltip組件的背景色設置不生效了。找了文檔并未發(fā)現什么說明，時間緊張于是又切回了canvas模式。
3，移動端字號設置
? ? 因為移動端尺寸的限制，圖表有時候會很緊湊，也就存在更小文本的需求。這里主要說的是，因為圖形都是canvas或者svg來繪制的，所以，字號的設置不受瀏覽器的最小字號限制。我們可以隨意設置更符合界面顯示需要的字號。
4，tooltip的顯示位置優(yōu)化
? ? tooltip默認是出現在用戶交互的數據點附近，這在PC端并不會產生什么問題。但移動端交互是手指觸摸產生的，在觸摸點展示會導致數據展示框會被手指擋住很大一部分，用戶無法看全。因此基于良好的交互體驗的前提下，應該動態(tài)計算tooltip的position，使其始終在觸摸位置的左上角顯示；
? ? 如下代碼，建議是top值其實可以不用動態(tài)，讓其始終在圖形上方即可；left值根據當前觸摸交互點的位置，減去一定的值就行，這個具體數值根據你圖形的tooltip寬度，做一些相應的調整就行。
? ? 對了，為了防止圖形溢出，應該設置tooltip的confine屬性為true
position: function(pos) {
????var? obj = {
?????????top: 10,
?????????left: pos[0] - 130
?????}
?????return obj;
?}
5，折線圖-數軸最小值的優(yōu)化建議
? ? value類型的Y軸，如果數據整體差異較小，默認用0作為最小值的話，整體數據的波動性圖形上就體現不太出來。因此，基于用戶體驗考慮，應該動態(tài)計算數據最小值作為min屬性的值，以便圖形能夠更好的體現波動性。
6，多圖形重疊交叉圖表的優(yōu)化
? ? 單個圖例中，如果存在多個series數據項，則存在圖形交叉疊加的可能性。因此，也是基于用戶體驗的考慮，應該設置圖形的層級，讓更重要的數據展示在最上方，避免覆蓋?？赏ㄟ^series中的z屬性來設置優(yōu)先級，數值越大優(yōu)先級越高；
7，tooltip默認自動顯示
? ? tooltip默認是基于用戶交互，才會展示的；但根據不同業(yè)務需要，可能存在圖形渲染完畢就展示tooltip的需求。這個echarts也有提供相應的api的。通過圖形實例的dispatchActiopn方法，可以手動觸發(fā)tooltip的顯示。
? ? 這里有個要注意的點，當我們獲取到圖形數據，然后通過setOption把數據傳入echart實例后，如果同步執(zhí)行上述的方法，可能無法成功。因為此時option更新后，圖形還未渲染完成，會導致tooltip無法成功顯示。因為建議在setOption之后，通過setTimeout異步執(zhí)行上述方法。
8，同一圖例展示不同數據項的問題
? ? 同一個圖例，基于不同的用戶選擇，渲染不同的數據。如果圖例數據存在數據項的變化，直接setOption會導致數據殘留。因為echarts修改option，默認是數據合并狀態(tài)的。因此如果要徹底更新option，需要在setOption時，設置第二個參數為true。
