Can the Mirai botnet teach us how to make Android apps faster?

Recently, I've been spending a lot of time thinking about Android app performance, specifically regarding network requests. Developers working on mobile apps are allowed a lot more customization for low-level details (for example, we get to customize our own network stack!) but in exchange, we must plan for our applications to work in some crazy environments. Our users might be on WiFi, 5G, 4G, or even GPRS. They could be sitting in a coffee shop or riding on a high speed rail with their cell service hopping to a new cell tower every 10 minutes. They could even be using satellite if they're sailing on a boat or flying through the air. On top of all this, we need to be able to support everyone using a $100 to $1000 smart phone.

Interestingly enough, the conditions that mobile developers have to run their mobile apps in is actually reminiscent of the conditions that botnet developers have to run their malware in! The Mirai botnet malware ran with a tiny memory footprint, a tiny energy footprint, and was able to manage a very large number of connections all from a single thread. If I remember correctly, the Mirai botnet even took into account when the device was low on resources so that it could slow down and not overwhelm the device. If the Mirai malware were an Android application it would probably be the most efficient app out there on the marketplace.

I wonder if it is possible to draw ideas from the Mirai botnet code to help make our Android HTTP libraries like Volley or our network stacks such as Cronet more efficient. Working with Volley in my day-to-day job I realized there actually is a lot to be desired from our current libraries for networking on Android. For one, Volley NetworkDispatchers are blocking, so they can only handle one request at a time. This is currently being addressed by this experimental addition to Volley called Asynchronous Volley. But even with Asynchronous Volley, there's still issues like the requirement of Volley to deliver responses to the main thread. For applications running on low-end devices that require animations, this could increase the amount of latency your users perceive a network request to have by many hundreds of milliseconds, which slows down an already janky experience even further.

Comments

Popular posts from this blog

First-Principles Derivation of A Bank

A Play-by-play of the Mirai botnet source code - Part 1 (scanner.c)

You can control individual packets using WinDivert!