经过前两种方式的优化方式，返现Taro小程序在一些场景上，性能不如H5的好，所以第三次优化决定使用H5方式进行重构；所以这次优化已经不算是给予Taro的优化了；只是想记录优化的过程；
H5的方式优化的思路和之前的方式基本一致，这里采用了现有的一些开源库react-virtualized
H5之后弥补了第一次和第二次优化中的问题：
在使用react-virtualized 的 AutoSizer API时遇到了一个问题，在安卓手机上时，在底部的输入框键盘弹起会引起页面高度的变化，从而AutoSizer重新渲染，这里使用了一个变了存储高度，记录第一次渲染的高度，从而固定List的高度；
经过这次事情后，后面一些功能可以考虑小程序+h5的方式，开始没选择这种方式主要还是觉得纯小程序体验会好一些，但是随着应用到复杂度不断提升(目前已有35+的功能模块)，小程序的弊端也暴露出来了；比如分包加载也比较慢，可能比打开H5页面还要慢；大数据长列表的渲染表现很差；发布依赖微信审核，遇到几天还没审核通过的情况；
在Taro列表优化上，其实还有一种方案没有尝试，像官方提供的虚拟列表中Item是定高的，react-virtualized虽然也要给Item设置高度，但是他支持自动计算，其实Taro也可以尝试这种方式，只是实现起来时间可能更久，性能上从之前的经验来看，预计也不理想，所以放弃尝试，直接改用H5方式。
另外也考虑过把Taro编译成H5，但是实验下来，编译没问题，但是里面用了很多小程序的api，在H5中并不存在，这样修改起来影响范围太大，风险高，所以也暂时放弃了；
