小程序AppID: wx718700a474b4fa75 我们有一个用户最近小程序一打开就黑屏，有时候连微信也一并闪退。麻烦官方人员看下微信的日志。 用户ID：wxid_nzhjckv3ta3822 手机型号：OPPO PBAM00 日志时间：2019-07-29 最近一次黑屏发生的时间：2019-07-29 18:20

- 需求的场景描述（希望解决的问题） 新建一个代码片段，一行代码不写，在手机上预览，打开性能监控面板，内存消耗就有200M左右，从这点来看，小程序可一点都不“小”。 现在不少安卓手机还是4G以下的内存，本身内存就是很容易吃紧的，小程序这一上来就几百兆的内存，很容易就因为内存不足发生黑屏、闪退等问题 -- 我们目前还没有多少用户，就已经收到不少相关问题的反馈了。 - 希望提供的能力 能不能从底层优化一下，减少小程序的内存消耗，让小程序真的“小”？

- 需求的场景描述（希望解决的问题） 有一些用户跟我们反馈小程序黑屏和闪退问题，我们首先怀疑是内存消耗异常导致的。找用户帮忙测试了，在确认手机可用内存大于2G的情况下测试（我们的小程序内存正常使用范围在200M~500M之间），仍然有问题，于是进一步怀疑小程序在用户的手机上内存消耗存在异常（消耗了过大的内存），然后为了确认，我们需要给用户开通开发版权限，然后教用户怎么打开“性能监控面板”，再教用户怎么录屏…… 我们的用户年龄偏大，对手机的使用不像年轻人那么熟练，学习成本非常高，尽管很多用户很友好很有耐心配合我们，但是花的时间太长，对我们和用户都是一个不小的负担。如果有API能够直接获取内存使用情况，我们直接代码里监控就行了，顶多让用户提交一下意见反馈把日志上传上来。 - 希望提供的能力 希望提供一个API，能够获取到小程序当前的内存（RAM）使用情况，以便于我们分析定位黑屏、闪退问题是否和内存有关。 只要安卓系统有这个接口可用就行，目前我们出问题的主要是安卓机。

从2.7.3开始，支持选择器后，如果想使用选择器，就不需要设置scrollTop，而且如果同时设置scrollTop和selector，貌似scrollTop优先级更高一些。而文档里依然说scrollTop是必填的，容易造成误解。 https://developers.weixin.qq.com/miniprogram/dev/api/ui/scroll/wx.pageScrollTo.html [图片]

文档里说可以在其它组件里使用editor导出的html，要额外引入一段样式，可是给的样式是css，在小程序里根本没法用。难道这里说的“其它组件”并不是小程序中的组件，比如rich-text？ editor组件导出的html，如果能用在rich-text中，样式差异（比如图片不会宽度自适应）怎么解决？ [图片]

我们做的是一个朗读工具，用户在上面可以对着素材（我们提供了一部分，用户也可以自己添加）朗读，朗读录音可以发布出来给别人听，也能转发给好友。服务类目“生活服务-休闲娱乐”我们都用了快一年了，这两天改了点bug发了新版，审核的时候，要我们添加“社交-笔记”这个服务类目，可我们小程序提供的服务和笔记根本没关系呀。已经连续拒了我们三次了，烦请官方人员帮我们核查一下。 和我们同类的小程序，如“优谷朗读”、“明兮朗读”等，也都没有“社交-笔记”这个类目。

wx.request的报错信息： request:fail request unknow host error 应该是unknown host吧，希望能改正，不然搜索的时候还得刻意去注意不要加n，很难受。

