Always on, always small
A privacy tool is only valuable while it is running. On a phone, it has to run all day without draining the battery, without using much memory and without being shut down by the operating system. If it fails any of those tests, people switch it off, and protection stops.
That makes efficiency a security requirement, not just a performance goal.
The constraints
- Battery. Every wake-up and every check costs energy.
- Memory and storage. Low-cost phones have far less of both than flagship models.
- Background limits. Modern systems restrict what apps may do when not in use, and many manufacturers add their own aggressive limits on top.
- Changing networks. Connections move between Wi-Fi and mobile data throughout the day.
Doing less, on purpose
- Keep the fast path fast. Most decisions should be answered from a cached result in a fraction of a millisecond, with slower checks reserved for what is genuinely new.
- Use compact data structures. Lists of known bad domains can be stored in memory-efficient forms such as tries and probabilistic filters, instead of plain lists.
- Update incrementally. Downloading only what changed saves data and battery compared to refreshing whole lists.
- Avoid polling. Reacting to events is cheaper than asking over and over whether anything happened.
Staying alive
Protection also has to survive the operating system. That means using the mechanisms the platform provides for long-running work, handling power-saving states gracefully, restarting cleanly if the process is stopped and being visible to the person, so that a silent gap in protection never goes unnoticed.
Test where it hurts
A feature that feels instant on a new flagship phone can be painful on a four-year-old budget one. We measure on modest hardware, because that is where limits show up first and where many people actually are.
KEY TAKEAWAYS
- On phones, efficiency is part of security because people switch off tools that hurt battery.
- Design for low memory, limited background time and changing networks.
- Cache decisions, use compact data structures, update incrementally and avoid polling.
- Test on modest hardware, and never fail silently.