页面崩溃原因分析及解决2020终于Chrome浏览器“啦”的问题！

引言

在开发综合管理平台态势概览的大屏页面的過逞，碰到了页面崩溃的问题，本帖子记载了崩溃的缘故分析和好息争决方案。

问题

打开综合管理平台，进入态势概览页面，停顿在此页面一段时间，会出现如下图所示的页面崩溃的环境。

缘故分析

注：以下操作环境提议在browser隐身模式下进行，防备其他因素滋扰

使用工具

根据页面崩溃的提示，可以开端判断是页面内存溢出导致的崩溃，为了验证内存是否溢出，可以使用 Chrome browser自带的工具分析验证。这里介绍三种工具的使用，可以联合实际需求来使用。

1) 打开方法：

2) 界面：

3）使用方法：
使命管理器的使用方法最为简单，打开需要分析的页面，直接察看内存占用空间与 JavaScript 使用的内存即可。假如这两个数据连续上升，说明内存正在走漏。

1） 打开方法：
按 F12 打开开发者工具，选择 Performance 栏
2） 界面：

3） 使用方法：
打开需要分析的页面，等页面稳定下来后，点击 Performance 左上角的录制按钮开始录制，它会保存下页面的快照、JS Heap、Document、!Nodes、Listener、GPU Memory等信息。录制一段时间（最幸亏一分钟以上）后，停止录制，等候工具天生陈诉。

1） 打开方法：
按 F12 打开开发者工具，选择 Memory 栏
2） 界面：

3） 使用方法：
这个工具的使用方法最为庞杂，这里只简单介绍下 Heap snapshot 的使用，感爱好的可以自行搜索其他使用方法。
首先，打开需要分析内存的页面，点击工具左上方的录制按钮，天生分析陈诉。
其次，进行一些大概导致内存上升的操作后，再次点击录制按钮，天生分析陈诉。
最后，我们有了两份分析陈诉，通过菜单栏的下拉框选择 Comparison 过滤分析结果。察看 #New、#Deleted、#Delta 这三列，分别代表新增对象数、删除对象数、新增数与删除数的差值，找到那些只有新增，没有删除的对象，看看是被谁引用了，据此来找到大概导致内存溢出的代码。

确定内存溢出缘故

打开态势概览页面后，通过使命管理器察看页面使用的内存，发现内存是连续上升的，这时再通过 Performance 工具进一步分析。
以下是 Performance 的分析结果：

通过度析结果可以看到，内存资源在连续上升，再进一步察看结果，可以发现内存上升是存在一个门路式的上升周期的，为什么会产生这种征象呢？放大内存上升的部分进一步分析看看：

上图表现了内存上升部分细节，把鼠标移动到页面快照上，可以清晰地看到，当上一个大屏页面轮播到下一个页面时，内存就会上升而且不会再降落到之前的程度。如今已经有原因猜疑是页面轮播引起的内存溢出，以是，通过暂停页面轮播，再进行一次 Performance 分析，看看分析结果：


通过上图可以看到，暂停页面轮播后，并没有显着的上升趋势，说明browser可以正常回收内存，并没有溢出。至此，已经可以确定当页面轮播时内存会溢出。

分析内存溢出对象

经过第二步的分析，已经知道了大屏页面切换会导致内存升高，使用这个证据，用 Memory 工具去进一步分析， 找到那些被引用本该被开释，但实际没有的开释的对象 。
首先，打开态势概览页面，先暂停页面轮播切换，停顿在总体态势页面，待页面加载完成，然后打开 Memory 工具，点击录制按钮分析总体态势页面的内存。分析完成后，手动切换到风险态势页面要么其他大屏页面，再切换回总体态势页面，然后在 Memory 工具中再次点击录制!按钮分析页面切换之后的内存。完成以上操作之后，就得到了两份分析陈诉，分别是内存上升前和上升后的，在 Memory 工具的菜单栏下拉框中选择 Comparison，看看到底是哪些家伙占用了内存！

来分析上面的结果图，首先，页面上有种种种类的对象，点击对象可以看到对象详细的引用信息，我们的使命是通过对象引用信息找到一些蛛丝马迹。我们可以搜索 detached 开头归类的对象，也就是那些在内存中但是没有在页面进行渲染的元素。选择一个，可以看到它的具体引用信息：

很显着，ehcarts 引用了这个对象，而这个对象连同它的引用，理应是在页面切换之后被烧毁了的，既然他没有烧毁，说明我们的代码是有问题的。接下来要做的是，找出 ehcarts 引用的对象没有被烧毁的缘故，修改相关代码，再验证。

解决方案

使用准确的 echarts 实例烧毁方法

根据上面的缘故分析，我们知道是 echarts 引用的对象没有正常被烧毁，那么很easy，我们只要实验准确烧毁 echarts 实例就好了。进入到我们的 ehcarts 组件代码，定位到 beforDestory 钩子，可以看到，已经有一段代码对 echarts 实例进行开释了。

进入 echarts 官网查询烧毁实例的相关 api，发现 .clear() 方法只是清空了实例，并没有烧毁，而 .dispose() 方法才会烧毁实例。

