为什么不能频繁 setData 先科普下 setData 做的事情： 在数据传输时，逻辑层会执行一次 JSON.stringify 来去除掉 setData 数据中不可传输的部分，之后将数据发送给视图层。同时，逻辑层还会将 setData 所设置的数据字段与 data 合并，使开发者可以用 this.data 读取到变更后的数据。 因此频繁调用，视图会一直更新，阻塞用户交互，引发性能问题。 但频繁调用是常见开发场景，能不能频繁调用的同时，视图延迟更新呢？ 参考 Vue，我们能知道，Vue 每次赋值操作并不会直接更新视图，而是缓存到一个数据更新队列中，异步更新，再触发渲染，此时多次赋值，也只会渲染一次。 [代码]let newState = null; let timeout = null; const asyncSetData = ({ vm, newData, }) => { newState = { ...newState, ...newData, }; clearTimeout(timeout); timeout = setTimeout(() => { vm.setData({ ...newState, }); newState = null }, 0); }; [代码] 由于异步代码会在同步代码之后执行，因此，当你多次使用 asyncSetData 设置 newState 时，newState 都会被缓存起来，并异步 setData 一次 但同时，这个方案也会带来一个新的问题，同步代码会阻塞页面的渲染。 同步代码会阻塞页面的渲染的问题其实在浏览器中也存在，但在小程序中，由于是逻辑、视图双线程架构，因此逻辑并不会阻塞视图渲染，这是小程序的优点，但在这套方案将会丢失这个优点。 鱼与熊掌不可兼得也！ 对于信息流页面，数据过多怎么办 单次设置的数据不能超过 1024kB，请尽量避免一次设置过多的数据 通常，我们拉取到分页的数据 newList，添加到数组里，一般是这么写： [代码]this.setData({ list: this.data.list.concat(newList) }) [代码] 随着分页次数的增加，list 会逐渐增大，当超过 1024 kb 时，程序会报 [代码]exceed max data size[代码] 错误。 为了避免这个问题，我们可以直接修改 list 的某项数据，而不是对整个 list 重新赋值： [代码]let length = this.data.list.length; let newData = newList.reduce((acc, v, i)=>{ acc[`list[${length+i}]`] = v; return acc; }, {}); this.setData(newData); [代码] 这看着似乎还有点繁琐，为了简化操作，我们可以把 list 的数据结构从一维数组改为二维数组：[代码]list = [newList, newList][代码]， 每次分页，可以直接将整个 newList 赋值到 list 作为一个子数组，此时赋值方式为： [代码]let length = this.data.list.length; this.setData({ [`list[${length}]`]: newList }); [代码] 同时，模板也需要相应改成二重循环： [代码]<block wx:for="{{list}}" wx:for-item="listItem" wx:key="{{listItem}}"> <child wx:for="{{listItem}}" wx:key="{{item}}"></child> </block> [代码] 下拉加载，让我们一夜回到解放前 信息流产品，总避免不了要做下拉加载。 下拉加载的数据，需要插到 list 的最前面，所以我们应该这样做： [代码]this.setData({ `list[-1]`: newList }) [代码] 哦不，对不起，上面是错的，应该是下面这样： [代码]this.setData({ list: this.data.list.unshift(newList) }); [代码] 这下好，又是一次性修改整个数组，一夜回到解放前… 为了解决这个问题，这里需要一点奇淫巧技： 为下拉加载维护一个单独的二维数组 pullDownList 在渲染时，用 wxs 将 pullDownList reverse 一下 此时，当下拉加载时，便可以只修改数组的某个子项： [代码]let length = this.data.pullDownList.length; this.setData({ [`pullDownList[${length}]`]: newList }); [代码] 关键在于渲染时候的反向渲染： [代码]<wxs module="utils"> function reverseArr(arr) { return arr.reverse() } module.exports = { reverseArr: reverseArr } </wxs> <block wx:for="{{utils.reverseArr(pullDownList)}}" wx:for-item="listItem" wx:key="{{listItem}}"> <child wx:for="{{listItem}}" wx:key="{{item}}"></child> </block> [代码] 问题解决！ 参考资料 终极蛇皮上帝视角之微信小程序之告别 setData, 佯真愚, 2018年08月12日

