JQuery Each() 함수는 DOM 구조 반복 성능을 어떻게 최적화합니까?

구체적인 구현을 모르고 jQuery를 사용하는 수준에만 머물면 문제가 발생하기가 정말 쉽습니다. 이것이 제가 최근에 jQuery를 별로 좋아하지 않는 이유입니다. 이 프레임워크의 API 설정은 사람들을 잘못된 길로 인도하는 것으로 의심됩니다.

코드 복사 코드는 다음과 같습니다.

$.fn.beautifyTable = function(options ) {
//기본 구성 항목을 정의한 다음 옵션으로 재정의합니다.
return this.each(function() {
var table = $(this),
tbody = table.children ('tbody'),
tr = tbody.children('tr'),
th = tbody.children('th'),
td = tbody.children('td'); >//단일 콘텐츠 클래스
table.addClass(option.tableClass);
th.addClass(options.headerClass); //1
td.addClass(options.cellClass) //2
//홀수 및 짝수 행 클래스
tbody.children('tr:even').addClass(options.evenRowClass); //3
tbody.children('tr:odd').addClass(options. oddRowClass); //4
//Alignment
tr.children('th,td').css('text-align', options.align); //5
//마우스 호버 추가
tr.bind('mouseover', addActiveClass); //6
tr.bind('mouseout', RemoveActiveClass) //7
//색상을 변경하려면 클릭
tr.bind( '클릭', 전환클릭클래스); //8
})


일반적으로 이 코드는 좋고, 아이디어도 명확하고, 논리도 명확하고, 하고 싶은 일이 댓글을 통해 명확하게 설명되어 있습니다. 하지만 저자에 따르면 테이블에 120개의 행이 있을 때 IE는 이미 스크립트 실행 시간이 너무 길다는 점을 반영했다고 합니다. 분명히 성능의 관점에서 볼 때 이 기능의 효율성은 높지 않거나 심지어 극도로 낮습니다.

그래서 코드 수준부터 분석을 시작했습니다. 이는 표준 jQuery 플러그인 함수입니다. return this.each(function( ) { .. };) 형식의 일반적인 코드가 있습니다. ; 작성자가 이 코드를 작성할 때 아무 생각 없이 스크립트를 따르지 않았다면 jQuery의 기능이 무엇인지 깨달았어야 했습니다.

간단히 말하면 jQuery.fn에 있는 대부분의 함수는 각각에 대한 호출입니다. 소위 말하는 각각은 자연스럽게 선택한 요소를 탐색하고 요소에 대해 지정된 작업을 수행합니다. 따라서 위의 코드를 살펴보고 얼마나 많은 순회가 수행되었는지 확인하세요. 120개의 행만 선택되었고 각 행에는 6개의 열과 1개의 헤더 행이 있다고 가정해 보겠습니다.
Traverse th, headerClass의 수를 추가합니다. 요소는 6입니다.
td를 트래버스하고 cellClass를 추가합니다. 요소 수는 6*120=720입니다.
모든 tr에서 홀수를 찾으려면 모든 tr을 한 번 순회해야 하며 요소 수는 120개입니다.
홀수 tr을 순회하고 evenRowClass를 추가하면 요소 수는 120/2=60입니다.
모든 tr에서 짝수를 찾으려면 모든 tr을 한 번 순회해야 하며 요소 수는 120개입니다.
짝수 tr을 순회하고,oddRowClass를 추가하면 요소 수는 120/2=60입니다.
th와 td를 모두 순회하고 text-align을 추가하면 요소 수는 120*6 6=726입니다.
모든 tr을 탐색하고 마우스 오버 이벤트를 추가하며 요소 수는 120입니다.
모든 tr을 탐색하고 mouseout 이벤트를 추가합니다. 요소 수는 120입니다.
모든 tr을 탐색하고 클릭 이벤트를 추가하며 요소 수는 120입니다.
편의상 단순히 순회 중에 요소에 액세스하는 데 10ms가 걸린다고 가정합니다. 그러면 이 기능에는 총 얼마나 걸리는가요? 이 함수는 총 2172개의 요소를 발견했으며 21720ms, 즉 21초가 걸렸습니다. 분명히 IE는 스크립트가 너무 오래 걸렸다고 보고해야 합니다.

이제 효율성이 낮은 이유를 알았으니 근본적으로 해결해야 합니다. 당연히 코드에 있는 주석의 숫자에 따라 루프를 병합하는 방법을 찾아야 합니다. 위에서는 최소한 다음 사항을 병합할 수 있습니다.
3과 4를 하나의 주기로 결합할 수 있습니다(120 60 120 60에서 120, 240으로 감소). 1, 2 및 5를 하나의 주기로 결합할 수 있습니다. 6 720 726에서 726으로, 726이 감소합니다. 6. 7과 8을 하나의 주기로 결합하여 120 120 120에서 120으로 변경하면 240이 감소합니다. 또한 3, 4와 6, 7, 8을 하나의 주기로 결합할 수 있으며, 이는 계속해서 120씩 감소됩니다. 누적적으로 총 240 726 240 120 = 1326 요소 작업을 줄여 총 13260ms를 단축했습니다. 최적화 후 함수 시간 소비는 21720-13260=8460ms, 즉 8초가 됩니다.
여기서 질문이 있을 수 있습니다. 테이블의 구조에서 모든 th 및 td 요소는 tr 내에 있어야 하는데 1, 2, 5의 3단계 주기도 tr에 넣으면 어떨까요? 루프, 중첩 루프를 형성하면 더 빠르지 않을까요?
여기에서 이 작업이 수행되지 않는 두 가지 주요 이유는 다음과 같습니다.
첫째, 1, 2, 5를 어디에 배치하든 모든 th 및 td 요소에 대한 액세스 권한이 줄어들지 않습니다.
반면 선택기 $('th, td')는 sizzle의 getElementsByTagName 함수에 대한 두 번의 호출로 변환됩니다. 처음에는 모든 th를 가져오고 두 번째는 모든 td를 가져온 다음 수집합니다. 합병의 그들. getElementsByTagName은 내장 함수이기 때문에 이 함수는 루프가 없다고 볼 수 있다. 즉, 복잡도는 O(1)이다. 동일한 컬렉션의 병합은 연산인 Array의 관련 함수를 사용한다. 메모리에 있으며 복잡성도 O(1) 입니다.

반대로 선택기 $('th, 'td)가 tr 요소의 루프에서 사용되면 getElementsByTagName은 tr 요소에서 두 번 호출됩니다. 왜냐하면 어떤 요소에서 함수가 호출되는지에 관계없이 발생하기 때문입니다. , 함수 실행 시간은 동일하므로 tr을 반복할 때 사용하면 함수 호출이 119*2개 더 많아지고 효율성은 늘어나지 않고 감소합니다.
sizzle 선택기에 대한 기본 지식도 jQuery 코드 최적화에 도움이 되는 매우 중요한 측면임을 알 수 있습니다.
자바스크립트가 모든 것을 하도록 두지 마세요.

이전 기본 최적화에 따르면 시간이 21초에서 8초로 줄어들었지만 8초라는 숫자는 당연히 용납할 수 없는 수치입니다.
우리 코드에 대한 추가 분석에 따르면 실제로 루프 순회는 언어 수준에 있으며 속도가 상당히 빨라야 합니다. 각 요소에 대해 수행되는 작업은 jQuery에서 제공하는 기능으로 순회에 비해 대부분의 리소스를 차지합니다. 순회 중에 요소에 액세스하는 데 10ms가 걸리는 경우, 직설적으로 말하면 addClass를 실행하는 데 최소 100ms가 소요됩니다.

따라서 효율성을 더욱 최적화하려면 요소에 대한 작업을 줄이는 것부터 시작해야 합니다. 코드를 주의 깊게 검토한 결과, 이 함수의 스타일에 최소한 다음을 포함하여 많은 수정 사항이 있음을 발견했습니다.
Add class to all th.
모든 TD에 클래스를 추가하세요.
tr의 홀수 라인과 짝수 라인에 클래스를 추가하세요.
모든 th 및 td에 텍스트 정렬 스타일을 추가합니다.
사실 우리는 CSS 자체에 하위 항목 선택기가 있고 브라우저의 CSS 기본 구문 분석이 JavaScript가 요소에 클래스를 하나씩 추가하도록 하는 것보다 훨씬 더 효율적이라는 것을 알고 있습니다.

따라서 CSS를 제어할 수 있는 경우 이 함수에는 headerClass와 cellClass의 두 구성 항목이 없어야 하며 가능한 한 CSS에서 구성해야 합니다.

코드 복사 코드는 다음과 같습니다.

.beautiful-table th { /* 헤더 클래스의 내용*/ }
.beautiful -table td { /* content of cellClass*/ }

또한 tr의 홀짝수 행 스타일의 경우 n번째 자식 의사 클래스를 사용하여 일부 브라우저에서 구현할 수 있습니다. 관련하여, 이 의사 클래스를 지원하지 않는 브라우저에서만 addClass를 사용하여 기능 감지를 사용하여 스타일을 추가할 수 있습니다. 물론 IE 시리즈만을 최적화하고 싶다면 이 항목을 무시해도 됩니다.

n번째 하위 의사 클래스를 감지하려면 다음 아이디어를 사용할 수 있습니다. 스타일시트를 만든 다음 #testspan:nth-child(odd) {display:block과 같은 규칙을 만듭니다. ; 해당 HTML 구조, ID 테스트가 포함된 div를 만들고 그 안에 3개의 범위를 배치합니다.

DOM 트리에 스타일시트와 div를 추가합니다. 1번째와 3번째 스팬의 런타임 표시 스타일을 확인하세요. 블록인 경우 의사 클래스가 지원된다는 의미입니다. 생성한 스타일시트와 div를 삭제하고 프로브 결과를 캐시하는 것을 잊지 마세요. 마지막으로 모든 th 및 td 요소에 텍스트 정렬 스타일을 추가하는 것도 CSS를 통해 최적화할 수 있습니다. 어떤 정렬이 추가되는지 모르므로 몇 가지 스타일을 더 작성하세요.

코드 복사 코드는 다음과 같습니다. :

/* CSS 스타일*/
.beautiful-table-center th,.beautiful-table-center td { text-align: center !important }
.beautiful- 테이블 오른쪽오른쪽 td { 텍스트 정렬: 오른쪽오른쪽 !중요 }
.beautiful-테이블-왼쪽 th,.beautiful-테이블-왼쪽 td { 텍스트 정렬: 왼쪽 !중요 }
/* javascript */
table.addClass('beautiful-table-' options.align)

물론 위에서 언급한 최적화는 CSS에 대한 제어를 기반으로 합니다. , CSS 스타일에 액세스할 수 없는 경우 어떻게 해야 합니까? 예를 들어 이것은 완전히 제어할 수 없는 제3자가 사용할 일반 플러그인 기능입니까? 완전히 불가능한 것은 아닙니다.
document.styleSheets와 같은 페이지에서 모든 CSS 규칙을 찾으세요. 모든 규칙을 순회하여 구성 항목에서 headerClass, cellClass 등을 꺼냅니다. 필요한 여러 클래스에서 모든 스타일을 추출한 다음 이를 beautiful-table th와 같은 새로운 선택기로 직접 조립합니다. 생성된 선택기를 사용하여 새 스타일시트를 생성하고 이를 DOM 트리에 추가합니다. 그런 다음 테이블에 beautiful-table 클래스를 추가하면 작업이 완료됩니다.

물론 위의 접근 방식은 실제로 시간이 많이 소요됩니다. 결국 스타일시트를 순회하여 스타일시트를 만들어야 합니다. 효율성을 높이는 데 큰 도움이 되는지 여부는 페이지 크기에 따라 달라지며, 기능 디자이너의 구체적인 요구 사항에 따라 다릅니다.

일반적으로 자바스크립트를 최대한 적게 실행하고 CSS에 더 많은 스타일링 작업을 전달하면 브라우저의 렌더링 엔진이 이를 완료하며, 이 기능은 addClass 및 CSS에 대한 호출에 대해 더욱 최적화될 수 있습니다. 100ms가 걸리므로 이 최적화는 원래의 120 726 = 846 작업을 직접 제거하고 84600ms의 시간을 절약합니다(물론 과장이지만 전체 기능의 소비 측면에서 이는 정말 큰 부분입니다).

이 기사에서는 jQuery의 다양한 구현 수준을 최적화하려고 할 뿐이며 jQuery의 전체 실행 프로세스에 대한 분석, 세부 소개 및 최적화 방향만 포함하며 일부 기본 최적화 방법에 대해서는 언급하지 않습니다. as: 먼저 DOM 트리에서 전체 테이블을 제거한 다음 다시 그리기를 줄이기 위해 모든 작업을 완료한 후 다시 DOM에 넣습니다. 올바른 이벤트 버블링 모델로 인해 발생하는 반복되는 이벤트 함수의 실행을 줄이기 위해 mouseover 및 mouseout을 mouseenter 및 mouseleave로 변경합니다. th 및 td와 같은 간단한 요소를 선택하려면 기본 getElementsByTagName을 사용하여 선택기를 분석하는 데 소요되는 시간을 줄이는 것이 우선순위입니다.

마지막으로 이 글에서는 프론트엔드 개발자들에게 비록 브라우저가 블랙박스일 수도 있지만, 이전에 어느 정도 이해할 수 있다면 많은 프레임워크, 도구, 라이브러리가 열려 있다는 점을 설명하고 싶습니다. 이를 사용하면 확실히 개인 기술을 향상시키고 최종 제품의 품질을 최적화하는 데 도움이 될 것입니다. "알지만 이유를 모른다"는 것은 매우 금기시되는 상황입니다.