答案到这里已经呼之欲出了，我们项目中之前不停用的是 .clear() 方法清空 echarts 实例对象，而不是用 .dispose() 烧毁，以是 echarts 实例并没有被正常烧毁，当我们频繁地切换页面的时间，echarts 实例就会不停的累加，占用的内存也会随之增长。以是，这里提议，以后我们封装 echarts 组件的时间，统一使用 .dispose() 方法烧毁组件。

页面隐蔽时停止定时器使命

你以为到这里就结束了吗？事情没有那么简单！在搜索内存溢出解决方案的时间，在网上看到了一篇文章： https://www.cnblogs.com/zdd20...

再次通过 Performance 工具分析验证，结果如下：

果真，内存又在连续增长，那么就使用网上分享的方法解决这个问题，添加一个标签切换的监听函数，在脱离页面时，把页面的定时器扫除，返回页面时重新开启定时器，这样就可以了。

结果

结果：内存保持在安稳状态，没有上升，页面没有崩溃

结果：内存保持在安稳状态，没有上升，页面没有崩溃

结果：内存保持在 2G 左右，页面没有崩溃

总结

通过此次的内存溢出分析，我们熟悉了一些内存分析工具及内存分析方法，也发现了代码中不足的地方，最后通过准确的方法解决了内存溢出的问题。盼望这篇文章可以对大家日后的工作有所帮助。固然，这只是很小一部分，也大概有不准确的地方，欢迎大家提出疑问一起探究。

Google的chrome莫名其妙忽然全部页面都表现“喔唷 崩溃啦”，种种插件在右下角弹出报错！这个问题我之前碰到过一次，后来通过改快捷方法的名字解决了。但是这次，断绝返回上班，打开电脑，又一次出现这种征象。折腾了一上午，种种方法都试过了，最后终于解决了。

实验失败的方法

网上虽然有许多答复，但历史久长，有大概之前这些方法确实有效，但如今对我统统不管用！为防备后人踩坑，不要耽搁太多时间，我简单说下哪些方法不可行。不外这种是对我的环境（win10 64bit），固然你也可以实验，大概对你实用。

• 卸载后重装chrome。
• 右击快捷方法修改默认参数，如

• 卸载扫除洁净chrome（卸载时扫除个人设置），扫除缓存和cookie，或实用CCleaner，重安装。
• 删除注册表HKEY_LOCAL_MACHINE---SOFTWARE---Google---Chrome。 把Chrome项完全删除。结果是删除不了，一些教程说新建 remove.reg ，然后粘贴删除项，双击删除，实际也删除不了。
• 找到路径C:\Windows\System32\drivers\bd0001.sys，删除。实际上没有这个文件。

等等，以上方法统统不可！统统不可！就差重装系统了，但这是公司的电脑啊，恨得我换了个火狐browser。

成功解决

最后，终于找到一个良知答案： https://www.cnblogs.com/RyanZhou/p/12083025.html。
引用下：

问题地点:
Google在79版本（2019年12月20号左右）的更新中又!重新启用了Renderer Code Integrity Protection（渲染器代码完备性葆护），会制止署名不是谷歌和微软的模块加载。该功能已经在之前一个版本中导致同样的问题，并由Google自己禁用了。
解决方法：
禁用谷歌chrome的这项功能
Win+R打开运行对话框，输入regedit打开注册表编辑器
导航到HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Google \ Chrome
在右边窗口中，右键单击新建>DWORD(32位)值以创建新密钥
双击它，然后将值名称改为RendererCodeIntegrityEnabled，并将值数据输入为0
重新启动chrome。

由于之前修改过注册表，以为是下面这个：

留意啊！不是上图的这个chrome，这个chrome就是之前我怎么删也删不掉的。

但是我的Policies下没有Google啊。可以新建项：

然后重启chrome，终于可以了！

官方说明：

https://support.google.com/chrome/answer/95669?visit_id=637147583639250344-892483008&p=e_awsnap&rd=1

征象：

browser打开一个vue页面，当前页面使用定时器每秒调后台接口一次，长时间停顿在此页面，约莫半天时间，browser表现：喔唷，崩溃啦！

定位问题：

browser标题栏空缺处点击右键-使命管理器，可以看到对应页面的历程的运行状态。
通过监控发现，问题页面内存连续上升，显着比其他页面高了许多，存在不同寻常。

思索：

1、猜疑定时器导致内存上升，但是写了个很easy的定时器刷新时间，并不会导致内存上升。
2、猜疑调用接口返回的数据量过大导致内存上升，但是模仿相同数据量，通过定时器每秒天生一个随机对象!也不会导致内存上升。
3、那就是接口的问题了，换另一个接口也存在同样的问题。
最后发现，调用接口时将请求存到一个全局变量的!数组（为了取消请求用），而路由没有跳转，数组不停没有被清空，全局变量渐渐增大内存使用能不往上涨嘛！！！

结论：

循环调用时，往全局变量不停set值，导致browser内存激增。
对于定时器不停请求的请求，就不要往全局变量内里放了，万不得已的话要想措施不要让全局变量连续增大！！！
同时，使用定时器前，肯定要扫除上一个定时器。

固然了每秒刷新提议使用websocket，怎样后台暂不提供。。。