赞
踩
swiper的加载太多问题,网上资料好像没有一个特别明确的,就拿这个答题页,来讲讲我的解决方案
这里实现了如下功能和细节:
当swiper-item数量很多的时候,会出现性能问题
我实现了一个答题小程序,在一次性加载100个swipe-item的时候,低端手机页面渲染时间达到了2000多ms
也就是说在进入答题页的时候,会卡顿2秒多去加载这个100个swiper-item
那我们能不能让他先加载一部分,然后滑动以后再去改变item的数据,让swiper一直保持一定量的swiper-item?
注意到官方文档有这么两个属性可以利用,我们可以开启衔接滑动,然后再bindchange方法中去修改data
1、保证swiper-item的数量固定,加载大量数据时,大大优化渲染效率
假设我们请求到的数据的为list,实际渲染的数据为swiperList
我们现在给他就固定3个swiper-item,前后滑动的时候去替换数据
正向滑动的时候去替换滑动后的下一页数据,反向滑动的时候去替换滑动后的上一页数据
当我们知道了要替换的条件,我们便可以去替换数据了
但是我们应该考虑到临界值的问题,如果当前页是list第一项和最后一项该怎么办,向左向右滑是不是得禁止啊
2、记录上次的位置,页面初次加载不一定非得是第一页,可以是任何页
有很多时候,我们是从某一项直接进来的,比如说上次答题答到了第五题,我这次进来要直接做第六题
那么我们需要去初始化这个swiperList,让它当前页、上一页、下一页都有数据
3、答题卡选择某一index回来以后的数据替换,并去掉swiper切换动画,提升交互体验
从答题卡选择index,那就不仅仅是滑动上下页了,它可以跳转到任何页,所以也采用类似初始化swiperList的方法
swiper切换动画我这边是默认250ms,但是发现有时候从答题卡点击回来,你在答题卡点击的下一项不知道会从左还是从右滑过来
体验真的很差,一开始不知道怎么禁掉动画,其实在跳转到答题卡页的时候把duration设为0就可以了
我然后在答题卡页的unload方法中恢复
在固定3个swiper-item的同时,保证我们可以有办法来替代微信自带swiper的current属性和change方法
一开始很头疼,为什么微信小程序提供的这个swiper,那么的不好用,和ViewPager差太远了吧。
然后在网上和社区找也没有一个特别好的解决方案。
后来想想,小程序是小程序,原生是原生。遇到需求就静下来解决吧。
项目地址:swiper-limited-load
如果错误,欢迎指出。
如有新的需求也可以提出来,如果有时间的话,我会帮你们完善。
如果能帮到你们,记得给一个star,谢谢。
有很多朋友在评论区提到了分页的需求,抽时间写了一个分页的Demo和大家分享一下。
还是以答题为例,比如我们一共有500条数据,一页20条,可能需要如下功能,乍一看不就加了个分页,挺简单的,其实实现起来挺麻烦的,下面说一下思路和一些需要特别注意的点:
1、从其他页面跳转到答题页时,不光只能默认在第一题,可以是任意一题,比如第80题。
跳转到任意一题,那么需要我们根据index算出该数据在第几页,然后需要请求该页数据,最后显示对应的index。我的思路更注重用户体验,不可能是上滑或者下滑才开始去请求数据,一定是要用户滑动前提前请求好数据。所以起码要保证左右两侧在初始化那一刻都有数据。如果此题和它的上一题下一题都在同一页,那么我们只需要请求一页数据(第15题,那么只需请求第1页数据)。如果此题和它的上一题或者下一题不在同一页,那么我们可能需要请求两页数据。(第20题,那么需要请求第1页和第2页数据)
2、左滑、右滑没数据时,都可以加载新数据。直到滑到第一题或者最后一题。
如果我们初始化时是第24题,那么我们左滑到第21题时,就应该去请求第一页的数据。那么用户在看完21题时,再滑到20题,可能就根本不会感知到通过网络请求了数据。但是如果用户此刻滑动特别快:滑到21题时请求了网络,请求还没成功,就又向左滑了。那么我们需要限制用户的滑动,给用户一个提示:数据正在加载中。
3、从答题卡点击任意一题可以跳转到相应的题目,并且左右滑动显示正常数据
比如我们初始化是跳转到了第80题,不一会点击答题卡又要跳转到200题,一会又跳转到150题。各种无序操作,你也不知道用户要往哪里点。
一开始是想着维护一个主list,点到哪道题往list中添加这道题所在的当页的数据,但是还得判断这一页或者左滑右滑请求新一页的数据得往list的哪个位置添加。这来回来去乱七八糟的判断就很麻烦了,很容易出bug。而且list长度太长了以后insert的性能也不好。
后来就去想,要不答题卡点击任意一题都清空旧的list,然后请求新的数据,左右滑动没数据了再请求新的数据呗。但是这样很浪费资源,并且用户体验也不好,用户已经从第1题答到第200题了,这时用户从答题卡选择了一个25题,还得重新请求网络。而且200道题的数据都没了,那再选个26题,再重新请求网络?网络有延时不说,还浪费资源。
最后转念一想,这时候就需要弄一个缓存了。所以最终的解决方法就出来了:我们维护一个map,在网络请求成功后,在map中保存对应页的数据,同时我们维护一个主list来显示对应的题目。当我们在答题卡选择某一题目,就清空list,然后判断map中有没有该页的数据,如果有就直接拿来,没有就再去网络请求。这个处理方式,写法相对来说简单,不需要乱七八糟的判断,也不浪费资源,用户体验也很不错。
总结
以上就是一些思路和要注意的地方。这个Demo断断续续花了好几天时间写出来的。可能我说的比较啰嗦比较细,只是想让需要用到这个分页Demo的同学能理解我是如何实现的。
如果觉得能帮到你,记得给一个star,谢谢。同时如果这个demo有bug或者你们有新想法,欢迎提出来。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。