지난 블로그에서 단 2주 만에 앱 크기를 75MB에서 34MB로 줄인 방법에 대해 이야기했습니다(보기! ). 하지만 그게 다가 아닙니다. 저희 앱의 전반적인 성능도 최대 80%까지 향상되었습니다.
그 방법을 알아봅시다!!
간단한 조사 끝에 저는 우리 앱에서 일방적으로 사용자 경험과 성능을 저하시키는 주요 문제 몇 가지를 발견했습니다. 정말 좋은 하루였습니다!
메인 빌런 - 실시간 응답 생성 중 전체 앱 UI 정지
Side Villain - 응답 속도가 느리고 프레임 속도가 없음
악당의 연인 - API 호출이 너무 많습니다
The Undead Army - 잘못된 오류 처리 및 충돌
고통 - CPU 사용량 증가 및 서버 비용 증가
The Tarnished - ME !
더 나은 세상을 희망하며 우주를 재창조하는 생명 없는 싸움이 시작된다.
그래서 대공황은 당장 맞서 싸우기보다 무시하기 쉽기 때문에 쉬운 문제부터 먼저 해결하기 시작했습니다.
ReactJ의 지혜와 저주는 상태입니다. React에서 나이가 들수록 상태가 적을수록 애플리케이션이 더 좋아진다는 것을 깨닫게 됩니다. 따라서 이 특별한 예술 작품은 단일 채팅 화면에서 메시지를 보내고 받는 것뿐인 22개(예 빌어먹을 useStates 22개)를 사용하고 있었습니다.
위에 체리!
우리는 서버에서 청크 단위 데이터를 가져오기 위해 서버 측 이벤트 구현을 사용하고 있었는데, 이 경우에는 단어 단위였습니다. 따라서 응답이 100단어인 쿼리가 있는 경우(이것은 응답이 가장 적습니다). 실제로 100개의 이벤트를 받게 됩니다.
그래서 수학을 안다면 응답을 받을 때마다 100*22 = 2200번 다시 렌더링합니다.
더 이상 설명해야 하나요? (아니요)
그래서 전체 화면을 다시 만들기 시작하고 이제 숫자를 6개 상태로 줄였습니다. 이전보다 더 좋고 부드러운 기능을 제공합니다.
이전 제품보다 72% 더 성능이 향상되었습니다!!
이제 React의 Radahn을 보고 나면 앱이 꽤 많이 멈출 것이라는 결론을 쉽게 내릴 수 있겠죠?
이제 6개 주에서도 주요 문제는 100*6으로 동일하게 유지됩니다. 우리는 여전히 매달리고 있지만 상태는 더 적습니다.
주된 원인은 React DOM이 각 청크에서 업데이트된다는 것입니다. 그래서 이 문제를 해결하기 위해 "일괄 처리 및 프레임 속도 생성을 사용했습니다.
맙소사!
기본적으로 청크를 얻을 때마다 DOM을 업데이트하는 대신 청크 배치를 만들고 고정된 동적 프레임 속도로 업데이트했습니다. 이러한 프레임 속도는 OS에서 호출되었으므로 모든 기기는 시스템 용량에 따라 서로 다른 FPS를 갖게 되어 앱이 더욱 강력하고 호환되는 성능을 갖게 됩니다.
제한된 청크 세트를 일괄적으로 캡처하고 프레임이 해제될 때까지 응답을 유지하고 모든 청크가 처리될 때까지 동일한 작업을 반복합니다.
따라서 DOM을 100번 업데이트하는 대신 DOM을 3~4번만 업데이트했습니다.
이제 숙제에 대한 성능 향상을 계산하고 계산해 보세요!
여자친구를 사귀는 것은 효과가 없었지만 확실히 앱을 훨씬 더 좋게 만드는 데는 효과가 있었습니다.
Api는 데이터를 얻는 멋지고 좋은 방법이지만 이를 현명하게 사용하는 것은 여러분 자신의 기술입니다! 이제 이 앱은 이 API를 사용하여 백엔드에서 사용자 상태를 가져왔습니다. 하지만 가장 좋은 점은 3초마다 사용한다는 점!!
알겠습니다. 개발자들이 불안감을 느꼈지만 일과 삶의 균형을 추구한다는 것은 그런 의미가 아닙니다.
사용자가 앱을 사용할 때마다 사용자 데이터를 가져오려면 앱 시작 시 또는 최근 앱이 호출될 때마다 호출하는 것입니다(앱 상태 리스너). 3초마다 호출하면 모바일 리소스가 무한 스트림으로 소모될 뿐만 아니라 서버 오버헤드도 발생합니다.
serve는 100명의 사용자로부터 100개의 요청을 받는 대신 1명의 사용자로부터 100개의 요청을 받습니다. 확장성이 뛰어나고 안정적이지는 않은 것 같습니다.
또한 추적할 수 없는 메모리 누수 및 사용을 발생시켜 장기간 사용 시 문제를 일으킵니다.
이제 사내 DDOS 공격을 해결한 후 이 앱이 데이터가 허공에 떠 있는 많은 API를 사용하고 있음을 발견했습니다(데이터 처리 불량). 데이터를 캐싱하고 동일한 흐름에서 다시 사용하는 대신 앱이 API를 다시 호출했습니다.
데이터가 캐시되어 흐름에 선형적으로 흐르도록 하고 새로운 인스턴스에 필요할 때만 API가 호출되도록 했습니다.
一定要記住！
這使得伺服器運作狀況更好，並減少了 api 請求過多而導致的後端停機時間。由於公司運行後端需要成本，因此僅在需要時才有效使用 API 至關重要
不僅對於後端，對於前端也是如此，進行額外的 api 呼叫會增加系統消耗，因為每次呼叫時都必須執行更多的 HTTP 握手和協定。
處理 api 的關鍵之一是錯誤。將它們安慰到日誌是不夠的，因為它使用戶的體驗比他們的良好使用情況差得多。
使用某種回饋系統處理任何操作中的錯誤非常重要。它可以是警報、彈出視窗、Toast 或任何東西。但用戶應該知道為什麼以及如何發生，以便他們可以報告或至少知道他們做錯了什麼！
哥們兒！她不會回來，但記憶洩漏會回來。在附加任何偵聽器或 Api 呼叫時我們忘記的主要事情之一是在關閉活動後刪除其實例。
這個應用程式有它的基調，即使活動關閉或在後台，API 呼叫也會被呼叫。導致不必要的 CPU 使用和資源佔用，使應用程式更加滯後且難以使用。
正確清理這些可以讓應用程式更快、更少的開銷。
現在使用任何資源的基本方法是導入它並正確使用它？
但是你知道它是如何運作的嗎？每次預設導入一個專案時，它都會透過初始化分配到記憶體中。因此，如果您在像這樣的 5 個檔案中匯入並聲明圖像或元件
import Profile from '../../profile'
它將為同一件事創建它的 5 個實例！
相反，您應該調用一個索引文件中的所有資源並從中導入對象，這樣它只會被聲明一次，並且將被到處引用使用。
因此將記憶體使用量減少到 4/5。
你是個好人阿瑟！ （抱歉，我剛完成了 RDR2，這是一款非常棒的遊戲）。
透過這些更改，應用程式效能得到了極大的提升，不僅有更好的行動端運行狀況，還有更好的伺服器端優化。
使用短短 1 週，商店評分從 3.5 上升到 4.1 !!!
記住，它不僅僅是一個程式碼，而是一個關於使用者如何與其互動的故事。
身為前端開發人員，整個產品取決於我們。無論後端的可擴展性如何，用戶將要使用的最終產品都是創建出來的，這是他們做出決定的唯一事情。因此，對我們來說最重要的是為他們提供順暢的互動，從而為整個公司帶來更好的業務。
？如果您喜歡該博客，請發表評論，或與您的朋友分享，讓他們也喜歡它！
以上是我如何將應用程式效能提高到的詳細內容。更多資訊請關注PHP中文網其他相關文章！
