css能力都阉割，单纯增加开发成本？

[图片] 每次提交审核都备注了对内小程序，也给了多个测试账号，还是一直被拒绝。

[图片] 每次搜索 测试 相关的，都是没内容。 屏蔽了 测试 关键词？

移动网络下：微信聊天发送位置定位OK，小程序定位失败 wifi情况下：微信聊天定位和小程序定位都正常 其间除了是否连wifi，没有修改任何其他设置

Component({ data: { dtest: 'dtest' }, ptest: 'ptest', lifetimes: { created() { this.test = 'test' console.log({ time: 'created', dtest: this.data.dtest, // dtest ptest: this.ptest, // undefined test: this.test // test }) }, }, }) [图片] 这种方式的初始化不会生效 代码片段：https://developers.weixin.qq.com/s/EsM0cVmI7Pm7

小游戏支持wx.onTouchStart，小程序有计划支持wx.onTouchStart嘛

page.onReachBottom = () => { comp.onReachBottom(); if (oldOnReachBottom) { oldOnReachBottom(); } }; 问题表现：上述方式更新页面触底监听函数，在页面没有声明onReachBottomde事件的时候不生效，只有页面声明onReachBottom再赋值才会生效。 预期：不管Page构造函数是否声明onReachBottom，page.onReachBottom都应该被触发 代码片段：https://developers.weixin.qq.com/s/4TceyFme7Zmm 对比： [图片] [图片]

已经提供代码片段，在input里输入1个字，点击下方4444，再次聚焦input，光标位于4|444 自测iphone可以复现

graphql可以有效的减少请求，快捷处理请求依赖等问题。 小程序云开发什么时候可以支持graphql呢

问题描述鲸营宝小程序在ios系统，切换数据看板有闪退情况 安卓设备暂无此类问题；ios机型，切换看板的速度影响小程序闪退； 初步判断是内存占用过高导致微信客户端闪退（部分机型会弹出内存告警的弹窗）。   目前正在尝试的解决办法优化看板数据请求方式、优化数据页状态管理姿势（合并数据setState引起的多次重渲染）、优化看板的渲染逻辑（合并多次渲染、手动取消数据变化没变化部分的渲染），优化canvas的渲染逻辑，减少canvas的绘制动作、和内存的消耗。 分析经过大量优化操作（优化请求更新状态、优化状态管理、优化kbone-canvas的绘制逻辑、合并状态更新、对比数据在必要时更新canvas等），减少canvas的绘制次数后，ios闪退的概率大大下降小程序社区中也有 原生开发+echarts、f2 发生闪退的情况https://developers.weixin.qq.com/community/develop/doc/0006c23c14471095fd1ac32bc5b400?highLine=canvas%2520%25E9%2597%25AA%25E9%2580%2580 https://developers.weixin.qq.com/community/develop/doc/000e6ea89289f0528f99552f556400?highLine=canvas%2520%25E9%2597%25AA%25E9%2580%2580 https://developers.weixin.qq.com/community/develop/doc/000a6c0d9fc8008f572a0a08f51c00?highLine=canvas%2520%25E9%2597%25AA%25E9%2580%2580 https://developers.weixin.qq.com/community/develop/doc/000c60f9c38e50c93d7a6ed695b000?highLine=canvas%2520%25E9%2597%25AA%25E9%2580%2580 等等   综上，得出大概率是因为ios小程序原生canvas有内存泄露的逻辑，并不是F2、echarts的问题，在优化逻辑减少canvas绘制次数后 闪退复现次数大大下降 也可佐证此结论