I have an on-site with FANG in a few days. I am compiling mobile architecture optimization topics worth discussing in interviews. Following is a generic list I have so far. View hierarchy and models would be a separate discussion. Please contribute more ideas Identify the Bottlenecks, tradeoffs and scale the design Network Footprint, Memory Footprint, Storage Footprint, Battery Footprint 1. Improvement - Use gzip encoding for response data. Trade-off - Device CPU cycles and Battery performance 2. Improvement - Use field parameters in the Rest APIs. Request only limited info from the server, rather than querying for large data. (Refer Graph API/ Google Drive API). Trade-off - Added complexities to merge the received data on to device persistent-store. 3. Improvement - Use batch APIs to combine multiple Rest API with the same host into one. Reduces the number of TCP connections and thus improves battery/network performance. Trade-off - Added complexity to manage the requests 4. Improvement - Use PATCH REST method type to update contents from the client to the server. Reduces the network bandwidth usage. Trade-off - Client complexity 5. Improvement - Use UDP priming to request the server to prepare the server to get the data ready for the current user. Trade-off - UDP does fit well for only when response arriving early is more important than lossy data 6. Improvement - Use Zero RTT protocol like QUIC to reduce the initial network setup time. Trade-off - QUIC is based off UDP, will only help if the application fits into the above mentioned use case 7. Improvement - Media downloads can be regulated while using cellular. Less frequent downloads or low resolution downloads while in a congested network. Trade-off - Estimating the network performance in real time is a complex problem and may involve sending multiple test network requests to measure the RTT- Adds complexity 8. Improvement - Image downloads can use techniques like Progressive JPEGs with low and high resolution scans. Trade-off - Complex client logic to implement progressive JPEGs with multiple scans 9. Improvement - Use lightweight pub-sub protocol like MQTT instead of TCP for applications like messenger. Helps to reduce the battery and network consumption. Server would send delta updates to the client when necessary. 10. Improvement - Use a persisted cache to serve contents. Cache Criteria - Based on a score (unread+content-type) Purge-Criteria - Based on a score(read+expiry). Trade-off - Mechanism to make sure we are not abusing the storage footprint of the device. 11. Improvement - In-memory cache to reduce the number of disk reads and improve battery performance. Trade-off - Can lead to Out of Memory (OOM) cases. Foreground OOM (FOOM) and Background OOM(BOOM). Handle logic to maintain a maximum threshold size - 10% of the available RAM 12. Improvement - Reduce the CPU intensive image/video processing while battery lower than a threshold of 15% Trade-off - Bad user experience. 13. Improvement - Limit background data fetch while battery below a certain threshold. Trade-off - Bad user experience 14. Provide Pagination - Use page anchors like Facebook Graph API 15. App Size Footprint – reduce the size of the generated ipa by analyzing unwanted class, refactoring etc.
Great post. Android Architecture Components might be something you want to look into. Kotlin Coroutines, aka lightweight threads is in trend. Webp and vector image formats are great to reduce size.
Thanks. I will add webp and vector images. I have read a FB eng blog how they implemented the Instagram stories reaction animation using SVG, very interesting. I predominantly work on iOS.
Don’t suggest svg on iOS. iOS uses PDF natively.
Will be great to know how your interview goes
I don’t have high hopes about the interview, but researching about these topics have been a good learning experience.
1. Authentication ( Oauth vs Saml,Scopes, Access) 2. Improvement - API Gateway (Reverse Proxy, routing requests,load balancing,request aggregations). For scaling, you might need multiple gateways. Bottleneck: single point of failure, tight coupling with microservices 3. Improvement - Logging/Tracing using elastic search 4. Improvement - Versioning - helps in sending iterations quickly..so only change versions when format/type of response chnages. Bottleneck : large URI footprint, http caching problems 5. Improvement - Offline Capabilities - which persistent db to use ( sqlLite vs couchbase) . Creating a local queue and storing requests with unique ids and once app is online, have a sync job running to update/rollback. Redux state management can be used here Bottleneck: maintaining single source of truth
I have worked with hybrid apps..native platform specific architectures might add more technical content
2,3,5 would be a server side improvement ?
Forgot to mention, look into architecture of Volley library (network on Android), video called Persistent Queues with Tape (queue on Android).
Thanks
Your gzip answer is a noob answer. The radios will use more energy sending uncompressed data than gzipping the data before transmission.
That’s true it’s debatable. I got it from https://developers.google.com/drive/api/v3/performance
Detailed one. Bookmarked. I am starting to prep so can’t join you system design since I won’t be bringing in much knowledge with me right now. Based on my last year’s interviews, make sure to read deep linking, retrofit, various design patterns, coroutines and lazy loading.
coroutine is an Android concept?
Fantastic compilation!. Bookmarked. I have a TPS coming up with FB and this will be very helpful if I make it to onsite. Pls post your onsite experience after you are done. Good luck!
Do you have any other mobile perf topics that would be interesting in this context?
Off the top of my mind - Improving scrolling performance and maintaining 60 FPS - how to reduce blending, offscreen rendering, keeping balance between CPU and GPU, using Core Graphics wherever applicable, etc.
Thanks folks for contributing. I have received a verbal offer from the company I interviewed for. The discussions derived from these notes were really useful!
Congrats!. E4 or E5?. What are the numbers?
Verbal offer E5. Numbers to be discussed soon.
How did you come up with this list?
Pretty detailed and thoughtful..Bookmarked :)
Would you like to add anything?
Thinking..will get back to you if I find something