本文会分享一个React性能优化的故事，这也是我在工作中真实遇到的故事，最终我们是通过魔改第三方库源码将它性能提高了几十倍。这个第三方库也是很有名的，在GitHub上有4.5k star，这就是：react-big-calendar。
这个工作不是我一个人做的，而是我们团队几个月前共同完成的，我觉得挺有意思，就将它复盘总结了一下，分享给大家。
在本文中你可以看到：
React常用性能分析工具的使用介绍
性能问题的定位思路
常见性能优化的方式和效果：PureComponent, shouldComponentUpdate, Context, 按需渲染等等
对于第三方库的问题的解决思路
关于我工作中遇到的故事，我前面其实也分享过两篇文章了：
速度提高几百倍，记一次数据结构在实际工作中的运用
使用mono-repo实现跨项目组件共享
特别是速度提高几百倍，记一次数据结构在实际工作中的运用，这篇文章在某平台单篇阅读都有三万多，有些朋友也提出了质疑。觉得我这篇文章里面提到的问题现实中不太可能遇到，里面的性能优化更多是偏理论的，有点杞人忧天。这个观点我基本是认可的，我在那篇文章正文也提到过可能是个伪需求，但是技术问题本来很多就是理论上的，我们在leetcode上刷题还是纯理论呢，理论结合实际才能发挥其真正的价值，即使是杞人忧天，但是性能确实快上了那么一点点，也给大家提供了另一个思路，我觉得也是值得的。
与之相对的，本文提到的问题完全不是杞人忧天了，而是实打实的用户需求，我们经过用户调研，发现用户确实有这么多数据量，需求上不可能再压缩了，只能技术上优化，这也是逼得我们去改第三方库源码的原因。
需求背景老规矩，为了让大家快速理解我们遇到的问题，我会简单讲一下我们的需求背景。我还是在那家外企，不久前我们接到一个需求：做一个体育场馆管理Web App。这里面有一个核心功能是场馆日程的管理，有点类似于大家Outlook里面的Calendar。大家如果用过Outlook，应该对他的Calendar有印象，基本上我们的会议及其他日程安排都可以很方便的放在里面。我们要做的这个也是类似的，体育场馆的老板可以用这个日历来管理他下面场地的预定。
假设你现在是一个羽毛球场的老板，来了个客户说，嘿，老板，这周六场地有空吗，我订一个小时呢！场馆每天都很多预定，你也不记得周六有没有空，所以你打开我们的网站，看了下日历：
你发现1月15号，也就是星期五有两个预定，周六还全是空闲的，于是给他说：你运气真好，周六目前还没人预定，时段随便挑！上面这个截图是react-big-calendar的官方示例，我们也是选定用他来搭建我们自己的应用。
真实场景上面这个例子只是说明下我们的应用场景，里面预定只有两个，场地只有一块。但是我们真实的客户可比这个大多了，根据我们的调研，我们较大的客户有数百块场地，每个场地每天的预定可能有二三十个。上面那个例子我们换个生意比较好的老板，假设这个老板有20块羽毛球场地，每天客户都很多，某天还是来了个客户说，嘿，老板，这周六场地有空吗，我订一个小时呢！但是这个老板生意很好，他看到的日历是这样的：
本周场馆1全满！！如果老板想要为客户找到一个有空的场地，他需要连续切换场馆1，场馆2。。。一直到场馆20，手都点酸了。。。为了减少老板手的负担，我们的产品经理提出一个需求，同时在页面上显示10个场馆的日历，好在react-big-calendar本身就是支持这个的，他把这个叫做。
性能爆炸看起来我们要的基本功能react-big-calendar都能提供，前途还是很美好的，直到我们将真实的数据渲染到页面上。。。我们的预定不仅仅是展示，还需要支持一系列的操作，比如编辑，复制，剪切，粘贴，拖拽等等。当然这一切操作的前提都是选中这个预定，下面这个截图是我选中某个预定的耗时：
仅仅是一个最简单的点击事件，脚本执行耗时6827ms，渲染耗时708ms，总计耗时7.5s左右，这TM！这玩意儿还想卖钱？送给我，我都不想用！
可能有朋友不知道这个性能怎么看，这其实是Chrome自带的性能工具，基本步骤是：
打开Chrome调试工具，点到Performance一栏
点击左上角的小圆点，开始录制
执行你想要的操作，我这里就是点击一个预定
等你想要的结果出来，我这里就是点击的预定颜色加深
再点击左上角的小圆点，结束录制就可以看到了
为了让大家看得更清楚，我这里录制了一个操作的动图，这个图可以看到，点击操作的响应花了很长时间，Chrome加载这个性能数据也花了很长时间：