这是本月第二次被暂停服务了，电商cps类接入的京东等平台，也准备接入小程序联盟，如果一直是这样，这种业务还有没有办法做，芬香这些同样的业务一点问题都没有 你好，因用户投诉并经平台审核，发现帐号已发布的服务涉及帐号无实质内容及服务，且主要目的为其他帐号进行推荐、推广、导流等行为 违反规范：《微信小程序平台运营规范》5.行为规范-5.10互推行为 违规内容：小程序内含有对微信小程序进行排行或集中设立跳转、添加平台服务。 请遵守规范，修改内容或行为后可重新发布服务。如果再有违规情况，将加重处罚至永久下线服务或封禁帐号处理。如有异议，可点击申诉。 对上述内容无法理解，可点击进入客服咨询

小程序今天被投诉举报含有虚拟支付和应用排行互推行为，小程序内容无任何虚拟支付内容，该小程序做的是跳转美团小程序，进行领取外卖红包，并没有对应用设置集中跳转，排名等情况，该小程序在16日被同问题下架处理，21日申诉审核通过后，由于昨日被同样的问题下架处理。 [图片] [图片][图片]

前天 我们的导购返利 小程序 被用户投诉为由，遭微信单方面停用了，给用户带来极大不便和损失，严重损害了开发者的感情。两次申诉都被拒了，我们不得已现在才发帖求助。 > 你好，经核实，小程序该线上版本仅提供电商类小程序商品价格详情展示并导流至相关小程序进行购买，平台暂不支持做纯导流、无实质内容的运营内容，请自觉遵守国家相关法律法规，不从事违法或违反《微信小程序平台运营规范》及相关规则的内容和行为，谢谢。 [图片] [图片] 1：关于违规跳转（小程序内含有对微信小程序进行排行或集中设立跳转、添加平台服务。） 导购小程序肯定是要跳转到第三方领券下单，这个跳转是对跳转接口的正常合规使用，跳转互动是良好小程序生态的重要一环，怎么能算是违规集中跳转，和互推行为呢？https://developers.weixin.qq.com/miniprogram/product/#_5-10-互推行为 2：平台暂不支持做纯导流、无实质内容的运营内容 我们有用户体系，等级体系，订单管理，有团队分销体系，有社群运营，后续还有商品价格监控等服务，怎么能算是纯导流呢，我们 是 报价/比价 类目，微信官方 有这个类目的，很多 比价小程序不都是这样的，怎么算是 无实质运营内容呢 二次申诉还是不通过，那么 芬香 这些 所有的导购程序 不都是这种吗，为什么他们可以！！！！ 请官方公正对待，认证审核，不忘初心，诚信友善，切勿破坏微信小程序健康的生态！

你好，因用户投诉并经平台审核，你的小程序涉及帐号无实质内容及服务，且主要目的为其他帐号进行推荐、推广、导流等行为行为，服务已被下线处理。请参照《小程序平台运营规范》修改内容。 违规内容 小程序内含有对微信小程序进行排行或集中设立跳转、添加平台服务 1，首先我们没有做“排行或集中设立跳转、添加平台服务”等动作； 2，我们本来就有自营售卖与对接京东、拼多多等平台cps，市场上所有都是这么做的，为什么就说我们违规； 希望官方能解答

这篇文章主要是解决小程序无限滚动瀑布流页面引起的ios内存不足，自动退出问题 问题回顾：我们有一个列表展示页，是无限瀑布流式的，展示的元素我们封装成了单个组件，暂且叫它[代码]Item组件[代码]。这个瀑布流包含若干个Item组件，并且这个Item组件也比较复杂，包含各种展示样式（根据不同类型，大概有9种吧，反正渲染节点很多），在进行滑动的过程中，item大概加载30-40个以后，就会造成小程序内存不足而退出，蓝瘦香菇… 点击此处查看二期 解决思路： 将超出屏幕一定部分的列表内的组件进行不渲染的处理（也就是用wx:if卸载掉组件），当到达渲染临界点时再开始渲染；保证每次少量的数据展示。 我们的项目中是保持15条Item，我们是每次分页请求5条，按照前5条，中间5条和后5条来划分，如果不在这个范围，则用一个等高度的骨架代替，并且卸载这些组件 实现方式 使用曝光监听，当一个Item曝光时，记录Item高度，并放到数组里面，作为骨架的填充高度，如果已经记录了高度，则不再重复记录；曝光时向外传递一个当前渲染范围的中心值（比如当前Item所属页码，或者当前Item索引），以此进行处理； 这里有一点要注意，如果你的列表item组件比较复杂，需要在ready的时候将记录的高度设置为item最小高度，不然组件重新装载时会有一定的渲染时间，在临界点会造成跳屏【此处已经通过骨架组件解决，可以忽略，只是作为踩坑记录】 此时优化点 为避免频繁setData和渲染，做了防抖函数，时间是600ms 此时缺点 滑动特别快时，会出现白屏，是因为曝光监听是在组件里面，而超快速滚动时，组件没有装载进来，也无法进行曝光监听，所以无法触发，这里考虑用骨架组件进行二次监听曝光 优化迭代 将骨架组件作为外壳套在Item外面（用[代码]slot[代码]），并对骨架进行监听曝光，可以解决上面缺点 给骨架组件做一个常规骨架屏样式，而不是纯白色，看起来更优雅 最后，还是尽量减少节点数，优化代码

#场景： 页面是不断上拉加载的数据流，不断地加载造成页面长列表， 情况类似使用的新闻app的数据加载方式。 结构示意： [图片] #问题： 此时进行页面渲染后，滑动页面出现卡顿现象， ios（6s）在超过10页轻微出现延迟， 安卓直接3-4页出现卡顿， 再往后直接延迟3、4秒才响应滑动，直到页面有5、6秒的延迟就操作不动。 #当前情况： 1、setdata已做优化，避免使用concat，采用分段，先占位（分页级别），再渲染。 setdata({ list[page]:datalist }) 2、列表的dom结构不一样，有单图组合文字、3图组合文字、有单张大图 [图片] 3、滑动区域没有使用scroll-view组件 不知社区内是否有类似情况，且有解的朋友。

关于发布，帮别人代做的小程序，做好以后怎么变成别人的小程序。 目前我是个人用户开发的，不懂开发完成后怎么交付别人，请各位前辈帮忙解释一下小弟万分感谢

我们是小程序第三方服务平台，主要为客户提供通用小程序解决方案，碰到几个问题，请问有没有便捷的方式 1、小程序申请注册有没有便捷方式，现在收集各个客户资料登录微信公众平台替客户逐个去申请注册的 2、小程序更新有没有便捷的方式，现在是更新了一个小程序然后登录各个客户的微信公众号平台去手动发布的 目前小程序注册、发布更新都是通过人工的方式进行操作，效率比较低，有没有便捷的方式；如100个客户就要操作100次

- 需求的场景描述（希望解决的问题） TabBarBadge不能自定义颜色 不能像QQ那样拖动点删除 - 希望提供的能力 自定义颜色 拖动删除，同时有删除回调 这样就比较灵活了，例如可以轻松实现拖动删除消息点，同时利用回调可以“标记所有消息为已读”等功能。