这次优化已经过去很长一段时间了，当时没能记录下来，现在有空写个回忆录，算是给自己和后来人一个借鉴吧。
当时为什么要优化呢？是爱吗？是责任吗？是对技术的极致追求？胸 dei，为什么？作为一个程序员，自己心里没电 BBBBB 数吗？
如上图，一个列表有148条记录，后端一次性给的数据，业务场景里没有分页，有批量操作，且左右有联动，切换状态选中状态和批量操作状态需还原。
不过说实话，刚开始还是有点无从下手，不仅是因为交互复杂，而且一直认为列表渲染慢的最大原因是后端的问题，因为从开始加载页面到菊花转圈到最后列表全部展示出来，大概肉眼感觉就需要 2s 左右（200条数据），http 请求耗时大概是1s 左右。
直到后来，后端优化了请求，将请求耗时优化了一半，但是，但是前端表现出来的效果似乎没有改变，于是，我就做了一个测试，只请求，不渲染列表。
测试的结果真真是打脸，而且是非常疼的那种，如果只请求而不渲染数据的话，发现菊花转的时间特别短，所以。。。问题自然是出在前端无疑了。
现在，这个艰巨的问题摆在面前，无疑是对一个老前端的一种挑衅。不解决，怕是在公司的地位难保啊。呵呵呵。。。只能动脑子去解决了。
第一步，先解决列表多次渲染的问题，因为之前每操作一个订单，列表会重新刷新一次。如果刷新时间够短，这种方式是比较好的，但是现在刷新的时间是无法忍受的，所以订单操作后的 UI 刷新做成本地的。无疑这是成功的，运营给的反馈就非常好。
第二步，优化列表渲染的时间，我想到了刚刚的实验，如果渲染的列表数据很少，那渲染的时间不就大大缩短了呢。于是，在初次加载的时候就只渲染 3 条数据，发现这样是可行的。
那剩下的数据如何渲染呢，灵光一闪，脑子里出现一个方案，“无限滚动”。没错，就是无限下拉加载数据那个，只是将加载的数据换成本地列表数据。
第三步，如何还原，批量操作数据和订单的选中状态，这里无非是对数据操作，虽然有点复杂，但是还是难不到老程序员的。
第四步，测试上线，刚开始还是平稳运行的，运营和用户都在用，也没有反馈有什么bug，开始时沾沾自喜了，哈哈哈。
突然有一天，客户反馈过来一张截图，页面里显示待审核有 100多条，但是列表只显示了 3 条，注意这这个数字 3。这就是我最开始渲染的那 3 条数据，按道理来说，是没有什么问题，但是用户是个土豪，超大 2k屏了解下。于是乎，在代码里又加了一个方法来判断页面长度是否够滚动，如果不够而数据又没有渲染完，就多加载10条数据。
到此，宣布本次优化结束。对比未优化前，200 条数据 ，初次渲染时间由 3-4 s 缩短到 600-700 ms，操作流畅度完爆优化前。
最后，祝大家节日快乐。
随时随地看视频
