我提交自动测试申请，大概多久才会有结果

官方文档链接：https://developers.weixin.qq.com/miniprogram/dev/framework/config.html#%E9%A1%B5%E9%9D%A2%E9%85%8D%E7%BD%AE [图片] 在 index.json 配置了disableSwipeBack 为 true，在webview的部分场景下，是可以侧滑的。 各位大佬有没有遇到

- 当前 Bug 的表现（可附上截图） 用户扫码二维码A，小程序onload中传递q参数为二维码地址B，且该二维码地址为用户历史使用二维码地址。我们获取扫码时间scancode_time与页面onload执行时间，两者相差了6万多秒，安卓，ios都偶尔会出现该问题 - 预期表现 之前听一个大佬说这个问题在微信新版本已经解决，但是目前偶尔还是会出现 - 复现路径 - 提供一个最简复现 Demo 代码： [图片] 日志： [图片]

目前微信扫普通二维码进入小程序，可以获取扫码时间scancode_tim这个参数，我们在加载页面是会比较扫码时间scnacode_time和onload执行时间的时间差，发现有时候（频率不低）两个时间会差几百秒，我们的页面加载并不慢，想问一下，什么原因会导致两个时间相差这么多？ 代码截图： [图片]

小程序后台的运维中心中的加载性能监控中，可以看到启动总耗时、初次渲染耗时、下载耗时的统计。 后两个都很好理解，但启动总耗时到底怎么算，有些疑惑。 从用户点击进入小程序开始计算，到小程序界面首次渲染完毕的耗时，单位毫秒，中间包含代码包下载（非首次启动则不需下载）、代码执行、渲染等耗时 代码包下载好理解，这个代码执行，是生命周期方法中的代码吗？还是包含了其中调用的异步代码的执行时间？是启动页的代码执行，还是所有页面都需要初始化后加载到内存中？ 渲染是指初次渲染吗？还是指用户无操作情况下页面内容不变时刻之前的所有渲染？ 因为最近在首页加了个异步查询后展示悬浮图片的功能，导致了启动总耗时上升比较明显（不是发版后的骤升，而是发版后几天稳定下来的启动总耗时），所以才有此疑问。 另外，在首页功能不变，后面加了几个页面时，也会有这种现象。 请了解这块计算方式的同学帮忙解惑下，谢谢 另外，大家有感觉API页面改版后，用的不习惯吗？原来一个类的属性和方法，一个页面就能看完，现在分成N个，菜单还是不连续的。比如说InnerAudioContext。 [图片]

根据小程序运营规范5.3内容： “对于有其他主要功能的小程序，分享获利只是活动促销手段的，不视为网 zhuan。” 1、本小程序主要功能为向用户提供优质的朋友圈热文，用户在我们的小程序里主要行为是阅读文章。  2、引导用户分享文章只是小程序活动推广的手段，并且没有诱导用户作任何下载其他 APP或者进入其他小程序的功能。截图内引导下载趣头条的广告为小程序官方广告。 3、所设计的任务也全部为为了增加一起看趣闻小程序用户活跃度。 我们的诉求： 我们承认在描述上出现转发、分享的字眼，这是我们的不当，但也仅限于推广我们自己的小程序，希望用户觉得好的话多分享给其他好友，并没有强制分享，不至于永久封禁。 希望能够指出具体哪部分文案或者功能有问题，可以让我们进行修改。也为以后我们在小程序生态内耕耘有经验与教训。 请求官方大大重新审核，给与我们整改机会！ [图片] [图片][图片][图片]

- [图片] 用户反馈打开小程序白屏。 上周就有用户反馈该问题，上周有上线分包代码。我们排查下来认为是分包导致，就回滚了分包代码 但是又有用户反馈打开白屏，后台查询了用户操作日志，发现未有任何操作记录。系统信息：iphone7 plus  微信版本6.6.5

- 最近审核很慢，之前基本都是当天就过了 - 希望赶紧帮我们审核一下 [图片]