审核类型：代码审核 审核时间：2019-11-05 19:02:00 被拒原因：宝宝巴士装扮小公主小游戏内容涉嫌代码包内容侵权（被侵权游戏名称：奇奇消消乐） 申诉理由：二次申诉提审时，我们已提供了相关的原因说明如下 这两个产品是同一个团队开发运营的，都是使用Cocos Creator引擎，以及基于Cocos Creator之上封装的一套基础框架（包含基础跳转、网络请求、导量位等组件）。虽然是不同主体，但是产品本身的核心逻辑代码与UI，都是完全不同的。仅仅由于编译后的代码中，引擎及基础框架占了大部分，就判断侵权，这明显不合理。 从这两款产品的成员管理中，也可以发现人员是高度重合的。 如果说判定宝宝巴士装扮小公主侵权了奇奇消消乐，那如果我们能够以奇奇消消乐的账号提供指定的证明奇奇消消乐不认为宝宝巴士装扮小公主侵权了自身，是否就可以了？

审核类型：代码审核 审核时间：2019-11-05 19:02:00 被拒原因：宝宝巴士装扮小公主小游戏内容涉嫌代码包内容侵权（被侵权游戏名称：奇奇消消乐） 申诉理由：二次申诉提审时，我们已提供了相关的原因说明如下 这两个产品是同一个团队开发运营的，都是使用Cocos Creator引擎，以及基于Cocos Creator之上封装的一套基础框架（包含基础跳转、网络请求、导量位等组件）。虽然是不同主体，但是产品本身的核心逻辑代码与UI，都是完全不同的。仅仅由于编译后的代码中，引擎及基础框架占了大部分，就判断侵权，这明显不合理。 从这两款产品的成员管理中，也可以发现人员是高度重合的。 如果说判定宝宝巴士装扮小公主侵权了奇奇消消乐，那如果我们能够以奇奇消消乐的账号提供指定的证明奇奇消消乐不认为宝宝巴士装扮小公主侵权了自身，是否就可以了？

- 当前 Bug 的表现（可附上截图） 后台更新后，原有的体验权限全都没了，项目成员在开发者助手小程序中都看不到体验版小程序。 [图片] - 预期表现 按照这个网页的说明，http://kf.qq.com/faq/170302zeQryI170302beuEVn.html，项目成员是应该有体验者权限的，可以在小程序开发助手中看到体验版的小程序。 [图片] - 复现路径 打开小程序开发助手，查看任意小程序 - 提供一个最简复现 Demo

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

通过基础库1.6.0以后提供的wx.getRecordManager接口返回的recordManager对象进行录音。 当用户手机熄屏或者通过分享切到其他页面（非当前小程序）时， 1、如果我们在页面的onHide里调用了recordManager的pause或stop方法，微信会立即报错，operateRecorder:fail:access denied。后面只要不重启小程序，即使再次通过wx.getRecordManager获取recordManager对象调用其start方法，也会立即报错，无法录音。 2、如果在页面的onHide里不去调stop方法，不会报错，回来后继续录音。但是等到最后调用stop时，在onStop里返回的录音文件发现，第一次onHide后录的所有内容，都没有保存。 我们现在真的有点纠结，是继续用微信新的wx.getRecordManager还是回去用来老的wx.startRecord与wx.stopRecord呢？ 请尽快给个答复吧。 报错截图如下 [图片]

1、当小程序处于后台情况下，如果通过微信的音乐播放控制去停止播放（包括安卓通知栏的×和全屏音乐播放控制下暂停后微信自动停止播放），都不会回调到小程序。而如果仅仅是通过通知栏进行暂停，即使小程序在后台，还是有回调的，只是后续的停止不会回调。 2、在以上情况下回到小程序后，在app的onShow方法里去查询wx.getBackgroundAudioManager()的url、paused、currentTime等参数： 在开发者工具中，会正确重置成url为undefined，paused为true，currentTime为0，即无歌曲在播放状态； 在远程调试（开发版）情况下，url为undefined，paused为true，currentTime却为停止时的时间； 而在体验版情况下，url为null，paused为false，currentTime却是切后台的时间。 三种环境，三种情况，这让我们如何开发？ 从现象上看，是当小程序处于后台的时候，微信没有将播放器的状态改变正确同步到小程序js中的BackgroundAudioManager中。 开发者工具的行为是正确的，微信自身什么时候能把这些bug修复呢？

最近写了一个音频播放相关的小程序，用innerAudioContext进行音频的播放。 发现小程序中的onStop回调与调用stop方法可能是异步。 现象是： 我们在一个触摸事件回调函数A中调用了stop方法停止当前音频播放，然后设置一些属性（不是在data里，是page中定义的customData区域）。 结果发现，有一定的概率，onStop回调的时候，前面那个函数的设置属性的代码还未执行。 在浏览器中，js是单线程事件模型的，即使有回调，也会等到函数A执行完毕，才执行onStop回调，而不会A执行一半，插入onStop进行执行。 如果onStop是与stop方法同步执行的，那应该在stop执行完毕之前，onStop就回调了。但我们实际监测到的情况却是，大概率情况下是在A函数执行完毕后才回调，也就是说是异步回调的。 请问一下微信小程序框架的工程师，音频回调的线程模型到底是什么样的？ 为什么有的时候回调先执行，有的时候后执行？（难道是多线程？那什么时候会提供加锁机制？）