以下bug，cover-view和cover-image两组件都有这个问题，项目中用的是cover-image，需求是想用一张图片挡住live-pusher/live-player组件，但是部分机型会出现底部或右侧有1条和画面一样的细线，非常明显。以下是上面代码段的部分机型截图 开发工具正常效果 [图片] 荣耀9，cover-view右侧和底部没有填充满 [图片] 放大图 [图片] iphone7 cover-view右侧没填充满，并且黄绿交替线没对齐 [图片] p30 pro cover-view右侧没填充满 [图片]

复现流程： 当canvas没有图片时，绘制线条是非常流畅的，当图片一张又一张的被渲染时，再画线条就会出现明显的卡顿，可以多点几次渲染图片再画线条测试。 在我们应用中场景比代码复杂很多，大部分手机都会出现卡顿的现象，应用场景是这样的： 程序里涉及文档功能，PC端会把文档上传到服务端，服务端转化把各个元素转化成图片，假如是一个word文档经过转化，背景图就是一张比较大面积的图片，我做过一些测试，在小程序中面积越大的图片会导致绘制线条越卡顿，还测试了在原生H5中同一张图片在同一台设备中反复的绘制图像也不会导致绘制线条卡顿。小程序是否能优化这个问题？ 另外一点，服务端下发图片时，是经过websocket发的二进制信息，注意到小程序没有生成临时路径的api，只能先通过FileSystemManager写入文件，有了路径之后再通过drawImage绘制图片。但是本地10M的缓存的限制，用来存文档中的图片有点牵强，是完全不够用的而且还要加入一套文件管理的机制才能这套方案，在上面代码中能体会这点。建议小程序能引入类似H5中的Blob对象生成临时路径，解决这个需求 以上两点，感谢官方能耐心看完

live-pusher正常推流后，出现以下bug 1.live-player组件auto-pause-if-navigate的属性设置失效，如代码片段，开启推流后再切换页面，声音就听不到了 2.开启推流/关闭推流声音后停顿一下，可能是声音输出方式从媒体声音和电话声音切换导致(有没优化的办法) 以上问题出现在ios新版本上，ios微信版本7.0.11以下表现正常，安卓也正常。望修复，谢谢

经常会遇到闪退问题，有时候两个页面来回切就闪退了，有时候转发给别人再回到小程序就闪退了,每次遇到都不是同一个场景，可能是缘分闪退。 这是最近一次遇到的闪退，实在找不出原因了，已上传日志，微信号: wxid_4ymiaqhujwiu12 时间在 2020-06-15 15:46:42 之后的十几秒内。 麻烦官大帮忙分析分析,谢谢。小程序appid:wx61afdde337ea8d21

[图片] [图片] 小程序切前台后摄像头会黑屏无法恢复，也无法捕获异常状态码，不容易复现，所以没法提供代码段 就是截图的这次复现出来了，能帮忙看看官方的日志是否存在异常 微信已上传日志，微信号：wxid_4ymiaqhujwiu12 appid: wx0049f26388e78432 万分感谢！

记得前段时间接了电话、语音、视频再返回到小程序视频画面都能正常恢复推流拉流，现在是又改出问题了吗？

原以为小程序类目中有资质，插件中就可以使用。但我们近期开发完插件提审后却发现没有合适的类目提供选择，提审后却要求添加社交-直播类目。但我们小程序里只是做了简单的1对1音视频实时通讯功能，和直播关系不大，因为我们有银行的资质，又想在多个小程序中嵌套使用，所以才决定使用插件方式开发。希望微信对插件中类目进行以下点修改： 1.插件中开放工具-视频客服等其他类目选择。 2.插件中不对live-player、live-pusher等组件资质审核，在提审的小程序中统一审核。 3.小程序中必须选择有资质的类目才能继续组件开发调试，而插件开发是根据小程序的类目决定有无权限开发，这点是不合适的。 希望官方能考虑以上提及的修改点，感谢！

