지난 블로그에서 단 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가 호출되도록 했습니다.
Point to remember !
This resulted in better server health and less downtime for our backend due to too much api requests. As it costs company to run backend it is crucial to use apis effectively and only when needed
Not only for backend but for frontend as well, making extra api calls make it more system consuming as it has to do more HTTP handshakes and protocols every time you make a call.
One of the crucial thing for handling apis is, ERRORS. Consoling them to the logs isnt enough as it makes user's exp far worse than their good usages.
It is important to handle errors from any action using some kind of feedback system . It can be an Alert or Popup or Toast or anything. But user should know why and how it happened so that they can report it back or atleast get to know what they did wrong !
Gottacha homie ! She aint coming back but the memory leaks will. One of the main thing we forget while attaching any listener or Api call is to remove its instance after we close that activity.
This app had tone of it, api calls were getting called even after activity is closed or in background. Causing unnecessary CPU usage and resource hogging making app more laggy and hard to use.
Proper cleaning of these makes app more faster and less over heading.
Now a basic way to use any asset is to import it and use it right ?
But do you know how it works ? Every time you default import an item it gets allocated into memory with an initialization. So if you import and declare a Image or component in 5 files like this
import Profile from '../../profile'
It will create 5 instances of it for the same thing !
Instead you should call all assets in one index file and import the object from it, that way it will only be declared once and will be used by Reference everywhere.
Hence reducing the memory usage to 4/5.
Your a good man Arthor ! ( Sorry I just completed RDR2 and it was a great great game ) .
With these changes the app performance boosted like hell with not just better mobile side health but as well as better Server side optimization.
The Store Rating went from 3.5 to 4.1 in just 1 week of using !!!
Remember it is not just a code but a story on how users interacts with it.
As a Frontend developer, the whole product depends upon us. No matter how scalable the backend is, the end product which user is going to use is out creation and it is the only thing they make decision on. So it is most important for us to give them a smooth interaction which leads to better business for the entire company.
? Drop comments if you like the blog, or share it with your homies to let them enjoy it as well !
The above is the detailed content of How I boosted my App Performance up to. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
