当前位置:首页 » 网页前端 » 前端dom元素过多页面崩溃
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

前端dom元素过多页面崩溃

发布时间: 2023-01-04 01:49:35

‘壹’ 前端性能优化-处理大批量DOM元素

滚动监听事件

‘贰’ 公安网加载dom组件失败原因

1. 事件失效的原因:
(1)bind事件绑定只对dom中存在的元素有效,对于我们后来动态增加的元素是监测不到,所以绑定不了
(2)同样,当你使用var aa = document.getElementsByTagName("动态生成的元素");来获取动态生成的元素的时候也是获取不到的,因为网页只会执行一次初始化绑定,之后动态生成的dom元素也是监测不到的。
2. 解决办法:
(1)在每一个动态生成的地方都再绑定多一次事件,比如这个博客里面的例子
(2)把bind改用live,因为live是实时监测的,对于新增的dom元素也是有效的(因为不断去绑定、判断,所以可能会影响Web性能问题)
(3)把bind改用delegate,因为delegate是实时监测的。
(4)在jquery1.7 起版本用on替代了bind()、live() 和 delegate() 方法。

‘叁’ 前端错误Uncaught TypeError: Cannot read property 'length' of null错误怎么处理

通过统计数据库中的1000多个项目,我们发现在 JavaScript 中最常出现的错误有10个。下面会向大家介绍这些错误发生的原因以及如何防止。
1. Uncaught TypeError: Cannot Read Property

这是 JavaScript 开发人员最常遇到的错误。当你读取一个属性或调用一个未定义对象的方法时,Chrome 中就会报出这样的错误。

导致这个错误发生的原因有很多,常见的一种情况是在渲染 UI 组件时,不正确地初始化状态。我们来看一个真实的应用程序中发生这种情况的例子。

以上代码有两个重要方面:

一是组件的状态(例如 this.state),在开始生命周期之前是 undefined 状态。

二是当通过异步的方式获取数据时,无论是在构造函数中 componentWillMount 中,还是在构造函数中提取 componentDidMount,组件在数据加载之前至少会渲染一次。当检测首次渲染时,会发现 this.state.items 是未定义的。此时就会出现一个错误 -“Uncaught TypeError: Cannot read property ‘map’ of undefined" in the consol”。

解决的方法很简单:在构造函数中使用合理的默认值进行状态初始化。

2. TypeError: ‘undefined’ Is Not an Object (evaluating...)

这是在 Safari 中读取属性或调用未定义对象上的方法时发生的错误,这与 Chrome 的上述错误基本相同,只是 Safari 使用不同的错误消息。

3. TypeError: Null Is Not an Object (evaluating...)

这是在 Safari 中读取属性或调用空对象上的方法时发生的错误。

在实际情况中,导致这种错误的原因之一是:在元素加载之前,就尝试在 JavaScript 中使用 DOM 元素。这是因为 DOM API 对于空白的对象引用返回 null。

任何执行和处理 DOM 元素的 JS 代码,都应该在创建 DOM 元素之后执行。JS 代码按照 HTML 中的规定自上而下进行解释。因此,如果在 DOM 元素之前存在标签,则脚本标签内的 JS 代码就会在浏览器分析 HTML 页面时执行。如果在加载脚本之前尚未创建 DOM 元素,就会出现这样的错误。

在这个例子中,我们可以通过添加一个事件侦听器来解决这个问题,事件侦听器会在页面准备就绪时通知我们。一旦 addEventListener 被触发,该 init( ) 方法就可以使用 DOM 元素。

4. (unknown): Script Error

当未捕获的 JavaScript 错误违背跨边界原则时,就会发生脚本错误。例如,如果将 JavaScript 代码托管在 CDN 上,则任何未被捕获的错误(通过 window.onerror 处理程序发出的错误,而不是 try-catch 中捕获到的错误)将仅报告为“脚本错误”。这是浏览器的一种安全措施,主要用于防止跨域传递数据的情况出现。

要获取真实的错误消息,需要执行以下操作:

Access-Control-Allow-Origin


Access-Control-Allow-Origin 设置为 *, 表示可以从任何域正确访问资源。* 如有必要,也可以用自己的域名进行替换,例如:

