微信小程式在ios下Echarts圖表不能滑動的解決方案
問題現象
這個問題的現象說起來很簡單。
小程式頁面中有一篇很長的文章,內部有一個Echarts圖表,手指上下滑動觀看內容。
但是手指滑動區域在Echarts圖表上時,頁面卻不能滑動了。
如下圖:
追蹤問題原因
因為在小程式上渲染圖表用到的是echarts-for-weixin這個元件,而這個元件確實不支援一些Echarts功能。
所以最開始我懷疑是這個元件的問題,認為它把我的滑動事件給吞了。
為了確認這個問題,我直接在這個元件ec-canvas旁加了個兄弟節點view,然後用絕對定位將其覆蓋在ec-canvas,這樣滑動的時候就會滑動到我的view上而不是ec-canvas。
但是結果在ios下,還是不能滑動。
於是我給這個view的加了個背景色,在ios下的真機除錯時發現,ec-canvas元件還是在view上面。
不論是加大view上的z-index值,還是將absolute改為fixed,反正ec-canvas元件所渲染的圖表就是在view上面,而沒有被view遮擋。
這個ec-canvas元件是如此出眾,無論什麼都遮蓋不了它的風采。
而導致它如此出眾的原因就是:圖表是一個canvas元件,而小程式中canvas是一個原生元件。
接下來就讓我們看看小程式中使用原生元件的限制。
小程式的原生元件使用限制
這裡先附上鍊接:小程式原生元件使用限制。
讓我們看看關鍵的地方:
也就是說canvas這類原生元件就是比view這種非原生的元件層級高。
用cover-view來解決?
為了解決原生元件層級最高的限制。小程式專門提供了 cover-view 和 cover-image 元件,可以覆蓋在部分原生元件上面。這兩個元件也是原生元件。
我將原來的兄弟view元件替換為了cover-view元件,然後希望達到可以滑動的效果。
雖然此時cover-view元件已經可以覆蓋在canvas上了,但是依然不能滑動。
關於這個問題,我們可以認為小程式的所有元件都是放在webview中,而原生元件在webview中用的是佔位符。
在滾動時,獲取原生元件佔位符的位置,再改變原生元件的位置。(如果仔細觀察,會發現這些原生元件有時會產生一些奇怪的抖動,這一點可以佐證這個論點。)
所以ios下,我們手指在canvas和cover-view這類原生元件上滑動時,事件是不會傳導到webview上的,頁面也就不會滑動。
最終解決方案
對於這個問題,因為我這邊和echarts的互動比較少,所以我的解決方案就是在echarts渲染完畢後將它替換為一張圖片。
如果我更新了資料,那麼就重新放出echarts,等它渲染完畢後,再次替換為一張圖片。
由於公司程式碼不適合放出,所以我搞了個簡易版的程式碼放在這裡。
wxml檔案關鍵程式碼:
<view class="echart-container">
<image wx:if="{{echartImgSrc!==''}}" src="{{echartImgSrc}}" class='echart-img'></image>
<ec-canvas wx:if="{{echartImgSrc===''}}" id="mychart-dom-pie" canvas-id="mychart-pie" ec="{{ ec }}" bind:init="echartInit"></ec-canvas>
</view>
js檔案關鍵程式碼:
Page({
data: {
ec: {
},
echartImgSrc: ''
},
initChart(canvas, width, height) {
const chart = echarts.init(canvas, null, {
width: width,
height: height
});
canvas.setChart(chart);
var option = {
// ...
};
chart.on('finished', () => {
this.selectComponent('#mychart-dom-pie').canvasToTempFilePath({
success: res => {
this.setData({
echartImgSrc: res.tempFilePath
})
},
fail: res => console.log('轉換圖片失敗', res)
});
})
chart.setOption(option);
return chart;
},
echartInit(e) {
this.initChart(e.detail.canvas, e.detail.width, e.detail.height);
}
});
總結
總的來說,解決起來還算簡單。
但是對於和Echarts有很多互動的場景,這個方案就未必那麼好實現了。
從這個問題入手,我對微信小程式原生元件的玩法有了更多的認識。
更深入一點的認識就是,微信小程式當下對原生元件的這種處理更像是在一件普通的布衣上貼上貂皮補丁。
雖然考慮到了原生元件所帶來的效能優勢,但是同樣也會引發大量的問題,對於這件衣服的整體表現而言這些貂皮補丁恐怕並不見得是件好事。
希望以後小程式能從根本上解決這種問題吧