首先说明 本文的虚拟滚动条是用于app， 没有在微信小程序中测试过，只在web环境和app（安卓、苹果）这三个环境中测试通过。
虚拟滚动条的原因当然是列表数据太多，列表直接显示app会卡（web是一点不卡的，苹果有点卡，本人的千元安卓是卡爆了）。
1、使用web的方式解决（第一版）
1.1 计算所有数据的总高度，再通过uniapp本身的函数计算滚动条的高度
可以通过： 通过uni.getSystemInfoSync()获取窗口宽度和高度动态设置 scroll-view 高度 :style动态绑定height高度。
1.2 然后在下拉的时候算出当前需要显示哪些数据通过事件scroll 算出当前需要显示的数据， 然后在页面上显示。
这个解决方案后解决了了卡的问题，但是引入了新的问题，行高度多少合适，如果有图片怎么办，文字数据多怎么办。
如果行高度设置少了，会出现文字显示到第二行上了，活着图片不能自适应显示。 如果文字设置多了会出现有不需要的空白出现，影响美观。
2、使用web的方式解决（第二版）
这个版本是在第二部的基础上把行设置成自适应。基本能解决行的数据显示问题。但是这里出现了一个新的问题。 需要显示什么数据计算的不是特别准确。这一版改造后苹果上基本上是没什么问题了，但是千元的安卓手机还是有点不流畅，反应卡顿；表现为上下滚动的时候数据不能马上刷出来。老板这个时候发话了，你们行不行，不行的话我到外面花钱解决。男人这时候怎么能说不行。所以有了第三版（死要面子活受罪）
3、参考游戏界面的设计（第三版）
不知道在什么时候看到过一篇腾讯游戏的开发工程师在博客园发的一篇文章里面说的游戏的优化，提到过一个词构建的元素重新复用。我的解决方案在高度和显示数据的计算上和第一版没有区别，但是页面列表的数据显示上就有区别了。
首先列表中数据行数我只渲染比显示数据多2条，就是显示数据的上面一条和下面一条。当然如果实际列表数据比显示数据少那么就直接显示就可以了。 然后列表的数据直接就渲染完成。通过计算， 把需要显示的数据直接显示在已经渲染好的列表数据上就可以了。
这里性能是完美的，就是有一个问题行高和图片自适应的问题。
4、基于第三版的最终版（性能优化没有终点）
关于图片采用了一个简单办法直接固定宽高（小图显示，列表上不需要大图显示），关于文字的显示。在程序往下滚得时候在数据显示的时候程序自动算出行的高度，然后保存并重现计算所有数据的总高度计算。目前这一版基本完美，在千元机上能够流畅显示数据。