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.
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