- 关于升级小程序,新旧代码问题
- 当前 Bug 的表现(可附上截图) 未能获取到对应常量配置;appLaunch时正常,在onLoad的时候,取到的是旧代码配置;全局已搜索,新代码无此配置; const defaultUserAgent={}; 如截图显示:旧代码CHCode为“WechatApp",新代码“WechatApp_FM"; onLaunch如下: [图片] onLoad如下: [图片] 图中字段排序,由vConsole重新排序。 旧代码已删除截图: [图片] - 预期表现 获取到正确的配置,defaultUserAgent - 复现路径 复现操作: 1、点击旧版,线上版本1.2.0《宝宝听听大全》 2、点击体验版1.3.0《宝宝听听大全》 查看vConsole ,打印日志,即可查看 - 提供一个最简复现 Demo 问题小程序appid:wxa7cc64b494efbc52 手机操作系统:iOS与android 都会出现 操作时间: 今天12:00 - 14:00 ps: 此问题,之前,我们公司其他小程序,升级框架,删除旧代码,也会出现。 导致:用户点击新版小程序,出现,请求数据异常
2018-09-12 - 问个事件触发问题
比如说form里面有个submit按钮,它是有事件的,那么如何在其他地方触发这个submit的默认事件 如jq中的trigger(‘click’)
2018-09-06 - <we取消了navigationStyle:custom后,原有小程序怎么办?
忽然取消了navigationStyle:custom 对 <web-view> 组件的支持,我们已上线的小程序导航乱成一团,很多用户已表示不用我们的小程序产品………… 我们该怎么办?怎么办?。让我们重新开发一套吗?你们这也太随意了!!!
2018-08-30 - 频繁调用wx.getLocation,内存增涨惊人
- 当前 Bug 的表现(可附上截图) 每隔6s调用wx.getLocation接口并在map上添加一个marker,但是内存增涨的吓人, 测试手机 型号:mix2s 内存:6GB 下图是刚打开页面的性能数据 365M [图片] 下图是小程序卡住了,后来就闪退时的性能数据 [图片] 微信提示 [图片] 分析:总共调用了209次接口,小程序卡死 所耗时=209*6/60大约20分钟 小程序内存怎么不会释放,而是一直增加,直接闪退 由我的小程序业务场景需要频繁定位,所以会经常拿不到位置,出各种错误 以下我们几百个业务员实际使用接口返回的错误信息,出问题手机,苹果7,7p,各种常用的安卓手机, {"errCode":404,"errMsg":"getLocation:fail:ERROR_SERVER_NOT_LOCATION"} {"errCode":1,"errMsg":"getLocation:fail:ERROR_NETWORK"} {"errCode":2,"errMsg":"getLocation:fail:ERROR_NOCELL&WIFI_LOCATIONSWITCHOFF"} 有时明明有权限,还是拿不到位置 我们开发人员应该如何避免这些问题 - 预期表现 应该正常显示位置 - 复现路径 - 提供一个最简复现 Demo 测试代码如下 [图片] 代码片段:wechatide://minicode/4ycWW2mh7L2k 总是得不到官方的回应,希望尽早答复
2018-08-29 - 小程序getLocation获取失败
- 当前 Bug 的表现(可附上截图) 问题1:由我的小程序,使用getLocation接口频率很高,每操作一个流程都会调用getLocation接口3次,几百个人在用,天天都有人反馈获取不到位置,一个人会出现几次,返回信息 [图片] {"errCode":2,"errMsg":"getLocation:fail:ERROR_NOCELL&WIFI_LOCATIONSWITCHOFF"} 问题2:很多情况拿到的位置不准,就是从a到b地,在b地定位拿到了a的地的位置,还有就是完全拿错了,偏差几km,以下是业务员反馈的内容 [图片] - 预期表现 - 复现路径 频繁调用getLocation接口 - 提供一个最简复现 Demo 不是一直出现,是随机明 代码: [图片]
2018-08-28 - getSetting获取地理位置有没有授权bug
wx.getSetting({ success: res => { if (res.authSetting['scope.userLocation'] ) { console.log("授权授权授权授权授权授权授权授权授权") } else { console.log("地理位置未授权") } }, fail: function () { console.log("fail") } }) 授权后,始终返回未授权
2018-08-03 - 用户授权后,设置中未获取到相关权限
发现了一个问题,复现步骤为: 当用户首次进入小程序时,获取用户定位权限,由微信弹窗,用户 允许/不允许 相关权限,此时点击右上角关于,进入设置,能够看到用户操作过的权限列表。 此时用户将权限关闭并清空最近使用的小程序,再 点击卡片/扫码 进入小程序,获取用户定位权限时未弹窗,进入权限列表时也没有相关权限显示,显示为 xxxx未使用您的用户信息。 后续无法进行正常的业务逻辑处理。 请问这个问题该如何解决?(我们测试摩拜小程序,也复现了这个问题) [图片]
2018-08-22 - 加速计自动恢复成默认频率和偏移量不对的问题
小游戏里用到了加速计,发现以下问题: 多次start和stop加速计后,返回偏移量不对 一开始,我们是在开始游戏的时候调用startAccelerometer,死亡的时候调用stop, 结果:每次startAccelerometer后,发现返回的偏移量(目前只用到x)会不一样,多次start之后,这个值会变大。 多次进入游戏后,加速计的间隔会恢复成默认值200ms 由于上面这个问题,我们改成了只在进入游戏的时候启动加速计startAccelerometer,死亡后不再stop,也就是整个程序里,只在初始化的时候启动一次。但又发现,如果死亡后点击关闭按钮,程序进入后台,再打开小游戏(我这里是,从下拉小程序列表和分享这两个方式进入的,没有规律,反正就是胡乱进入),点击重新开始,多次操作后,很大几率加速计的间隔不再是启动时设置的game(20ms),而是默认值normal(200ms)
2018-08-01 - wx.pageScrollTo影响fixed元素
wx.pageScrollTo({ scrollTop: 0 }) 之后,页面中的fixed元素,先向上移动会后,再向下移动,有没有别的回到顶部的方法,除了scroll-view
2018-06-26 - 关于剪贴板弹窗最后的结论和想说的
昨天论坛里同时出现了我和其他几位开发者的关于突然读写剪贴板需要用户单次授权的问题: 当剪贴板内有内容时多了提示 wx.getClipboardData 突然弹出提示 监测剪贴板 一直弹出授权 点击确认 和取消后, 都会提出内容已复制 系统剪贴板多了弹窗提示 监测剪贴板 一直弹出层 好烦人, 如何清除黏贴版 还有这篇加急审核的 https://developers.weixin.qq.com/blogdetail?action=get_post_info&docid=000c44f0a80520af909660f9951800&highline=剪切板%7C%26弹窗&token=1934321849&lang=zh_CN 我们几位应该都是在首页onShow时使用了剪贴板内容,导致用户进入小程序就可以看到自己剪贴板的内容。并反复弹窗,这个对用户体验的伤害是灾难级别的。 昨天提交了临时屏蔽代码之后待审核,晚上团队对这个问题进行了激烈的讨论,最后决定彻底放弃对剪贴板实现页面routing的功能。这也让大家不需要等待这件事后续的调整结果了。 昨天在论坛里情绪激动,过了一夜之后平和点,但这里有一些对小程序团队,尤其是产品团队一些不得不说的话。 API的变更是否需要提前知会? 对于影响下游研发、整体生态用户体验的上线,是否应该有一个健全的知会和上线流程? 这次上线如果能先mp后台挂通知,然后文档先上线,再推基础库更新,这件事完全可以避免。我的观点里这个顺序应该是一个严格的流程,而到目前为止线上文档、开发者工具中仍然完全没有体现此次API体验变更的任何信息。我们小程序的客户也是微信的客户,现在大面积客户体验受影响是不争事实,这个在腾讯研发中算不算一个生产事故? 剪贴板到底需要不需要授权? 这完全属于讨论。我的个人观点是不需要; 一直非常支持也理解微信小程序在获取用户信息,本机电话,地理位置等等等等一系列用户隐私保护上做的设计,也一直觉得恰到好处。当然,监听并收集用户剪贴板里的内容到底有没有侵犯隐私的可能,这自然是肯定的。但这个可能性有多大? 第一剪贴板和输入法不同,不是一个连贯连续的数据采集过程;剪贴板数据偶发性和随机性特别大,所以从采集的数据规模,提炼转化的投入产出来说,都不是一个值得去实践的侵犯方案,在小程序的准入、审核门槛下风险更小。对于读写剪贴板都需要单次授权,我个人觉得是得不偿失的。到目前为止,个人还不知道任何OS、平台在剪贴板的使用上采用这样单次授权的先例,这意味着碰到剪贴板操作授权对于用户来说,都是一个全新的安全体验,这里需要付出额外的思考成本是巨大的。而应用如果只是在某种场景下使用到剪贴板,但又不得不在入口处进行检查(如手机淘宝使用淘口令)这样的授权体验会让用户怎么想?本来是非常innocent的事,反而显得非常malicious。我觉得在这点上强化用户授权行为是没有必要的,消除evil是好的,但不能成一个witch hunt。 即使授权,需要在弹窗里显示剪贴板内容么? 个人对这个设计也不理解。昨晚团队最终决定彻底割舍功能的原因,并不是完全因为有一个弹窗的干扰,而是因为这个弹窗会展示剪贴板的内容!我不知道产品经理自己是否实际体验过,这是有多么惊悚!现在大多数的移动设备都是不会关机的,而剪贴行为是一个偶尔发生的行为,但剪贴的内容往往比较重要且隐私,可能是一段领导需要传达的对话,可能是自己或者亲人或者客户的一个银行转账卡号,可能是懒得打字直接从哪复制,粘贴进入搜索引擎的一个搜索关键词。。。但这些信息都非常personal,往往复制和粘贴之间时间非常短,但粘贴之后,用户对于这段信息的期待是什么?就是除非我再粘贴,这东西就不应该再出现了,起码这个是从剪贴板被发明起就没有变化过的体验。但我们也不应该忘记,复制进入剪贴板行为是个偶发行为,剪贴板里的内容大多都是几个小时前、甚至几天前的内容;至少现在剪贴板还没有expire和判断时长的可能,所以请考虑这个场景: 我打开一个小程序给我朋友看某个有意思的页面,结果打开这个小程序时,跳出来了一个对话框,里面是我三天前复制粘贴进百度搜索的某个药品名称。。。。这是一个在任何情况下都不可被接受的场景。把这个问题换一个问法,微信小程序的产品经理,当您要求小程序只有用户授权才能操作剪贴板的时候,用户有授权微信展示他剪贴板内容在屏幕上过么?甚至在授权本机号码我们都会加几个****,PC上退出photoshop会提示“剪贴板里还有大量数据……”而不是把内容画在屏幕上, 为什么在这里展示剪贴板内容时候如此激进?难道都不是隐私内容么?这个内容足够隐私到小程序必须获取权限来获得机器判断的可能,但不隐私到可以暴露在屏幕上每次进入小程序都展示一次。。。。这是如何的自相矛盾。 即使授权,需要每次使用都弹窗么? 这点其他帖子也提到了,原因显而易见。一般需要读取剪贴板的应用场景基本都是在逻辑主干上判断是否剪贴板里是一个特定会影响应用行为的数据。这个必须读了才知道,可能产品经理是想这个判断权放到用户手里,自己看看这个数据要不要给小程序读取?但这个现实么?另外每次都让用户判断的成本有多大?另外一些场景里,剪贴板内容可能也是由应用写入,用户理解不了,还是微信就是想消灭掉应用中使用剪贴板通信的可能?既然如此何必开放这个API? 我们作为小程序研发者,公司可能整个业务都放在上面(以我们为例,我们没有h5,没有app,小程序是我们唯一的端) 几十个弟兄上上下下青春和财务都依赖微信生态,我们初心也简单,第一信任腾讯,第二相信小程序是解决我们业务场景的最佳不二选择,所以才这样没有backup的上。过往也会碰到各种bug和变动,但这一次,说实话伤害到了信任。这次提的4个问题,第1个问题,就跟昨天帖子里说的那样,这样不对,我们认为贵团队应该我们一个必要的说法。大家都是做研发,文档准确的重要性不言而喻不可儿戏。 第2,3,4问题,是我们坚持认为这个设计是一个错误,从我们狭隘的见识中,还看不到合理化解释的任何可能。这两点,真的只能说很遗憾。
2018-04-13