富文本编辑器中插入图片，目前图片地址仅支持 http(s) 和 base64 格式，使用起来不是很方便。能否放开限制，支持显示本地图片？ 理由： 1. 这个限制的初衷可能是为了确保开发将图片上传，避免保存后图片无法显示的情形。这个问题很容易注意到，开发人员应该都知道原因和怎么解决； 2. 因为这个限制，用户编辑过程中操作的所有图片我们都必须上传到服务器上（上传是首选。虽然转成base64就可以不上传，但如果要存入数据库，还是很有顾虑，手机照片一般都比较大），会造成一些不必要的开销：     a) 一些图片插入后可能又被删掉了，或者插了很多图片最后放弃编辑了，这样的图片是没必要上传的，白白浪费存储空间；     b) 上传链接一般需要请求服务端获取（不然谁都可以上传，不安全），添加一个就要请求一次，不是很有效率。 3. 如果能够去掉这个限制，支持显示本地图片，那就可以在添加图片的时候暂时显示本地图片，图片路径先记录下来（如果图片删掉了，图片路径也从记录中删除），等到保存时，一次性请求所有图片的上传链接，然后批量上传，并替换掉html中的图片路径就可以了。 -- 虽然这样在图片比较多时要多花些时间保存，但大部分情况下我觉得是更合理的。 -- 同一个图片插入两次，临时路径是不一样的，可以用个map<filePath, md5>记录路径和md5的对应关系，用md5获取上传链接，同一个md5的图片只上传一次。虽然当前情况下也能这样做，但如果能先显示本地图片，会更方便。 具体采用哪种实现方式，希望能把这个选择权交给小程序开发人员。

希望能提供判断用户当前是否插入了耳机的API. 我们的应用场景是这样的：用户在录音的时候可以添加配乐，如果戴了耳机，那录音里是不包含音乐的，录完后我们通过服务端处理把音乐给加进去；如果没戴耳机，那录音里就包含了音乐了，我们就不能再把音乐再加一遍，不然极有可能出现音乐重声的情况（录进去的音乐时间轴和后期加进去的音乐时间轴很难对齐）。 社区里其他开发者提这个需求的应用场景也差不多，都是要基于是否戴耳机来决定不同的处理逻辑。 我把这两年相关的帖子汇总了一下，还是有不少人需要这个功能的，希望官方能够再考虑下是否提供支持： https://developers.weixin.qq.com/community/develop/doc/00004e5e600480171b4757f0d56000?highLine=%25E8%2580%25B3%25E6%259C%25BA [图片] https://developers.weixin.qq.com/community/develop/doc/0002a277138838d847f61f49e51400?highLine=%25E8%2580%25B3%25E6%259C%25BA [图片] https://developers.weixin.qq.com/community/develop/doc/000a80629706e8ef1f882886951800?highLine=%25E8%2580%25B3%25E6%259C%25BA [图片]

AppID: wx718700a474b4fa75 陆陆续续有一些用户跟我们反馈说，录音会出现丢失一些片段的现象，举例来说：我读的是“一二三四五六七八九十”，但是录音只录下来“一二三四八九十”，中间少掉了“五六七”。 这个问题很低频，但是后果很严重，因为录音是我们的核心功能，一旦出问题非常影响用户体验。 以下是一个丢失片段的录音： https://resources-1257265876.cos.ap-beijing.myqcloud.com/debug/片段丢失.mp3   大概36-38秒的位置 读的文本，出问题的那一段用红框标记出来了： [图片] 当时录音的日志： 2019-6-30 11:31:10 [info] [1561865470393]recorder.onStart 2019-6-30 11:31:13 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51346 2019-6-30 11:31:17 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51400 2019-6-30 11:31:20 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51293 2019-6-30 11:31:23 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51440 2019-6-30 11:31:26 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51497 2019-6-30 11:31:29 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51234 2019-6-30 11:31:33 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51434 2019-6-30 11:31:36 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51565 2019-6-30 11:31:39 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51791 2019-6-30 11:31:42 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51999 2019-6-30 11:31:46 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51716 2019-6-30 11:31:50 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51789 2019-6-30 11:31:53 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51409 2019-6-30 11:31:57 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51840 2019-6-30 11:32:0 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=52079 2019-6-30 11:32:3 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51587 2019-6-30 11:32:6 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51833 2019-6-30 11:32:10 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51820 2019-6-30 11:32:13 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=51828 2019-6-30 11:32:15 [info] [1561865470393]record.onFrameRecorded: frameBuffer.byteLength=30560 2019-6-30 11:32:15 [info] [1561865470393]recorder.onStop: {"duration":63160,"tempFilePath":"wxfile://tmp_59d985983a4db736e1086cb8116425146d2797d9678ec73b.mp3","fileSize":1011460} 2019-6-30 11:32:15 [info] [1561865470393]wxfile://tmp_59d985983a4db736e1086cb8116425146d2797d9678ec73b.mp3 size: 1011460, MD5: 9fe80e2d49da918497e2fcc2044a1bcf