Suyash Vashishtha⌛ Recap Time
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 !!
🕜 The Lore
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.
The Tahiti Plan ( But this time it works )
So I started with tackling the easier problems first as it is easy to ignore the great depression than fighting it on the moment.
1. ⚛️ Curse of React
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 !!
2. ❄️ The Frozen Desert
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 !
3. 😊 Be a good listener !
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.
a) Fetching
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.
b) Data Flow
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.
3. 😎 Its not a Error if we don't acknowledge it !
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 !
4. 💔 Her Memories
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.
5. Declaration of Performance
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.
✅ Conclusion -
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 !
