1、问题背景
那是一个风和日丽的早晨，突然！有人反馈说客服工作台页面会卡死！
是不是设备太老了？软件版本太低了？这个是对于这种棘手的，摸不着头脑的问题总是想先上三板斧：重启、重装、重买。
但不好使，随着陆陆续续的越来越多的客户人员的反馈，事情渐渐坏起来了。
于是伴随着客户每况愈下的情绪与态度，我们开始了艰难的、痛苦的问题排查。
2、排查过程
2.1、性能指标
首先明确一点，页面卡死涉及到哪个性能指标？答案是：cpu！
不同于内存泄漏导致的页面崩溃，页面卡死、未响应更多的是由于cpu被沾满导致的浏览器再无资源去处理新指令。
这也问题难以排查的原因：js脚本都跑不动了，想上报日志也上报不了。
而且问题难以复现，客户那边、我们这边都找不到一个可以稳定复现的方法。
“反正就是有时候用着用着会卡死”，客户如是说到。
2.2、排查误区一——场景错误
那既然是呼叫中心的页面卡死，那我们的第一反应就是，是否是反复的操作导致哪里的事件反复挂载之类的问题。
于是一遍一遍的走查呼叫中心相关的代码，查看哪里有潜在的隐患，但收获不大。
后来远程客户，观察他们操作之后才发现，这根本不是他们的使用场景！
这就是耽误排查的一大误区，错误的假定的客户的使用场景！
我们下意识的以为，客户是大量时间停留在客服工作台，做各自各样的操作；最终在某一刻发现，页面卡死了。
但实际上客户的使用场景是：大量时间停留在其他页面，只有在必须的时候才进入客服工作台，然后偶尔在进入客服工作台的时候出现卡死的情况。
排查的重点应该在客服工作台的初始化，而不是长时间执行。
而在客服工作台内，确实会有几个比较重的操作：
1、大量的日志上报接口调用
2、右侧对象详情页的初始化
3、session列表的创建
对此我们联系相关团队，做了如下的优化：
1、日志上报接口先做收集，再每10秒上报一次（如果有的话）；且只需要最新的300条日志，这是考虑缓存太多日志信息也有内存的消耗，且一般正常人短时间内也无法做出这么高频的操作。
2、初始化时，延后对对象详情页的渲染。
但将这几个优化发布后，问题仍旧存在......
2.3、排查误区二——未完全还原场景
为什么问题还是没有修复呢？那当然的因为客户的问题不是出在这啦~
这里我们忽略了一个比较重要的、也比较容易被忽略的信息，那就是：电话条通话中！
为什么说比较容易忽略，是因为电话条本身就是一个比较轻量的组件，而其存在、其状态也相对独立。
它甚至不跟客服工作台强关联，离开工作台也可以存在！
所以即便客户老爷屡次三番强调是在通话中就会卡死，我们还是无情的忽略了这一信息，毕竟，他们懂什么代码呢。（不是
但随着时间的推移，客户的反馈愈来愈烈，解决这一问题的希望愈发渺茫，这一原本不受重视的信息也渐渐迎来了程序员大大的注视。（盯
“通话中就通话中吧，都说了没区别，不信就演示给你看嘛！”，一咬牙，一跺脚，走投无路的程序员开始在电话条通话中的时候，疯狂的刷新页面.....
！！！！！
出现了！页面卡死的问题出现了！！！
可是.....为什么呢？这跟通话中有什么关系.....
但先不管了，既然能稳定的复现，抄起性能分析工具就上呗，于是乎我们得到了这样的结果：
嗯，cpu确实已经被沾满了，代码位置也标注出来了，那就改呗。
不行！代码位置涉及的函数其实，单次调用的开销并不大，而且这跟通话中依旧没有关系。
而且查看分析报告，其单次调用耗时也确实不高，那为什么会导致占满cpu呢？高频调用！
掉一次开销不大，那调用一百次、一千次呢？
有了这个思路我们就开始了又一次的代码走查，终于发现了这里。
我们监听了某个事件，然后去通知所有的左侧会话的数据更新。
其实之前也有怀疑过这个位置，但一来没有性能分析工具的佐证，二来它依然跟通话中没有关系啊。
但是不管了，时间紧迫，先把这个通知关闭再说。
解决了！
但是，为什么呢.....
同样的通知，不管电话条是在什么状态下，它都会触发，为什么有时候就会卡死呢？
于是抱着试试看的心态，我们在事件监听处，和事件触发处加了日志：
得到了如下的结果：
事件在通话中的情况下，会被触发上千次，而每次的触发都会通知50-60个实例去更新数据，5、6万次的方法调用把cpu干爆了......
那接下来的处理就很简单了，在事件接收那里我们加了个防抖，限制处理次数。
而由于事件本身是由其他团队触发的，就通知其他团队排查具体原因了。在掌握复现条件的情况下，相信也毕竟好排查了。
to bo continue......
3、问题总结
为解决这个卡死的问题所耗费的时间是比较长的，而之所以如此，我认为是有如下几个原因的：
3.1、歧义
我们在产品设计的时候、在开发、在维护的时候，我们会对我们的产品进行各自各样的命名。
但这些名词，客户是不一定接受的。他们可能在他们的使用中，又延申出了自己的一套名词系统。
我们讲啊猫指的是桌子，客户讲啊猫指的也许就是椅子。我们说”通知“是这个，当客户像表达的”通知“却是另外一个。
这会导致我们难以复刻用户的使用场景，以及错误的排查方向的出现。
所以尽量让用户提供视频，或者提供远程的方式来反馈问题，以保证确切的理解客户的问题所在。
3.2、复现
可以看到，这个问题排查的关键转折点就在问题的复现上。
相信大家在日常的工作中都有所体会，能复现的问题往往比较好修复，而那些偶现的问题才是真正的折磨。
而在没有复刻客户场景的情况下，性能分析工具也没把出问题的代码分析出来：
可以看到，cpu是会有一定程度的冒高，但我们问题的主角，真正出问题的代码，却只占用了较少的部分。
而要想较好的复现客户问题，做好信息的同步是关键，让客户提供操作视频、让客户协助远程、甚至是远程挂着观察一段时间客户操作。
4、写在最后
4.1、卡死的页面也能跑性能工具
页面虽然卡死了，但控制面板其实还是可以正常操作的。
4.2、ai协同
性能分析工具有些参数不理解其含义，而网上又搜不出来相关资料的时候，可以尝试截图问ai