Access-Control-Allow-Origin: www.example.com。

以下是在各种环境中设置的一些示例:

在脚本标签上设置crossorigin =“anonymous”

在你的 HTML 源代码中,为每一个脚本设置
Access-Control-Allow-Origin,在设置 SCRIPT 标签中,设置 crossorigin="anonymous"。在将 crossorigin 属性添加到脚本标签之前,请确保正在向脚本文件发送 header。在 Firefox 中,如果 crossorigin 属性存在但 Access-Control-Allow-Origin 标题不存在,则脚本不会执行。

5. TypeError: Object Doesn’t Support Property

当调用未定义的方法时,IE 中会发生这样的错误。

这相当于 Chrome 中的 “undefined’ is not a function” 错误。对于相同的逻辑错误,不同的浏览器可能会有不同的错误消息。

这是在 IE 的 Web 应用程序中使用 JavaScript 命名空间出现的一个常见问题。出现这种情况的绝大部分原因是IE无法将当前名称空间内的方法绑定到this关键字。例如,如果你有 JS Rollbar 方法的命名空间 isAwesome。通常,如果位于 Rollbar 命名空间内,则可以使用以下语法调用该 isAwesome 方法:

6. TypeError: ‘undefined’ Is Not a Function

当调用未定义的函数时,Chrome 中就会发生这样的错误。

执行上面的代码会导致以下错误:“Uncaught TypeError: undefined is not a function。” 发生以上错误的原因是,当你调用 setTimeout( ) 时,实际上是在调用 window.setTimeout( ),传递给 setTimeout( ) 的匿名函数是在窗口对象的上下文中定义的,而该窗口对象没有 clearBoard( ) 方法。

符合旧版浏览器的解决方案是以变量的方式简单地将引用保存在 this 中,然后通过闭包继承。

‘肆’ JS操作大量Dom数据时,假死现象

1:JS中大量的DOM操作也会导致事件响应缓慢甚至真正卡死浏览器,如在IE6下一次插入大量的HTML。而如果真的弹出了“脚本运行时间过长“的提示框则说明你的JS脚本肯定有死循环或者进行过深的递归操作了。

2:这时候需要对脚本进行优化,其步骤如下:

第一步,优化循环,循环体中包含太多的操作和循环的次数过多都会导致循环执行时间过长,并直接导致锁死浏览器。如果循环之后没有其他操作,每次循环只处理一个数值,而且不依赖于上一次循环的结果则可以对循环进行拆解,看下面的chunk的函数:

function chunk(array, process, context){
setTimeout(function(){
var item = array.shift();
process.call(context, item);
if(array.length >0){
setTimeout(arguments.callee,100);
}),100);
}
chunk()函数的用途就是将一个数组分成小块处理,它接受三个参数:要处理的数组,处理函数以及可选的上下文环境。每次函数都会将数组中第一个对象取出交给process函数处理,如果数组中还有对象没有被处理则启动下一个timer,直到数组处理完。这样可保证脚本不会长时间占用处理机,使浏览器出一个高响应的流畅状态。
其实看来,借助JS强大的闭包机制任何循环都是可拆分的,下面的版本增加了callback机制,使可再循环处理完毕之后进行其他的操作。

