目前 wxml 标签中的属性名对数字的支持有限。请考虑统一写作 class1 而非 class-1 。之后我们会考虑改善。
组件的externalClasses属性组件的externalClasses属性值有数字导致绑定无效 [图片]
2019-03-14图上显示的微信版本最晚都是一年前的了，比较久远。我查了一下内部的更新记录，发现很老版本下确有类似问题，需要更新微信版本才能解决。
at api getClipboardData 这么久的bug还没修复吗;at App onShow function;at api getClipboardData success callback function， 今天用户老是说打不开，加载失败 快速搜索一下，并没有用过这个getClipboardData函数 然后那用户的数据在调试工具一看，没问题。 去后台看日志也是没有报错。然后就小程序报错群一直这个问题。而且还是今天才有的，特奇怪。 [图片] 还有个问题，我记得以前那个app.json配置文件只要有文件的路径没有配置了，就会报错，调试不了。但是现在是不提示报错没有配置路径了，还是可以用。 我是怎么发现的呢，后台通知报错，错误码 41030 ,就是page 参数配置错误，原来是没有问题的，直到今天上了个 app.json没有那个跳转路径的版本后，才报错。 真的难受~
2019-03-14看起来是 iOS 系统对 env(safe-area-inset-bottom) 的支持度的问题。我们也没法解决。
自定义 tabBar iphoneX 适配问题，不吸底自定义组件到不了 底部，但有时又可以。 [图片] [图片] [图片]
2019-03-14小程序崩溃闪退时没有办法执行开发者的代码，所以是没法上报的。
（已解决）亲们，要求小程序上报到服务器崩溃日志，我如何获取崩溃信息？如题，求亲们指导，服务端提供了接口，现在我不知道如何获取崩溃信息，并在何处调用服务器的接口。
2019-03-14iOS canvas 的绘制性能会稍差一些，在每次 bindchange 的时候都绘制的话确实可能会有抖动的情况，请考虑降低绘制的频率。 out-of-bounds 我这边测试并没有问题，只是你的点太小了，回弹动画很不明显。如果真的需要回弹动画，请考虑调整一下 damping 之类的动画参数。
moveable-view设置out-of-bounds无效- 当前 Bug 的表现（可附上截图） iPhone手机移动moveable-view组件时 canvas绘制的线条出现抖动 moveable-view设置out-of-bounds无效 - 预期表现 - 复现路径 - 提供一个最简复现 Demo https://developers.weixin.qq.com/s/9xaEVQmK7h6Y
2019-03-14这个是使用哪个接口发送的请求呢？
在真机调试中 Request Header 自己定义的属性被强转小写- 当前 Bug 的表现（可附上截图） 在真机调试中Android和ios 的 Request Header 自己定义的属性，不一样，Android的被强转为小写 - 预期表现 Android的应该跟代码中设定的一样，为大写开头 - 复现路径 - 提供一个最简复现 Demo [图片] [图片]
2019-03-14预期应该是返 fail 。mix2s 返的 success ？微信测试版吗？
getStorage 取不存在的值时，有些手机返success，有些返fail调用wx.getStorage 异步获取key对应的value，此时storage没有key-value，然后在 小米mix2s 上，返的success，在iPhone和大部分安卓手机以及开发工具，返的都是fail 咨询下官方，是安卓版本问题，还是微信版本问题，还是storage的bug会导致这个问题。
2019-03-14就是指需要从微信的 CDN 下载代码包时，网络消耗的时间 下载时间受很多因素影响，以我们的经验小程序代码包大小对下载时间的影响其实不大 下载时间受很多因素影响，和你们的用户使用特点（离线包命中率之类的）也有关系，所以用节假日的数据不好推断原因 同3，另外，更新小程序和初次下载小程序需要的下载时间是不一样的 top 的小程序包通常也比较大，所以其实参考价值不大 以我们的经验和试验结果，优化主包大小其实是对整体启动时间有帮助，而不一定会表现只在下载耗时上（影响下载耗时的因素实在是太多了）；反倒是从下载完成到小程序完全启动消耗的时间，与主包大小呈现更明显的正相关关系（不过这个数据你们不太好搜集）。
请教主包大小对加载速度的影响Hello 我从2月8号至2月13日，逐渐开始优化主包大小，主包从1.7MB降到1.26MB 之后从2月13日到今天，主包从1.26MB降低到1.18MB 但是通过小程序助手观察到的下载时长如下： 可以观察到Android的下载时长几乎没有任何变化，iOS则从除夕假期开始下降，随着假期结束逐步回升。 也就是主包大小精简了44%之后从小程序助手没有看到明显的优化效果。 [图片] 想咨询的是 小程序助手里监控的下载时长在整个生命周期里指的是哪一段时长，能否区分用户是否下载过小程序离线包 Android为什么没有随着主包的体积减少，下载时间有所优化 iOS的下载时长为什么会随着节假日开始而有所缩短 如果3是否定的，从图表上看iOS的下载时长似乎是随着主包体积减少而逐渐加大，想了解原因 业界最好的小程序在下载时长上大概是什么水平，能否推荐TOP3的小程序供我们参考学习 使用方有没有小程序助手以外的办法统计主包下载时长，当前我只能从用户从小程序外扫码开始计时到onlaunch统计计时，我理解这个时间既包含了下载又包含了预加载等时间 另外供以参考的通过我自己的业务监控来看（用户从小程序外扫码开始计时到onlaunch的计时），下载时长也基本没有变化。 [图片] 希望哪位大拿可以帮忙答疑解惑，万分感谢，北京方向期待面基约饭 ：）
2019-03-14已复现。看起来不是每次都必现的？
竖屏跳横屏再返回竖屏，页面元素变大，getSystemInfo不正确- 当前 Bug 的表现（可附上截图） 1.进入竖屏页面： [图片] 2.进入横屏页面。 [图片] 3.按手机返回键返回上一页。发现页面显示异常。并且getSystemInfo接口拿到的参数也变成了横屏的参数。 [图片] - 预期表现 返回竖屏页面正常显示。 - 复现路径 目前主要在安卓机上测试，小米8以及其他很多安卓机型，从竖屏页面进入横屏页面，再点击手机返回键回到竖屏页面。发现页面显示异常。 - 提供一个最简复现 Demo https://developers.weixin.qq.com/s/bYbCnRm97N63
2019-03-14获取的就是对应自定义组件的 this 。具体逻辑请你自己检查一下。
getRelationNodes获取的节点信息不会实时更改吗？getRelationNodes获取的元素，每个对象里面有个data属性，data属性里面有个top字段，这个数值是相对于谁？当我translateY移动后，为什么获取到的还是最初的那个top值？？？？怎么才能随着页面的变化实时获取？
2019-03-14
获得过 0 次赞
回答过的问题获得 0 次赞
分享过的文章/案例获得 0 次赞
评论与回复获得 0 次赞