最近涉及到uniapp 开发小程序和h5 做的一个长列表，遇到有几个需要注意的地方，在此写个记录提醒健忘的自己避免踩坑。

原始实现方式：

首先一个正常的列表都是有一个 tab 来做头部选项卡和一个内部区域，通过手指的滑动可以切换选项卡。然后传统都是采用swiper 加  scroll-view实现（tab 因为没什么性能上的问题就不说了）。但是有时候程序并不能如你所愿，通过这两个组件实现的列表如果数据比较少的情况下确实是比较好用，但是如果出现tab每一项动态加载的数据比较多之后，通过swiper来切换，会导致页面的抖动和卡顿，这个就给用户和页面性能上带来较差的体验。

优化方式：

1、首先是scroll-view 的优化，这个组件如果超出预定区域后就会出现滚动条来进行滚动，滚动查看数据又或者在配合监听到底加载更多的时候，会出现滑动卡顿，不流畅等问题。首先我们来看下官方给出的解决方案：

scroll-view 不适合放长列表，有性能问题。长列表滚动和下拉刷新，应该使用原生导航栏搭配页面级的滚动和下拉刷新实现。包括在app-nvue页面，长列表应该使用list而不是scroll-view。

这个方案也是现在通用的解决方案，就是通过页面级的滚动方式来替换scroll-view的滚动。何为页面级，意思就是说在可视区里，通过内容撑出滚动条来进行滚动，这个还有个好处就是能在生命周期中监听的到是否拉到底部（虽然说 scroll-view也有，xixix）。最后需要处理一下tab ，如果tab 不想跟着页面级滚动走下去，可以搞个吸顶，吸顶之后，内容区域需要padding增加一下tab的高度避免挡着。

当然如果想一站式处理完美，还有各种友好的提示，可以用下mescroll 这个组件，官方给出的说明是：

mescroll.js 是在 H5端 运行的下拉刷新和上拉加载插件。原生js, 不依赖jquery,zepto支持vue超详细注释, 快速使用,轻松上手一套代码多端运行, 支持uni-app，完美运行于android, iOS, 手机各浏览器，兼容PC端主流浏览器

2、swiper的优化就比较复杂。在app端使用的话，uni使用的是nvue的原生性能，所以它会自动处理释放优化非可视区的数据。在非App端使用的模式是只缓存左右一共3列的数据，dom中的数据过多时，它会自动释放。就是说App上，只要看过这一页，再进去时内容是还在的。而在非App上，只能做到缓存3页数据，其他页即便看过，再进去也会重新加载。并且非App的这种情况下，不再提供下拉刷新。虽然插件市场也有其他前端模拟的下拉刷新，但性能不佳。一般小程序的大厂案例里，提供左右拖长列表的，都是这种做法。

如果此方法有难度实在实现不了的，可以将它做成组件后添加一下切换的过度动画来实现又或者直接不理会设计师的要求，我就是爸爸的心态，做成没有动画效果，固定的也行