⌛ 요약 시간

지난 블로그에서 단 2주 만에 앱 크기를 75MB에서 34MB로 줄인 방법에 대해 이야기했습니다(보기!). 하지만 그게 다가 아닙니다. 또한 앱의 전반적인 성능을 최대 80%까지 향상시켰습니다. ?.

방법을 알아봅시다 !!

? 지식

간단한 검토 후에 저는 우리 앱에서 사용자 경험과 성능을 일방적으로 저하시키는 주요 문제 중 몇 가지를 발견했습니다. 정말 좋은 하루였어요!

• 주요 악당 - 실시간 응답 생성 중 전체 앱 UI 정지

• Side Villain - 느린 응답 시간 및 프레임 속도 없음

• 악당의 연인 - API 호출이 너무 많습니다.

• The Undead Army - 잘못된 오류 처리 및 충돌

• 고통 - CPU 사용량 및 서버 비용 증가

• 변색된 - 나 !

더 나은 세상을 희망하며 우주를 재창조하는 생명 없는 싸움이 시작된다.

타히티 계획(그러나 이번에는 성공했습니다)

그래서 대공황을 지금 당장 극복하기보다는 무시하는 것이 쉽기 때문에 쉬운 문제부터 먼저 해결하기 시작했습니다.

1. ⚛️ 반응의 저주

ReactJ의 지혜와 저주는 상태입니다. React에서 나이가 들수록 상태가 적을수록 애플리케이션이 더 좋아진다는 것을 깨닫게 됩니다. 따라서 이 특정 예술 작품은 단일 채팅 화면에서 22(예 빌어먹을 useStates)를 사용하여 메시지를 보내고 받는 것뿐입니다.

위에 체리 !
우리는 서버에서 청크 단위 데이터를 가져오기 위해 서버 측 이벤트 구현을 사용하고 있었는데, 이 경우에는 단어 단위였습니다. 따라서 응답이 100단어인 쿼리가 있는 경우(이것은 응답이 가장 적습니다). 실제로 100개의 이벤트를 수신하게 됩니다.

따라서 수학을 안다면 응답을 받을 때마다 100*22 = 2200번 다시 렌더링됩니다.

더 이상 설명해야 합니까? ( 아니요 )

그래서 전체 화면을 다시 만들기 시작하고 이제 숫자를 6개 상태로 줄였습니다. 이전보다 더 좋고 부드러운 기능을 제공합니다.

이전보다 72% 더 성능이 향상되었습니다 !!

2. ❄️ 얼어붙은 사막

이제 React의 Radahn을 목격하고 나면 앱이 꽤 많이 정지될 것이라는 결론을 쉽게 내릴 수 있습니다. 그렇죠?

이제 6개 주에서도 주요 문제는 100*6으로 동일하게 유지됩니다. 우리는 여전히 매달리고 있지만 상태는 더 적습니다.

주요 원인은 React DOM이 각 청크에서 업데이트된다는 것입니다. 그래서 이 문제를 해결하기 위해 우리는 "일괄 처리 및 프레임 속도 생성을 사용했습니다.

이런 젠장!

기본적으로 청크를 얻을 때마다 DOM을 업데이트하는 대신 청크 배치를 만들고 고정된 동적 프레임 속도로 업데이트했습니다. 이러한 프레임 속도는 OS에서 호출되었으므로 모든 기기는 시스템 용량에 따라 서로 다른 FPS를 가지므로 앱이 더욱 강력하고 호환되는 성능을 제공합니다.

제한된 청크 세트를 일괄적으로 캡처하고 프레임이 해제될 때까지 응답을 유지하고 모든 청크가 처리될 때까지 동일한 작업을 반복합니다.

따라서 DOM을 100번 업데이트하는 대신 DOM을 3~4번만 업데이트했습니다.

이제 숙제에 대한 성능 향상을 계산하고 계산해 보세요!

3. ? 좋은 청취자가 되십시오!

여자친구를 사귀는 것은 효과가 없었지만 확실히 앱을 훨씬 더 좋게 만드는 데는 효과가 있었습니다.

Api는 데이터를 얻는 멋지고 좋은 방법이지만 이를 현명하게 사용하는 것은 자신만의 기술입니다! 이제 이 앱은 이 API를 사용하여 백엔드에서 사용자 상태를 가져왔습니다. 하지만 가장 좋은 점은 3초마다 사용한다는 것입니다!!

알겠습니다. 개발자들은 불안감을 느꼈지만 일과 삶의 균형을 가져오겠다는 의미는 이것이 아닙니다.

a) 가져오는 중

사용자가 앱을 사용할 때마다 사용자 데이터를 얻으려면 앱 시작 시 또는 최근 앱이 호출될 때마다 호출하는 것입니다(앱 상태 리스너). 3초마다 호출하면 모바일 리소스가 무한 스트림으로 소모될 뿐만 아니라 서버 오버헤드도 발생합니다.

