프런트엔드tree 최적화 실천: 렌더링 속도 14.65s에서 0.49s

전편 주요 사상: 귀속의 본질은 창고의 읽기이다

먼저 효과 대비를 보다

다음은 모두 10000개의 노드 데이터를 바탕으로 비교하고 최종 데이터를 먼저 비교한다.
귀속판tree, 렌더링 속도:14.65s, 클릭 노드 처리 속도:9.83s
최적화 버전tree, 렌더링 속도:0.49s, 클릭 노드 처리 속도:0.18s
귀속 구성 요소 구현tree: 렌더링 속도 15.71s -1.06s = 14.65s
역귀판tree성능도-1
귀속 구성 요소 버전tree 클릭 노드 성능 분석도: 클릭 노드 처리 속도: 10.19s - 0.357s = 9.833s ≈9.83s
귀속tree 클릭 노드맵-2
최종 최적화 tree: 렌더링 속도 2.25s - 1.76s = 0.49s
최적화 tree 성능도 -3
최적화판tree 클릭 노드 성능 분석도: 클릭 노드 처리 속도 0.623s - 0.3s = 0.3s
tree 클릭 노드 그림 최적화 - 4
최종 대비:
귀속판tree, 렌더링 속도:12.19s, 클릭 노드 처리 속도:9.52s
최적화 버전tree, 렌더링 속도:0.49s, 클릭 노드 처리 속도:0.18s

문제를 분석하다

우리는 performance를 빌려 귀속 구성 요소의 소모 시간점을 분석하고 상귀속 구성 요소의 렌더링 성능 분석을 할 수 있다.

1.script 시간 소모 분석:

역귀tree script 성능 분석도 - 5
그림-1 성능 폭포를 통해 스크립트의 실행이 8.9s를 차지하는 시간을 뚜렷하게 볼 수 있다. 위의 그림인 그림-5를 통해 스크립트의 호출 창고는 주로 vue 실례를 만들 때의createChildren에 집중되어 있음을 알 수 있다.

2. render 소모 시간 분석

역귀tree render 성능 분석도 - 6
위의 그림인 그림-6을 통해 렌더의 소모 시간은 주로 Recalculate Style, Layout 위에 집중되어 있음을 뚜렷하게 볼 수 있다.Recalculate Style, Layout은 주로 스타일 컴퓨팅인 것을 알고 코드를 확인합니다.
귀속 구성 요소 부분 코드맵 - 7
귀속된tree-node 구성 요소 안에 많은 양식의 계산이 있음을 발견했고 10000개의 노드는 10000번의 계산이 필요하다.

3. DOM 구조 분석

반복 어셈블리 DOM 맵 -8

사상을 실현하다

우리의 개편 사상을 살펴보자. 귀속의 본질은 창고의 읽기이다.
알고리즘에서 우리는 많은 귀속 실현 사례를 만날 수 있다. 모든 귀속은 비귀속 실현으로 전환할 수 있다. 그 중에서 전환의 본질은 귀속은 해석기(엔진)로 창고의 접근을 도와주고 비귀속은 수동으로 창고를 만들어서 창고의 접근 과정을 모의하는 것이다.
만물은 서로 통하고 귀속 구성 요소도 편평수 그룹으로 변환하여 실현할 수 있다.
1. DOM 구조를 평형 구조로 바꾸고 노드와 노드의 시각적 양식을 클릭하여 총list 데이터를 조작하여 실현
2. 그리고 가상 길이 목록을 사용하여 vue 서브 구성 요소의 실제 생성 수량을 제어합니다.

최적화 버전 구현

주로 두 가지 기능으로 나뉜다.
1. tree 데이터와 DOM 구조의 편평화;
2. 가상 길이 목록은 DOM 렌더링 수량을 제어합니다.

1. tree 데이터와 DOM 구조의 편평화

