1.背景 如今信息流业务是各大互联网公司争先抢占的一个大面包，为了提高用户的后续消费，产品想出了各种各样的方法，例如在微视中，用户可以无限上拉出下一条视频；在知乎中，也可以无限上拉出下一条回答。这样的操作方式用户体验更好，后续消费也更多。最近几年的时间，微信小程序已经从一颗小小的萌芽成长为参天大树，形成了较大规模的生态，小程序也拥有了一个很大的流量入口。 2.demo体验 那如何才能在小程序中实现类原生APP效果的下一条无限刷体验？ 这篇文章详细记录了下一条无限刷效果的实现原理，以及细节和体验优化，并将相关代码抽象成一个微信小程序代码片段，有需要的同学可查看demo源码。 线上效果请用微信扫码体验： [图片] 小程序demo体验请点击：https://developers.weixin.qq.com/s/vIfPUomP7f9a 3.实现原理 出于性能和兼容性考虑，我们尽量采用小程序官方提供的原生组件来实现下一条无限刷效果。我们发现，可以将无限上拉下一篇的文章看作一个竖向滚动的轮播图，又由于每一篇文章的内容长度高于一屏幕高度，所以需要实现文章内部可滚动，以及文章之间可以上拉和下拉切换的功能。 在多次尝试后，我们最终采用了在[代码]<swiper>[代码]组件内部嵌套一个[代码]<scroll-view>[代码]组件的方式实现，利用[代码]<swiper>[代码]组件来实现文章之间上拉和下拉切换的功能，利用[代码]<scroll-view>[代码]来实现一篇文章内部可上下滚动的功能。 所以页面的dom结构如下所示： [代码]<swiper class='scroll-swiper' circular="{{false}}" vertical="{{true}}" bindchange="bindChange" skip-hidden-item-layout="{{true}}" duration="{{500}}" easing-function="easeInCubic" > <block wx:for="{{articleData}}"> <swiper-item> <scroll-view scroll-top="0" scroll-with-animation="{{false}}" scroll-y > content </scroll-view> </swiper-item> </block> </swiper> [代码] 4.性能优化 我们知道view部分是运行在webview上的，所以前端领域的大多数优化方式都有用。例如减少代码包体积，使用分包，渲染性能优化等。下面主要讲一下渲染性能优化。 4.1 dom优化 由于页面需要无限上拉刷新，所以要在[代码]<swiper>[代码]组件中不断的增加[代码]<swiper-item>[代码]，这样必然会导致页面的dom节点成倍数的增加，最后非常卡顿。 为了优化页面的dom节点，我们利用[代码]<swiper>[代码]的[代码]current[代码]和[代码]<swiper-item>[代码]的[代码]index[代码]来做优化，控制是否渲染dom节点。首先，仅当[代码]index <= current + 1[代码]时渲染[代码]<swiper-item>[代码]，也就是页面中最多预先加载出下一条，而不是将接口返回的所有后续数据都渲染出来；其次，对于用户已经消费过的之前的[代码]<swiper-item>[代码]，不能直接销毁dom节点，否则会导致[代码]<swiper>[代码]的[代码]current[代码]值出现错乱，但是我们可以控制是否渲染[代码]<swiper-item>[代码]内部的子节点，我们设置了仅当[代码]current <= index + 1 && index -1 <= current[代码]时才会渲染[代码]<swiper-item>[代码]中的内容，也就是仅渲染当先文章，及上一篇和下一篇的文章内容，其他文章的dom节点都被销毁了。 这样，无论用户上拉刷新了多少次，页面中最多只会渲染3篇文章的内容，避免了因为上拉次数太多导致的页面卡顿。 4.2 分页时setData的优化 setData工作原理 [图片] 小程序的视图层目前使用[代码]WebView[代码]作为渲染载体，而逻辑层是由独立的 [代码]JavascriptCore[代码] 作为运行环境。在架构上，[代码]WebView[代码] 和 [代码]JavascriptCore[代码] 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 [代码]evaluateJavascript[代码] 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 [代码]JS[代码] 脚本，再通过执行 [代码]JS[代码] 脚本的形式传递到两边独立环境。 而 [代码]evaluateJavascript[代码] 的执行会受很多方面的影响，数据到达视图层并不是实时的。 每次 [代码]setData[代码] 的调用都是一次进程间通信过程，通信开销与 setData 的数据量正相关。 [代码]setData[代码] 会引发视图层页面内容的更新，这一耗时操作一定时间中会阻塞用户交互。 [代码]setData[代码] 是小程序开发中使用最频繁的接口，也是最容易引发性能问题的接口。 避免不当使用setData [代码]data[代码] 应仅包括与页面渲染相关的数据，其他数据可绑定在this上。使用 [代码]data[代码] 在方法间共享数据，会增加 setData 传输的数据量，。 使用 [代码]setData[代码] 传输大量数据，通讯耗时与数据正相关，页面更新延迟可能造成页面更新开销增加。仅传输页面中发生变化的数据，使用 [代码]setData[代码] 的特殊 [代码]key[代码] 实现局部更新。 避免不必要的 [代码]setData[代码]，避免短时间内频繁调用 [代码]setData[代码]，对连续的setData调用进行合并。不然会导致操作卡顿，交互延迟，阻塞通信，页面渲染延迟。 避免在后台页面进行 [代码]setData[代码]，这样会抢占前台页面的渲染资源。可将页面切入后台后的[代码]setData[代码]调用延迟到页面重新展示时执行。 优化示例 无限上拉刷新的数据会采用分页接口的形式，分多次请求回来。在使用分页接口拉取到下一刷的数据后，我们需要调用[代码]setData[代码]将数据写进[代码]data[代码]的[代码]articleData[代码]中，这个[代码]articleData[代码]是一个数组，里面存放着所有的文章数据，数据量十分庞大，如果直接[代码]setData[代码]会增加通讯耗时和页面更新开销，导致操作卡顿，交互延迟。 为了避免这个问题，我们将[代码]articleData[代码]改进为一个二维数组，每一次[代码]setData[代码]通过分页的 [代码]cachedCount[代码]标识来实现局部更新，具体代码如下： [代码]this.setData({ [`articleData[${cachedCount}]`]: [...data], cachedCount: cachedCount + 1, }) [代码] [代码]articleData[代码]的结构如下： [图片] 4.3 体验优化 解决了操作卡顿，交互延迟等问题，我们还需要对动画和交互的体验进行优化，以达到类原生APP效果的体验。 在文章间上拉切换时，我们使用了[代码]<swiper>[代码]组件自带的动画效果，并通过设置[代码]duration[代码]和[代码]easing-function[代码]来优化滚动细节和动画。 当用户阅读文章到底部时，会提示下一篇文章的标题等信息，而在页面上拉时，由于下一篇文章的内容已经加载出来了，这样在滑动过程中会出现两个重复的标题。为了避免这种情况出现，我们通过一个占满屏幕宽高的空白[代码]<view>[代码]来将下一篇文章的内容撑出屏幕，并在滚动结束时，通过[代码]hidden="{{index !== current && index !== current + 1}}"[代码]来隐藏这个空白[代码]<view>[代码]，并对这个空白[代码]<view>[代码]的高度变化增加动画，来实现下一篇文章从屏幕底部滚动到屏幕顶部的效果： [代码].fake-scroll { height: 100%; width: 100%; transition: height 0.3s cubic-bezier(0.167,0.167,0.4,1); } [代码] [图片] 而当用户想要上拉查看之前阅读过的文章时，我们需要给用户一个“下滑查看上一条”提示，所以也可以采用同上的方式，通过一个占满屏幕宽高的提示语[代码]<view>[代码]来将上一篇文章的内容撑出屏幕，并在滚动结束时，通过[代码]wx:if="{{index + 1 === current}}"[代码]来隐藏这个提示语[代码]<view>[代码]，并对这个提示语[代码]<view>[代码]的透明度变化增加动画，来实现下拉时提示“下滑查看上一条”的效果： [代码].fake-previous { height: 100%; width: 100%; opacity: 0; transition: opacity 1s ease-in; } .fake-previous.show-fake-previous { opacity: 1; } [代码] 至此，这个类原生APP效果的下一条无限刷体验的需求的所有要点和细节都已实现。 记录在此，欢迎交流和讨论。 小程序demo体验请点击：https://developers.weixin.qq.com/s/vIfPUomP7f9a

