问题场景
所谓悬浮窗就是图中微信图标的按钮，采用fixed定位，可拖动和点击。
这算是一个比较常见的实现场景了。
为什么要用cover-view做悬浮窗？原生组件出来背锅了~
最初我做悬浮窗用的不是cover-view，而是view。
这是简化的代码结构：
index.wxml:
一大段test，占个位，表示下存在感
index.js:
Page({
/**
* 页面的初始数据
*/
data: {
left: 20,
top: 250,
isIos: true
},
/**
* 拖拽移动
*/
setTouchMove: function (e) {
if (e.touches[0].clientX > 0 && e.touches[0].clientY > 0) {
this.setData({
left: e.touches[0].clientX - 30,
top: e.touches[0].clientY - 30
})
} else {
this.setData({
left: 20, //默认显示位置 left距离
top: 250 //默认显示位置 top距离
})
}
},
/**
* 返回首页
*/
goToHome: () => {
wx.reLaunch({
url: '/pages/index/index',
})
}
})
为什么要用cover-view呢？
因为页面上有个textarea组件，这个组件是原生组件，当悬浮窗移动到这个textarea组件上时，将无法继续拖动和点击。
如果悬浮窗一开始就定位在textarea上，那么就更惨了，一开始就不能点击和拖动了。
这个原因是因为微信小程序的原生组件层级高于非原生组件，不是你修改几下样式就能解决的问题。
这里就不讲什么原生组件了，如果想进一步了解，可以参考我之前写的一篇博客：微信小程序在ios下Echarts图表不能滑动的解决方案。
如果你的页面上面没有原生组件，那么像上面的代码一样用view做悬浮窗即可。
如果有，那么就可以跟着我继续踩坑，使用cover-view这个原生组件层级的组件来做悬浮窗。
安卓下的cover-view拖动起来，抖得不像帕金森，像是魔鬼的步伐
以下是我们修改为cover-view之后的代码：
一大段test，占个位，表示下存在感
注意这里，我们的image也改为了cover-image，因为cover-view只支持嵌套 cover-view、cover-image，不过可在 cover-view 中使用 button。
这样虽然解决了可在原生组件上自由拖动点击的问题，但是在安卓上出现了一个很奇怪的现象，以至于我认为已经无法用抖动可以来形容了：
上图是就是我滑动这个悬浮窗之后的效果，我只是很缓慢地在移动手指，但是这个悬浮窗的表现简直就像一个受惊的兔子。
当我第一眼看见这个效果的时候一脸懵逼，我都不知道说什么好。
虽然在ios上cover-view移动起来表现良好，但是在安卓上拖动起来的表现简直没法看。
勉强能看的补丁方案
安卓上这么挫，还不如原来的呢。
所以来个补丁方案好了，在ios下用cover-vi
最低0.47元/天 解锁文章
3043
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