小程序客服移动端终于来了？ 几天前，一个叫做「客服小助手」的小程序被扔进晓程序观察（yinghoo-tech）的粉丝群中，打开小程序，发现它的定义是“帮助小程序在移动端为用户提供客户服务的工具”，可以简单理解为小程序客服的移动版，主体是腾讯公司，官方出品无误。 [图片] 一石激起千层浪，群里的开发者们对此纷纷叫好，因为之前客服功能只能在PC端使用，这一次终于在移动端实现了。 不过，当晓程序观察测试一番之后，发现这款小程序依然有很多尚待优化的地方，且待我们细细说来。 把商家从电脑前“解救”出来 都说微信是基于移动端而生，但微信小程序的客服却只能在PC端使用，这一点实在有些“反人类”。 尤其对于中小团队而言，还得专门让运营守在电脑前，否则很容易耽误了消息回复，这令大家叫苦不迭。 [图片] “我们这些商家，做小程序目的就两个：带来客人与减少工作量，但小程序是把客人带来了，工作量反而增加了，因为客服只能在电脑上实现，我们既要当老板，又要当客服，实在是麻烦。”从事婚纱摄影多年的周立波说到，他做了一款小程序「全球婚纱摄影」，常常有人用客服进行咨询。 因此，许多客服需求旺盛的小程序，诸如电商、二手交易、知识付费等等，都只能选择第三方提供的客服服务，这对于恨不得把一块钱掰成两半花的小团队而言，又是一笔额外支出。 「客服小助手」正是冲着这个痛点而来。 有趣的是，它其实早在今年1月就注册了，当时叫做“门店客服助手”，直到3月4日才改名为“客服小助手”。 我们推测，一开始「客服小助手」的服务对象是门店小程序，因为门店小程序无法接入第三方客服。 确实，微信团队如此回复我们： “「客服小助手」的升级主要是为了方便小程序开发者在移动端及时回复客服消息，提升服务质量与用户体验。小程序的定位也随之发生变化，可适用于所有小程序的客服服务。” 所以现在它已经全面开放，大家可以通过文末的小程序码体验一下。 整体上看，「客服小助手」的功能与PC端比较相似，商家进入小程序后，先选择与自己账号绑定的小程序，之后会提示“客服小程序申请向你发送服务通知”。 [图片] 商家同意后，只要有用户在小程序客服里留言，「客服小助手」就会推送一条服务通知给商家，商家点击进入小程序与用户交流。 在这里，「客服小助手」用上了“订阅消息”的能力，我们曾解读过该能力的特点是一次订阅，无限次推送。 之前曾有人理解为用户会无限次收到客服的消息，其实是反过来，是客服会无限次收到用户的消息。当然，如果有特殊情况，商家不想再收到通知，可以在小程序里选择“离线”，这一点与PC端一致。 [图片] 首次打开小程序时，会自动接入以前的客服消息，客服可以在48小时内和用户对话，后续有新的客服消息，会在对话框顶部显示。 [图片] 如果有多位客服同时在线，第一个客服接收信息后，其他客服不会再接收到信息。客服消息会随机分配到在线客服。 这就是「客服小助手」简单的使用逻辑，此后商家可以直接在移动端与用户进行交流，彻底从电脑前解放出去。 「客服小助手」仍需打磨 然而，「客服小助手」与PC端体验类似的另一层含义是： 过去PC端小程序客服的诸多缺点，在移动端依旧存在。 首先，每次只能“登录”一个小程序，假设你绑定了多个小程序，也只能接收到已登录小程序的用户留言。 [图片] 这里的问题是，现在很多团队都是矩阵化打法，拥有几十个小程序，现在「客服小助手」只能登陆一个，可真是让客服分身乏术了。 其次，精品店客服在线功能与「客服小助手」并不互通，很多小商家申请了自己的精品店，使用了精品店提供的“客服在线”功能，但有商家对我们，绑定了“客服在线”，就无法使用「客服小助手」，收不到消息。当他想解绑“客服在线”时，也找不到解绑入口，这也值得注意。 另外，从我们的测试来看，在发送消息以及解绑时，都会有信息延迟，甚至出现过已经解绑了小程序，还收到了用户留言，这说明「客服小助手」还有很多值得优化的空间。 有商家吐槽，「客服小助手」乍一看很惊喜，但研究之后才发现“虽然我们会用，但功能太简单，太基础了，还不如直接跟用户加好友。” 企业微信与「小助手」如何选择？ 当然，「客服小助手」纵有种种缺点，却也在移动端开了一个口子，给予了商家极大方便。 有小伙伴发问，不久前，我们曾推文表示，企业微信2.7.5版本中的“联系我”功能，也可以让企业微信化身移动端的小程序客服。 那么，企业微信与「客服小助手」有什么区别？商家该如何选择？ 首先可以肯定，企业微信比「客服小助手」功能更强大。 在之前的文章中，我们提到只要在小程序里放置“联系我”的按钮，用户就可以加上客服的企业微信，之后企业微信的种种强大功能就派上用场了。 比如，企业微信可以给用户打上标签，此后如果该用户再次询问，就知道他购买过什么，对什么感兴趣，最关心的点在哪里，由此更有针对性地进行回答。 另外，企业微信还可以直接给用户发小程序，推荐商品，促进转化，这些都是目前「客服助手」尚不具备的。 可以看到，企业微信会帮助商家与用户之间就建立起了强连接，有助于后续的进一步营销。 至于「客服小助手」，虽然微信团队表示此后会逐步开放“对多客服转接”功能，聊天记录同步功能也已经实现，但运营规则规定，用户每一次发问，客服只能最多回复5条消息。这就注定了「客服小助手」强调即时交流，短时间内为用户答疑解惑。 所以，我们可以由此判断： 企业微信更适合有一定用户规模，想要与用户建立长期强连接的小程序，比如，为特定的用户提供长期的咨询服务，类似「微保」的个人保险管家服务。 [图片] 而「客服小助手」适合用户规模较小，咨询任务不重，主要以即时沟通为主的小程序。 可以看到，微信正在一步步完善小程序的使用体验，但这里有个有趣的话题：原来这些因为小程序功能不够完善而产生的商业机会，会不会被微信自己补上？ 比如原来客服功能不完善，遂诞生了以「芝麻小客服」为代表的第三方客服服务商，这下「客服小助手」的推出，会对这些第三方产生什么影响？ 「芝麻小客服」的产品运营耳朵认为，这反而是一件好事。 “官方重视移动端的客服，说明这个方向是对的，有需求。而且官方参与进来后，也能够有效阻止一些围观者，倒逼我们进一步打磨产品。当然，目前官方的客服功能比较简单，而我们支持自动回复，多客服转接，平台客服等等，需求程度不同。”耳朵说到。 看来答案也很清晰，微信只提供最基础的工具，而第三方要做的是在工具之上封装的多功能与服务，满足更深层次需求的商家，这里面，才会诞生真正的商业机会。 最后，放上小程序码： [图片]