[视频] ios切换live-pusher大小有概率导致渲染层黑屏，状态码无异常，视频画面还在正常上传，只是本地渲染黑屏，live-player同样存在这个问题，已知可以复现问题的机型机型6s，7。点击胶囊看小程序简介或者转发给朋友再点关闭可以恢复视频画面。已知该bug存在很多个版本，但是以为是很频繁的bug官方很快就能修复，但是快大半年了还是存在，麻烦官方尽快修复，谢谢！

我们做视频会议的小程序，本端把音视频经过rtmp到服务器，后台把音频去掉了之后生成新的rtmp流地址给远端播放纯视频，音频是把大家的麦克风合成了一个rtmp地址用另一个live-player播放。 相关问题： 网络波动（wifi、4G信号不好）或者对网络限速，live-player会产生延迟，网络恢复后live-player不会恢复延迟。该问题从7.0.5版本开始一直就存在，我们做了大量的测试及对后台的架构调整也无法解决，现在也是没办法了。 问题的一些尝试： 后来发现，我们直接在live-player中播放上送给服务器的rtmp地址(带音视频的流)，网络波动后产生的延迟可以恢复到波动之前的水平。 我们猜测可能是流里没混音频才引起的问题，之后我们把远端的流里混了一些可以解码但无效的音频数据，发现安卓奇迹般的可以恢复到很低的延迟，但是苹果上并没有丝毫好转。 我们没有长期的rtmp地址，都是根据会议动态生成的rtmp地址，可以使用我们的小程序用两个手机进入同一个会议。故意制造网络不好的环境（走到wifi信号不好的地方或者对网络限速），即可复现。 希望官方进解决我们的问题，谢谢。 appid: wx61afdde337ea8d21

问题模块框架类型问题类型操作系统操作系统版本手机型号微信版本客户端小程序BugAndroidandroid9 MIUI10.3.6小米9se7.0.8 此问题是服务端接收到请求之后立即向客户端发送一条消息，小程序真机预览中通知顺序有概率是onMessag=>onOpen,在开发工具及真机调试中是正常顺序。 部分机型会存在该问题，是概率性问题，复现率50%左右。可能与小程序近期更新导致。 若出现该问题，我们小程序完全不能用了，希望官大尽快解决。 附上服务端Node.js最简化代码 [代码]let ws = require([代码][代码]'ws'[代码][代码]);           [代码][代码]//引入websocket模块[代码][代码]let socketServer = ws.Server;[代码][代码] [代码] [代码]let wss =[代码][代码]new[代码] [代码]socketServer({port: 8090});   [代码][代码]//创建websocketServer实例监听8090端口[代码][代码] [代码] [代码]//监听连接[代码][代码]wss.on([代码][代码]'connection'[代码][代码],[代码][代码]function[代码][代码](ws) {[代码][代码] [代码] [代码]    [代码][代码]console.log(`websocket已连接`);[代码][代码]    [代码][代码]ws.send([代码][代码]'向客户端发送第一条消息'[代码][代码]);[代码][代码]    [代码][代码]ws.send([代码][代码]'向客户端发送第二条消息'[代码][代码]);[代码][代码]    [代码][代码]/*监听消息*/[代码][代码]    [代码][代码]ws.on([代码][代码]'message'[代码][代码],[代码][代码]function[代码][代码](message) {[代码][代码]        [代码][代码]console.log(`message`);[代码][代码]    [代码][代码]});[代码][代码]    [代码][代码]/*监听断开连接*/[代码][代码]    [代码][代码]ws.on([代码][代码]'close'[代码][代码],[代码][代码]function[代码] [代码]() {[代码][代码]        [代码][代码]console.log(`close`);[代码][代码]    [代码][代码]})[代码][代码]})[代码] 小程序代码片段 https://developers.weixin.qq.com/s/RrYd50mY77dv