当前位置:   article > 正文

记录一次前端页面崩溃的产生及处理

记录一次前端页面崩溃的产生及处理

记录一次前端页面崩溃的产生及处理

​  起因:前端的一个地图页面某一些单子一点进去,就会导致页面卡死、崩溃,浏览器最终给的错误码为:out of memory。

​  排查:OOM!第一反应是猜测会不会是因为地图要渲染的点位太多了(大概7、8千个点位),后面在另一个页面看到相同数量的点位也能够正常的渲染出来,就排除了这一猜测。

​  由于这个情况只发生测试环境,本地环境复现不出来,一时陷入了困境。后面对比了两个环境的区别,测试环境是通过打包,使用 nginx 代理的方式运行的,本地环境是通过 node 环境运行。于是本地环境也采用打包,nginx 代理的方式运行,终于成功的把页面崩溃情况复现出来。

​  第一次代码定位:通过查看网络请求,发现页面卡死前有个请求一直处于未返回状态,于是使用接口调试工具手动调用该接口,但该接口能正常返回,排除接口问题。接着将代码定位到发送该请求处,在进行各种各样的尝试后发现,将 statusList 从响应式类型换成非响应式类型后,居然页面不会崩溃了,于是便再发了一版测试环境…

  ...
<div v-for="(item, index) in statusList" :key="index" style="width: 100%">
  ...
</div>
  ...
  • 1
  • 2
  • 3
  • 4
  • 5
const statusList = ref<any>(); 

const draw = async () => {
	...
    statusList.value =  await getStatus();
    ...
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

​  解决方案:将响应式类型换成非响应式类型…

​  再起:发版没过多久,这个状况又出现了,不同之处在于,这次刚点进去没问题,过了一段时间才会出现页面崩溃的情况。

​  排查:这次情况第一反应,内存泄漏!通过内存工具发现,页面快照的内存会随着时间的增加而增加。这次首先去优化了地图元素的使用,没用的元素该销毁的进行销毁,不出意外,没啥效果。又是一顿各种尝试,终于发现了问题所在!

​  第二次代码定位:通过打 log,发现某一方法(getShipRoute)一直在死循环不断输出 log,于是定位到了该代码处。

	...
<div v-for="(item, index) in statusList" :key="index" style="width: 100%">
    <div v-if="getShipRoute(Number(items.pointIndex) - 1)">
        ...
        <span class="arr-time">船名:{{ shipRoute.vesselName }}</span>
        ...
    </div>
</div>
	...
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
const shipRoute = ref<any>(null);
const getShipRoute = (idx:number) => {
    let a = routeList.find((v: any) =>{
        return v.range === idx
    });
    if (a) shipRoute.value = a;
    return a;
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

​  原因:shipRoute 是一个响应式数据,内部是一个对象,第一次循环,将 a1 的引用赋值给 shipRoute,然后 shipRoute 进行第一次页面元素 pageElement1 渲染,第二次循环,将 a2 的引用赋值给 shipRoute,然后 shipRoute 进行第二次页面元素 pageElement2 渲染,同时由于 shipRoute 发生改变, pageElement1 需要重新进行一次渲染,又将 a1 的引用赋值给 shipRoute,此时 shipRoute 对于 pageElement2 来说又发生了变化,至此死循环发生了。

​  解决方法:将 shipRoute 的内部数据换成数组,至此该问题得到了解决。

​  疑问点:

  • 为什么第一次改动可以延迟问题的发生?
  • 为什么打包才会导致问题的发生?

​  对于疑问1,推测跟渲染方式有关,如果外层数组为响应式数据,每次死循环都得渲染外层整一个代码块,这无疑大大加速了内存的爆炸,而不为响应式数据,则每次死循环只需要渲染内层一个小代码块,内存增长的速度不会那么快。但随着时间的累积作用,内存也会增长到极限值进而引发崩溃,这似乎解释了为什么第一次改动可以延迟问题的发生。

​  对于疑问2,猜测 node 环境可能对此种情况做出了一定的优化,导致问题没能复现,具体原因也未得而知。

​  补充:页面崩溃前的情况:其他元素貌似渲染完毕,只剩下地图元素还没进行渲染,这一定程度误导了我们对于该问题产生原因的推测。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/我家小花儿/article/detail/652187
推荐阅读
相关标签
  

闽ICP备14008679号