100명의 사용자로부터 100개의 요청을 받는 대신 Serve는 1명의 사용자로부터 100개의 요청을 받습니다. 확장성이 뛰어나고 안정적이지는 않은 것 같습니다.

또한 추적할 수 없는 메모리 누수 및 사용을 발생시켜 장기간 사용 시 문제를 일으킵니다.

b) 데이터 흐름

이제 내부 DDOS 공격을 해결한 후 이 앱이 데이터가 허공에 떠 있는 많은 API를 사용하고 있음을 발견했습니다(데이터 처리 불량). 데이터를 캐싱하고 동일한 흐름에서 다시 사용하는 대신 앱이 API를 다시 호출했습니다.

데이터가 캐시되어 흐름에 선형적으로 흐르도록 하고 API는 새로운 인스턴스에 필요할 때만 호출되도록 했습니다.

기억할 점 !

이로 인해 너무 많은 API 요청으로 인해 서버 상태가 향상되고 백엔드의 가동 중지 시간이 단축되었습니다. 회사가 백엔드를 실행하는 데 비용이 들기 때문에 API를 필요할 때만 효과적으로 사용하는 것이 중요합니다

백엔드뿐만 아니라 프런트엔드에서도 추가 API 호출을 수행하면 호출할 때마다 더 많은 HTTP 핸드셰이크 및 프로토콜을 수행해야 하므로 시스템 소비가 더 늘어납니다.

3. ? 우리가 그것을 인정하지 않는다면 그것은 오류가 아닙니다!

API를 처리할 때 중요한 것 중 하나는 오류입니다. 로그로 위로하는 것만으로는 사용자의 경험이 좋은 사용법보다 훨씬 나빠지기 때문에 충분하지 않습니다.

일종의 피드백 시스템을 사용하여 모든 작업에서 발생하는 오류를 처리하는 것이 중요합니다. 경고, 팝업, 토스트 등 무엇이든 될 수 있습니다. 하지만 사용자는 문제가 발생한 이유와 방법을 알아야 다시 신고하거나 적어도 자신이 무엇을 잘못했는지 알 수 있습니다!

4. ? 그녀의 추억

알았어 친구! 그녀는 돌아오지 않을 것이지만 기억누수로 인해 돌아올 것입니다. 리스너 또는 Api 호출을 연결하는 동안 우리가 잊어버린 주요 사항 중 하나는 해당 활동을 닫은 후 해당 인스턴스를 제거하는 것입니다.

이 앱에는 활동이 종료된 후에도 또는 백그라운드에서 API 호출이 호출되는 경향이 있었습니다. 불필요한 CPU 사용과 리소스 낭비로 인해 앱이 더 느려지고 사용하기 어려워집니다.

이를 적절하게 정리하면 앱이 더 빨라지고 오버헤드가 줄어듭니다.

5. 실적 선언

이제 자산을 사용하는 기본 방법은 자산을 가져와서 올바르게 사용하는 것입니다.

하지만 그것이 어떻게 작동하는지 아시나요? 항목을 기본적으로 가져올 때마다 초기화를 통해 메모리에 할당됩니다. 따라서 다음과 같이 5개의 파일에 이미지 또는 구성 요소를 가져오고 선언하면

import Profile from '../../profile'

동일한 항목에 대해 5개의 인스턴스를 생성합니다!

대신 하나의 인덱스 파일에 있는 모든 자산을 호출하고 그 파일에서 객체를 가져와야 합니다. 이렇게 하면 해당 자산은 한 번만 선언되고 참조에서 모든 곳에서 사용됩니다.

따라서 메모리 사용량을 4/5로 줄입니다.

✅ 결론 -

당신은 좋은 사람입니다. Arthor! (죄송합니다. 방금 RDR2를 완료했는데 정말 훌륭한 게임이었습니다.)

이러한 변경으로 인해 모바일 측 상태가 향상되었을 뿐만 아니라 서버 측 최적화도 향상되어 앱 성능이 엄청나게 향상되었습니다.

!!!사용 1주일 만에 스토어 평점이 3.5에서 4.1로 올랐습니다.

단순한 코드가 아니라 사용자가 코드와 상호작용하는 방식에 대한 스토리라는 점을 기억하세요.

프런트엔드 개발자로서 전체 제품은 우리에게 달려 있습니다. 백엔드의 확장성이 아무리 뛰어나더라도 사용자가 사용할 최종 제품은 생성이며 사용자가 결정을 내리는 유일한 제품입니다. 따라서 회사 전체의 더 나은 비즈니스로 이어지는 원활한 상호 작용을 제공하는 것이 가장 중요합니다.

? 블로그가 마음에 들면 댓글을 남기거나 친구들과 공유하여 친구들도 즐길 수 있도록 하세요!