一、初窥门径 大一那年，懵懵懂懂的入学，每天上课学习，下课游戏，奔波于各式活动之内，游走于各大社团之中。直到那天，看到了首届高校微信小程序应用开发赛，心头一动，点滴想法悄然酝酿而生。 二、出师未捷 石楠轩606宿舍内，几个大小伙子讨论得热火朝天： “我觉得可以，现在学校内还没有这样的小程序，如果做好了，肯定能迅速占领市场。” “没错，而且我们还能借着比赛的机会学一学小程序开发，有利无害呀” … … 当晚我们便着手报名，名曰“南柘”，将楠字左边的木嫁接到石字上，隐喻我们住在石楠。 然后… 就没有然后了… 稚嫩的我们终究没有坚持完比赛，甚至连个像样的模块都没搭建出来。 当时我们都是小白，不懂html、不懂js，更别提后台了。比赛开始后，我找了微信小程序的教学视频来看，发现讲得太泛，并不适合我这种初学者。我迫切需要的是手把手的教学视频或书籍，然而，当时自身底子太薄，学起来很慢，而队友们则忙于他事，连教学视频都没看过几眼。 自然而然的，我们默认了失败，这场尚未开战便宣告失败的战役，仿若一根耻辱柱，时时刻刻提醒我，梦开始的地方，不是做梦开始的地方。 三、沉淀 大一下学期，我成功转专业到计算机学院，开始恶补相关知识； 大二上学期，学了数据结构、算法、数据库，还写了个APP； 虽然囫囵吞枣，但也力求搞懂重点，尤其经典的算法。 随后机缘巧合下接触了Django后端开发，感谢这次开发经历，我对于前后端交互有了一个直观的感觉。第二届小程序开赛前，小程序开发于我而言不再是一个遥不可及的梦。 四、再战 去年一个队伍三个人，今年有些变化，一个队伍可以四个人，得益于此，我再次面对小程序比赛。好友薯饼邀请我加入他的队伍，已经有一个后端，一个UI；后来经过讨论，我和薯饼一起担任前端开发。 任何成果的取得，都不是轻而易举的。 1. 前期准备 我们开始讨论要做什么小程序，脑暴，调研，跟已有的校内小程序对比分析，最终我们决定了我们的作品 —— WritByU（writ 取自古英语，并非 write 的错别字） WritByU 是针对校园用户进行信息分享传播和问答的一个小社区，用户既可以以文 字、图片的形式实现信息的即时分享和传播互动，也可以围绕某一话题进行提问、答疑 以及讨论。 甚至于，我还用PPT做了简单的界面，现在想想确实好笑。 [图片] 随后便是确定技术路线，几经周转，也找到了一个高颜值的开源UI库：ColorUi，虽然没有文档用起来稍有不适，只能翻看源码使用。 [图片] 2. 爆肝开发 前期开发并不顺畅，毕竟万事开头难，一开始使用 ColorUi 就遇到了不少问题，因为没有文档，之前也没使用过 Component，为了解决问题，我找到了 ColorUi 的开发者，进行了交流群，虽然没有直接解决我的问题，但看群里大佬的交流却给我提供了不少思路，受益匪浅。 [图片] 此外，前期开发也比较容易拖沓，心里总想着不急，还有时间，（这为我们后面的通宵爆肝埋下了伏笔）有时间也是慢悠悠的写，或者把时间分配给了其他事情。 一些技术难点：(对于初学者来说想实现这样的小功能并不容易，但是耐下性子多看看别人的源码就可以解决。) 【富文本编辑器】 一开始写这个小程序的时候还没有出 editor，当时想着实在找不到可用的组件就手撸吧，结果还真的没找到（捂脸）。 最后勉强实现了图文混排，当然远不如现在的editor强大，结果富文本编辑器做得差不多的时候 editor发布了（求心理阴影面积） 当然愉快的尝鲜，结果发现 editor 的文档，也太简陋了吧，无奈之下翻看源码，折腾了半天总算搞定初始化、获取内容、更新内容等方法。 编辑框如下图，上方是 editor 强大的控件板，我们保留了一部分常用的功能， 下方加入了插入封面和标题（input），分享内容则使用了 editor 。 [图片] 【瀑布流】 广场页面为了实现瀑布流，我上网找了不少例程和方法，无奈没有可以直接用的轮子，理清了demo的思路就自己操刀开始干。 [图片] 渲染层：使用 leftData 和 rightData，分左右两边渲染。 [图片] 逻辑层： 本markdown编辑框的代码解析似乎出了点问题，输入左箭头会变成 &lt，如下所示，因此这里还是截图。 [代码]for (let index = 0; index < array.length; index++) [代码] [图片] 中期开发过程则比较艰辛，有段时间课内作业很多，大家都在今天赶这个实验报告，明天赶那个实验报告，大家很难凑在一起开发，童心，我们的后台小伙伴只好自行吭哧吭哧写接口，后续也因为一些逻辑没有提前沟通好修改了不少接口。 我们的API文档： [图片] 3. 提交作品 5.30晚，BUG基本都改完了，队友们也在进一步完善文档，凌晨四点多，我给小程序的使用方法录屏后，开始配音，剪辑视频，果然也是个技术活，几个小时后，终于捣鼓完了，不禁松了口气。打包代码、上传体验版，提交作品，这一阶段结束。几个人吃了个早餐上课的准备上课，我则回宿舍安心睡会觉。 [图片] 五、给初学者的技术建议 掌握基础知识：html、css、JavaScript，写几个小页面快速上手 看微信小程序的API文档，setData、bindtap，了解数据渲染、方法绑定； 了解 ajax 请求，找懂后端的师兄师姐或者同学开个简单的get请求接口给你练习（当然自己开个后端服务就更好了，比如Django什么的，上手方便，也可以用小程序云开发功能），然后自己阅读微信小程序API文档，试着使用wx.request。 此时已经基本掌握写一个单页面小程序的能力了，紧接着可以找一些开源的UI库，美化自己的界面，了解小程序页面、组件的生命周期找一些demo进心学习。 书法学习有临与摹，临，是照着原作写；摹，是用薄纸蒙在原作上面写。写代码也一样给，建议掌握必要的基础知识后，通读 demo 源码，了解大概思路，然后自行临写，而非对着别人的 demo 一行一行的摹，如此，一开始虽更费劲，但效果显著。 以上，是个人的一点小建议，如有更好的想法，可以在下方留言哦，欢迎交流~