In my last blog I talked about how I Reduced my app size from 75MB to 34MB in just 2 weeks ( View ! ). But that's not all , I also improved overall performance of our app upto 80% ?.
Let's discover HOW !!
After a simple round of walk through I discovered few of the top tier issues in our app leading to bad user experience and performance single headedly. What a day !
Main Villain - Whole App UI Frozen while generating Realtime response
Side Villain - Slow response time and No frame rates
Villain's lover - Too many Api calls
The Undead Army - Poor Error handling and crashes
Sufferings - More CPU usages and Server Costs
The Tarnished - ME !
Hence a lifeless battle of recreation of universe with a better world hope begins.
So I started with tackling the easier problems first as it is easy to ignore the great depression than fighting it on the moment.
The Wisdom and Curse of ReactJs is states. As we grow older in React we realize that lesser the states more better the application. Hence this particular piece of art was using 22 ( Yes goddamn 22 useStates) in a single chat screen where all you can do is send message and receive message.
Cherry on the top !
We were using Server Side event implementation for getting chunk-by-chunk data from server , which in case was word-by-word. So if you had a query which has a response of 100 words ( THIS IS LEAST OF RESPONSE ). It will actually receive 100 events.
So if you know the maths, 100*22 = 2200 re-renders each time we get a response.
Do I have to explain any further ? ( NO )
So I begin recreating the whole screen and took down the number to 6 states now. With better and smooth functionality as before.
That is 72% more performant that previous !!
Now after witnessing the Radahn of React, we can easily conclude that app is going to be freezing quite a lot right ?
Now even with 6 states, the main issue remains same it is 100*6. We are still hanging but with less states.
The main cause was, react dom getting updated on each chunk. So to tackle this we used "Batch Processing & Frame Rates Generation.
Hell Yeahh !
So basically instead updating the DOM each time we get a chunk, we were making batches of chunk and updating it in a fixed dynamic frame rate. These frame rates were called from OS so every device will have a different FPS as per system capacity giving the app more robust and compatible performance.
We captured a limited set of chunks in a batch and hold the response till the frame is released and repeated the same till all chunks are processed.
Hence instead of updating DOM 100 times we only updated DOM 3-4 times.
Now do the maths and calculate the performance enhancement for Homework !
It didn't work for me to get a girlfriend, but certainly worked to make the app much better.
Apis are cool and nice way to get data but using them wisely is a skill of your own ! Now this app was using this api to get the user status from backend. But the best part is it was using it every 3 seconds !!
I get it, developer had insecurities but this is not what they meant by bringing Work-life balance.
In order to get the user data every time user uses the app, is to make the call at app start or every time app gets called from recent ( App state listener ). Calling it every 3 seconds not only uses Mobile resources into a infinite stream but also cause Server overhead .
Instead of getting 100 requests from 100 users, serve will get 100 request from 1 user. Doesn't sound very scalable and reliable to me.
As well as it creates untraceable memory leaks and usages which creates problem in longer usages.
Now after resolving that inhouse DDOS attack, I discovered that this app was using many apis whose data was getting ghosted in thin air ( Poor data handling ). Instead of caching data and using it again in same flow, the app was calling apis again.
I made sure data gets cached and flowed linearly to the flow and api is called only when needed for fresh instance.
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 !
Disclaimer: All resources provided are partly from the Internet. If there is any infringement of your copyright or other rights and interests, please explain the detailed reasons and provide proof of copyright or rights and interests and then send it to the email: [email protected] We will handle it for you as soon as possible.
Copyright© 2022 湘ICP备2022001581号-3