소개하다.

Material-UI는 유행하는 구성 요소 라이브러리(Reactstrap와 경쟁자)로 React와Material Design를 통일시키고 후자는 구글이 구축한 디자인 시스템이다.
React 개발자로서 저는 수많은 프로젝트에서 Material UI를 사용한 적이 있습니다. 이것은 격자 시스템, 많은 구성 요소와 함께 제공되고 일치된 UI를 신속하게 구축하는 데 도움이 되는 훌륭한 라이브러리라고 말해야 합니다.
내가 그것을 개인 개원 프로젝트Ammo에 사용하기 전에 나는 그것에 대해 매우 만족했다.

Quick parenthesis about Ammo: it's an open source projects which aims at capturing http requests and turn them into stress test engines scripts (such as Gatling). Not the focus of this article though, I won't dive into more details.

배경.

물질 사용자 인터페이스에 대한 불만을 폭로하기 전에 내 발악을 살펴보자.
《탄약》에서 나는 다음과 같은 물품 명세서를 가지고 있다.

목록의 각 항목을 축소/압축해제할 수 있습니다.

여기서 보듯이, 물건을 풀 때, 그것은 약간의 물건을 나타내지만, 너무 화려하거나 복잡하지는 않다.왼쪽에서 텍스트가 있는 기본 HTML div를 볼 수 있습니다. 오른쪽에 코드 세션이 있습니다. (React syntax highlighter 포맷/미화)
그러나 나는 곧 응용 프로그램의 전체 성능이 매우 나쁘다는 것을 알아차릴 것이다.
뭐?

제1차 조치

코드 세션 강조 디스플레이 기능을 개발한 후에 이 기능에 100% 만족하기 위해 목록에 항목을 추가하고 문법 강조 디스플레이 라이브러리가 응용 프로그램의 성능을 파괴하지 않았는지 확인했습니다.
그 생각은 공연 결과가 엉망이었기 때문에 의미가 있다는 것이 증명되었다.
얼마나 엉망인지 설명하기 위해서, 다음은gif입니다. 인터페이스에 50항목을 추가할 때 발생하는 상황을 보여 줍니다. (설정 간격을 사용하여 300ms당 1항목을 추가합니다.)

보시다시피 응용 프로그램은 매우 낙후되어 사용하기에 매우 고통스럽다.50개밖에 없어요!
게임 배경에서 왔으니 60 프레임/초의 속도로 그림, 애니메이션, 음향 효과, 음악, 다중 배경 등을 보여야 한다. HTML div만 보일 때 이런 지연을 보는 것은 정말 견디기 어렵다.그래서 제가 잠입해서 분석을 했습니다.

정치 박해: 반응판

나의 첫 번째 직감은 React에 문제가 생겼다는 것이다.어쨌든, 나는 과거에 많은 응용 프로그램이 불필요한 렌더링과 성능 방면의 나쁜 방법을 가지고 있는 것을 본 적이 있다.그래서 내가 하는 첫 번째 일은 목록이 최적화되는 것을 확보하고 두 가지를 하는 것이다.

목록의 항목마다 인덱스가 아닌 유일한 키를 제공합니다

새 항목을 추가할 때 다시 렌더링되지 않도록 렌더링된 항목을 기억합니다.나는 memo를 사용했지만 useMemo도 마찬가지로 효과가 있다.

그런 다음 애플리케이션을 분석했습니다.

우리는 다음과 같은 점을 주목할 수 있다.

우선 회고록이 잘 작동하는 것 같다.렌더링된 항목이 회색으로 표시되어 다시 렌더링되지 않았음을 알 수 있습니다

.

새로 도입된 프로젝트는 렌더링 시간이 좀 걸리는 것을 알 수 있습니다

.
하지만 걱정되는 것은 오른쪽 상단의 도표다.보시다시피 렌더링은 시간이 지날수록 느려집니다.새 항목의 렌더링을 시작하려면 약 100ms가 필요하지만 리스트가 길어지면 500ms가 필요합니다.
뭐?
우선, 목록의 항목 수가 새 항목의 렌더링 시간에 어떤 영향을 줍니까?그리고 500밀리초 동안 기본적인div를 렌더링하세요!말똥!
항목 렌더링에 대한 분석을 확대합니다.

이 사진에서 나는 두 가지를 강조했다.

오른쪽에서 볼 수 있듯이 나의 첫 번째 걱정원인 react 문법 형광등은 성능이 좋지 않은 원인이 아니다.빠른 렌더링 속도

상당히 오래 걸릴 것 같은 것은'제목'(왼쪽)이다.

명확한 것은 이것이 제목이라는 것이다.

사실 아무것도 아니야, 단지 두 개의 내연 텍스트만 있어!왜 이렇게 느려???내 견해를 한층 더 증명하기 위해 다음과 같은 것은 <Header> 구성 요소의 코드이다.

<Box className={classes.values}>
    <Typography variant="subtitle2">
        <span>{key}</span> :
        <span className={classes.headerValue}>
            "{value}"
        </span>
    </Typography>
</Box>

이곳에는 신기한 것이 거의 없다.숨겨진 성능 경고가 없습니다. 이것은 몇 가지 기본div입니다.

이 모든 것은 재료 인터페이스에 귀결된다

매우 절망적이었다. 나는 많은 것을 시도했고, 많은 논단을 훑어보았으며, 리액션이 어떻게 일을 이렇게 엉망으로 만들었는지 여전히 알아내려고 했다.그리고 생각에서 나는 <Box>로 <div> 구성 요소를 교체해 보았다.

<div className={classes.values}>
    <Typography variant="subtitle2">
        <span>{key}</span> :
        <span className={classes.headerValue}>
            "{value}"
        </span>
    </Typography>
</div>

놀랍게도 나는 약간의 개선된 모습을 보았다.더 나아가 중요한 UI 구성 요소(주요적<Box>와 <Typography>를 최대한 없애려고 노력한 결과 다음과 같은 결과를 얻었습니다.

만약 네가 정확하게 읽었다면, 너는 발견할 수 있을 것이다.

이 테스트는 500개의 항목(약 1000개의 렌더링)을 사용하여 수행됩니다.그리고 얘는 흐르는 거야!

최대 렌더링 피크는 50개 항목 500ms가 아닌 ~110ms

입니다.

항목 표시 시간은 일치합니다. 목록

에 있는 항목의 수량에 따라 증가하지 않습니다.

그래서 이것은 거대한 승리다!현재 이 앱의 물품은 10배 증가하여 상당히 원활하다!그리고 그것의 성능은 일치한다!

결론

Material UI는 훌륭한 라이브러리입니다. 지난 몇 년 동안 제 지원을 받아 왔지만, 지금은 응용 프로그램에 성능 도전이 있을 수 있으니 사용하지 말라고 강력히 권장합니다.간단한 폼이나 표준적인 웹 페이지가 문제가 되어서는 안 되지만, 이 점을 기억해 주십시오.
물론 나는 처음으로 이런 문제들을 발견한 사람이 아니다. Github (this one for example 에는 해결해야 할 몇 가지 문제가 있다.
그 밖에 이 모든 최적화가 끝난 후에도 당신은 프로젝트의 110밀리초 과장 시간이 여전히 길다고 말할 수 있습니다. 나는 동의하지만, 나는 잠시 일을 여기에 남겨 두겠습니다.어떤 진일보한 최적화도 새로운 문장의 좋은 주제가 될 것이다.