MzTreeView1.0 트리 컨트롤이 출시된 이후로 많은 피드백을 받았고 많은 네티즌들이 이 컨트롤에 대한 많은 관련 제안과 많은 버그와 단점을 지적했기 때문에 새 버전을 작성할 계획입니다. Tree는 모든 사람의 제안을 구현에 통합합니다. 요즘 새 버전의 트리를 작성하고 있는데 트리 제어에서 가장 중요한 것은 효율성입니다. 특히 노드 수가 많은 경우에는 약간 덜 효율적인 모드가 브라우저를 다운시키게 됩니다. 트리에서는 비동기 데이터 로딩에 대한 지원을 추가하는 등 효율성을 높이는 것이 최우선 과제입니다. 또한 트리 구조의 수직선을 스타일 시트(배경 이미지)를 사용하여 구현하는 아이디어도 있습니다. 스타일 시트 배경 이미지는 한 번만 로드하면 되며 이제 이 모드(여러 <img> 사용) 이미지에 캐싱 메커니즘이 있지만 여전히 각 작은 이미지에 대해 한 번씩 서버에 요청할 수 있으므로 얼마나 좋은지 생각했습니다. 이를 달성하기 위해 스타일 시트를 사용하는 것입니다. 코드가 간소화되고 구조가 명확하며 효과가 훌륭하지만 거의 일주일 동안 테스트한 결과 렌더링 효율성이 완전히 실패했습니다. 스타일 시트가 너무 열악합니다. 새로운 아이디어는 실현되지 못했고, 약간의 답답함도 느꼈지만, 테스트 결과를 모두와 공유해야겠다는 생각이 들었습니다.
여기서는 트리 모양의 수직선에 대해 설명하겠습니다. 트리 왼쪽에 ┌ ├ └ │가 있는데, 이 수직선은 트리 레벨을 하나씩 쌓아서 사용했습니다. 사용 종류 스타일 시트는 <div class="l2"></div>와 같은 코드를 사용하여 구현되며, 스타일 시트는 배경 이미지를 채우는 역할을 합니다.
#mtvroot div td{너비:20px;높이:20px;}
#mtvroot .l0{배경:url(line0.gif) 반복 없음 센터}
#mtvroot .l1{배경:url(line1.gif) 반복 없음 센터}
#mtvroot .l2{배경:url(line2.gif) 반복 없음 센터}
#mtvroot .l3{배경:url(line3.gif) 반복 없음 센터}
#mtvroot .l4{배경:url(line4.gif) 반복 없음 센터}
#mtvroot .ll{배경:url(line5.gif) 반복 없음 센터}
#mtvroot .pm0{배경:url(plus0.gif) 반복 없음 센터}
#mtvroot .pm1{배경:url(plus1.gif) 반복 없음 센터}
#mtvroot .pm2{배경:url(plus2.gif) 반복 없음 센터}
#mtvroot .pm3{배경:url(plus3.gif) 반복 없음 센터}
#mtvroot .expand .pm0{배경:url(minus0.gif) 반복 없음 센터}
#mtvroot .expand .pm1{배경:url(minus1.gif) 반복 없음 센터}
#mtvroot .expand .pm2{배경:url(minus2.gif) 반복 없음 센터}
#mtvroot .expand .pm3{배경:url(minus3.gif) no-repeat center}
위 CSS는 나중에 설명을 돕기 위해 스크립트에서 동적으로 생성한 스타일의 일부입니다. 스타일 시트를 사용한 후에는 정말 간소화되었고 각 노드의 생성 속도가 충분히 빨랐습니다. 그러나 예를 들어 트리 노드 수가 300-500개 노드에 도달하면 노드 생성 효율성이 아무런 영향을 미치지 않는다는 것을 알았습니다. , 그러나 매번 노드의 확장/축소는 몇 초 또는 심지어 10초 이상 걸릴 정도로 매우 느리며, 이 기간 동안 CPU 사용량은 100%입니다. 설명하자면, 트리의 확장/축소는 상위 노드의 style.display = none|block을 설정하여 이루어집니다. 내 컴퓨터 구성은 AMD2800+ 1GDDR400 메모리이며 구성은 나쁘지 않습니다.
나의 첫 번째 반응은 '너무 많은 <table>을 사용하면 효율성에 영향을 미치나요?'였습니다. 각 노드마다 <table>을 사용하는데 <table>을 <div>, <span> 등으로 대체했지만 효율성이 향상되지 않아 CPU 사용량이 100%가 되는 문제는 발생하지 않는다는 의미입니다. HTML 태그의 문제, 남은 문제는 여기서 스타일 시트를 사용하는 것입니다.
500개의 노드를 예로 들면, 1.0에서는 왼쪽에 약 2,000개의 작은 그림이 쌓이게 됩니다. 이런 경우에는 브라우저가 로컬로 캐시되지 않도록 설정하면 큰 문제가 발생하게 되는데, 이렇게 작은 그림들을 많이 불러오려면 시간과 서버 리소스가 많이 소요되기 때문에 이제 이 새로운 스타일 시트를 사용하게 되었습니다. 스타일 시트 방식. 즉, 배경 이미지를 렌더링하기 위해 스타일 시트가 필요한 곳이 약 2,000군데 있다는 뜻입니다. 다양한 상황을 테스트해본 결과 1.0 버전의 코드와 비교해본 결과, CPU 사용률이 너무 높은 이유는 렌더링에 시간이 많이 걸린다는 결론에 도달했습니다. 검증도 매우 간단합니다. 위 스타일시트의 왼쪽에 있는 #mtvroot 부분을 제거했습니다. 이는 스타일시트의 종속 관계를 제거한다는 의미입니다. 테스트 결과 효율성은 많이 향상되었으나 시간 소모가 많이 발생했습니다. 여전히 상당한 시간입니다. 3~5초 정도입니다.
게다가 다른 브라우저로 바꿔봤는데 테스트 결과도 달라요. 가장 역겨운 건 IE에서요. 예를 들어 특정 노드에 자식 노드가 500개 있으면 닫아버리죠(CPU 100%, 3시간 기다립니다). -5초), 즉 display="none"입니다. 이때 이 노드의 상위 노드를 축소하면(이 노드에는 다른 형제 노드가 없습니다. 즉, 해당 상위 노드에는 이와 같은 하위 노드가 하나만 있습니다) , 노드가 하나만 있는 것은 당연한 일이지만, 결과는 3~5초 동안 CPU가 100%가 된다는 의미입니다. HTML 개체는 해당 부모인 display="none"에 의해 숨겨져 있습니다. 레벨에서 작업이 수행되면 IE는 스타일 시트를 사용하여 이러한 숨겨진 개체를 다시 렌더링합니다. IE 개발자가 무슨 생각을 했는지 정말 모르겠습니다.
다시 테스트하러 FIREFOX에 갔습니다. 접었을 때(display=none) 순간적으로 숨겨진 물체를 다룰 때 FF가 더 이상 에너지를 소비하지 않을 것이라고 확신할 수 있습니다. 물론 확장 시에는 모든 브라우저가 동일합니다. CPU 100%로 3~5초 정도 소요되지만 FF가 조금 더 빠릅니다.
위의 현상을 통해 저는 다음과 같은 결론에 도달했습니다. 동적으로 렌더링할 때 스타일 시트는 효율적이지 않습니다. 상위 컨테이너가 상태 변경을 감지하면 FireFox는 디스플레이=를 처리하여 모든 하위 객체의 스타일 시트를 다시 렌더링하게 됩니다. noneHidden 개체는 다시 렌더링되지 않지만 IE는 다시 렌더링됩니다.
그렇다면 왜 이 스타일 시트 렌더링 효율성 문제가 이전에 발견되지 않았습니까? 웹 페이지를 만들 때 배경 이미지를 렌더링하기 위해 스타일 시트가 필요한 페이지에 수천 개의 배경 이미지가 있는 경우는 거의 없습니다. 일반적으로 장소는 몇 군데, 수십 군데 밖에 없기 때문에 렌더링의 효율성을 느낄 수 없으며, 이와 관련하여 브라우저별 차이도 느낄 수 없습니다. 그러나 트리와 같은 컨트롤을 만들 때 큰 데이터 배열, 생성된 HTML 개체 수 등과 같은 다양한 극단적인 문제에 직면하게 됩니다. 렌더링 효율성의 차이는 JS 스크립트를 작성할 때만 나타나는 문제 중 하나입니다. 마주쳤다. 오늘 이 테스트 결과가 앞으로 모든 분들이 프로그램을 작성하실 때 참고하시고, 디자인하실 때 참고하시길 바라면서 공유합니다.
마지막으로, 제가 작성한 컨트롤에 대한 여러분의 확인과 지지에 감사드립니다. 감사합니다!