최적화 버전 tree의 DOM 구조도 -9
위의 그림에서 우리는 개조된tree의DOM구조를 볼 수 있다. 부모 노드와 하위 노드는 등급이 같고 하위 노드를 조작할 때 메모리에 있는listData 데이터를 조작하여 관련 노드의 상태를 바꾸는 것을 볼 수 있다.
listData 데이터의 구조를 살펴보겠습니다.
최적화판treelistData 데이터 구조도 -10
위의 그림은 그림-10과 그림-9의 DOM 구조를 결합하면 전체 기능의 실현 논리를 한눈에 볼 수 있다.
listData의 모든 항목의 스타일, checked, path 등 정보로 노드의 스타일 위치와 상태를 설명하고, 한 노드를 조작할 때listData를 통해 관련 노드의 상태 스타일 등 정보를 변경합니다.
그래서 최종적으로 우리의 코드를 쓴다.
실현vue 코드맵-11
handle CheckChange가 무엇을 했는지 살펴보겠습니다.
handleCheckChange 처리 논리도 -12

2. 가상 길이 목록은 DOM 렌더링 수량을 제어합니다.

아이디어 실현:
루트 DOM은 두 개의 하위 노드로 나뉘어집니다.fui-treephantom 및 fui-treecontent.
두 개의 하위 노드는 모두 절대적인 포지셔닝입니다. 스크롤할 때 데이터의 변경을 피하기 위해 스크롤 이벤트를 터치합니다.
가상 목록 DOM 조직 맵-13
루트 노드는 두 개의 하위 노드 css를 해제합니다.

.fui-tree {    height: 400px;    overflow: auto;    position: relative;  }  .fui-tree__phantom {    position: absolute;    left: 0;    top: 0;    right: 0;    z-index: -1;  }  .fui-tree__content {    left: 0;    right: 0;    top: 0;    position: absolute;  }

그리고 우리는 스크롤 바의 위치를 통해 우리가 어떤 데이터를 취해야 하는지 계산한다.
기본 코드:
가시 영역 데이터의 시작과 끝을 계산하는 인덱스 index 그림 - 14
startIndex,endIndex를 통해 우리가 순환해야 할 데이터 목록renderNodes를 꺼낼 수 있습니다:

computed: {      renderNodes() {        if (!this.treeNode) return []        return this.treeNode.listData.slice(this.positionConfig.startIndex, this.positionConfig.endIndex)      },      phantomStyle() {        return {          height: this.allListLen * 20 + 'px'        }      }    }

그림-11의 v-for를 결합하면 우리가 렌더링할 때의dom 수량은 고정된 줄 수이다. 다음과 같다.
최적화된 tree DOM 수량은 고정된 그림 - 15
가상 목록의 접속은 아무리 많은 데이터량이 있어도 고정된 DOM 수량을 렌더링할 수 있어 더 큰 데이터의 렌더링과 기능을 지탱할 수 있다.
이상에서 우리는 업무 수요의 빅데이터 렌더링을 실현했다. 현재 테스트는 20w개의 노드를 지탱할 수 있다. 서브 노드를 클릭할 때 육안으로 볼 수 있는 지연이 있다. 주로 그림-12에서handle CheckChange의 데이터 검색과 처리이다. 이 부분은 일정한 최적화 공간이 있다. 사전 트리를 사용하여 노드와 관련된 정보를 저장하고 사전 트리와 편평수 그룹list 데이터의 모든 요소는 같은 메모리 주소를 가리킨다.handleCheckChange에서 사전 트리를 조작하여listData 요소를 조작하는 효과, 고전적인 공간 교환 시간의 사례를 얻을 수 있습니다.

참조 링크

https://zhuanlan.zhihu.com/p/34585166

https://juejin.im/post/5c41543a51882525da2656f9

더 많은 내용은 앞머리를 주목해 주십시오.
회의 추천
2019년 6월, GMTC 글로벌 프런트엔드 기술 콘퍼런스 2019를 앞두고 있습니다.애플릿, 플루터, 모바일 AI, 엔지니어링, 성능 최적화...프런트엔드 다음 사이트는 어디입니까?아래 그림을 클릭하여 더 자세한 정보를 보십시오.