function chunk(array,process,cbfun){
var i=0,len = array.length; //这里要注意在执行过程中数组最好是不变的
setTimeout(function(){
process( array[i], i++); //循环体要做的操作
if( i < len ){
setTimeout(arguments.callee,100)
}else{
cbfun() //循环结束之后要做的操作
}
}
}

第二步,优化函数,如果函数体内有太多不相干但又要一起执行的操作则可以进行拆分,考虑下面的函数:

function dosomething(){
dosomething1();
dosomething2();
}
dosomething1和dosomething2互不相干,执行没有先后次序,可用前面提到的chunk函数进行拆分:

function dosomething(){
chunk([dosomething1,dosomething2],function(item){item();})
}
或者直接交给浏览器去调度

function dosome(){
setTimeout(dosomething1,0);
setTimeout(dosomething2,0);
}

第三步,优化递归操作,函数递归虽然简单直接但是过深的递归操作不但影响性能而且稍不注意就会导致浏览器弹出脚本失控对话框,必须小心处理。
看以下斐波那契数列的递归算法:

function fibonacci(n){
return n <2? n: fibonacci(n -1)+ fibonacci(n -2);
};
fibonacci(40)这条语句将重复调用自身331160280次,在浏览器中执行必然导致脚本失控,而采用下面的算法则只需要调用40次

fibonacci =function(n){
var memo ={0:0,1:0}; //计算结果缓存
var shell =function(n){
var result = memo[n];
if(typeof result !='number') //如果值没有被计算则进行计算
memo[n]= shell(n-1)+ shell(n -2)
return memo[n];
}
return shell(n);
}
这项技术被称为memoization,他的原理很简单就是同样的结果没必要计算两次。另一种消除递归的办法就是利用迭代,递归和迭代经常会被作为互相弥补的方法。

第四步,减少DOM操作,DOM操作的代价是相当昂贵的,大多数DOM操作都会触发浏览器的回流(reflow)操作。例如添加删除节点,修改元素样式,获取需要经过计算的元素样式等。我们要做的就是尽量少的触发回流操作。

el.style.width ='300px' el.style.height ='300px' el.style.backgroundColor ='red'
上面的操作会触发浏览器的三次回流操作,再看下面的方式:

el.className ='newStyle'
通过设置改元素的className一次设置多个样式属性,将样式写再CSS文件中,只触发一次回流,达到了同样是效果而且效率更高。因为浏览器最擅长的就是根据class设置样式。
还有很多可以减少DOM操作的方法,在此就不多说了,但是一个基本的原则就是让浏览器去做它自己擅长的事情,例如通过class来改变元素的属性。
相信经过上面的优化的过程必定可以大大提高用户体验,不会出现浏览器被锁死和弹出脚本失控的对话框,使你的浏览器从繁重的任务中解放出来。需要指出的是上面这些优化并不是必须的,只有当一段脚本的执行时间真的影响到了用户体验才需要进行。虽然让用户觉得脚本的执行变快了,但其实完成同一个操作的时间可能被延长了,这些技术只是让浏览器处于一个快速响应的状态,使浏览更流畅。

‘伍’ 解决vue页面DOM操作不生效的问题

现象:
使用Element
UI渲染了一个树形结构,设计在鼠标移入每个节点是显示其中的操作按钮,效果如下:
下面是出错部分:
在新增节点后移入新增节点附近(图中是移入一级2),功能按钮的显示位置出现偏移
原因查找:
经过调试发现是在新增节点后,执行DOM操作获取节点时,取到的仍是之前的结构,新增的节点并未获取到。
原因分析:
猜测是vue使用的虚拟DOM,使得页面虽然已经渲染出来,但在Vue实例中让处在在虚拟DOM中,无法获取。
解决方法:
使用Vue.nextTick,看下官方材料:
‘在下次
DOM
更新循环结束之后执行延迟回调',这句话不是特别理解,不过可以看出DOM更新是一个循环的过程,在过程结束之前无法获取到真实的DOM元素(至于这个循环是多久,还在探索中)。而将DOM操作放在nextTick中操作便可以获取到更新后的DOM。
结果:
依据上述原理,将DOM操作的函数在更新数据后在nextTick里调用,实现了理想中的效果。
以上这篇解决vue页面DOM操作不生效的问题就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持脚本之家。
您可能感兴趣的文章:vue指令以及dom操作详解

‘陆’ 页面中变量存太多变量会卡吗

不会。
页面卡顿应该不是全局变量过多造成的,通常会造成这种情况要么是出现了太密集频繁的dom元素操作,因为操作dom的开销是很大的,严重的话会阻碍浏览器UI引擎的渲染使页面感觉卡顿,这也是现今虚拟dom能在各种框架流行的原因;要么就是出现了时间复杂度过大的运算,例如嵌套多次的循环之类的,总之你要排查一下你的代码有没有逻辑不合理的地方,然后尝试去优化它,例如把太耗时的计算放入worker线程中去执行等。