Summary of "Анатомия энергопотребления / Никита Васильченко"

Main ideas / lessons

User experience isn’t only speed (startup/rendering); it also depends on battery discharge rate.
Energy problems come from two broad causes:
- Inefficient code that creates extra load on device components.
- Well-written but highly distributed, modular apps whose architecture can generate a persistent (often unnecessary) load.
Battery discharge rate and “processor time” (CPU work) can diverge, so debugging needs an understanding of how power is measured and which components dominate.
Measuring energy is about choosing the right granularity and accuracy; battery-level metrics can hide causes or be imprecise.
In modern apps, the mobile modem (network) is often the main energy consumer, especially when the app sends data frequently.
Display energy is influenced by content and rendering behavior (brightness/colors, animation/frame rate), but it may not be the primary factor compared with modem usage.
Networking inefficiency is strongly affected by LTE “tail energy”—how long the modem stays in a high-power state after transmissions.
Developers can reduce modem energy by:
- Using efficient protocols (e.g., avoiding repeated handshakes).
- Reducing header/connection overhead.
- Grouping requests so the modem wakes up fewer times.
Optimization strategy should start early (design-time) using theoretical insights, then validate later with measurements in production.

Methodology / instruction-like guidance

1) How to measure energy consumption (available methods)

Software methods (via OS APIs)

Energy/Battery and component stats counters
- Use the Health Stats API to track component usage patterns (e.g., how often GPS ran, how long Wi‑Fi/screen/CPU activity occurred).
- Use BatteryManager to read battery percentage/charge and instantaneous current.
- Be aware of accuracy variability: BatteryManager accuracy depends heavily on the device chip.
- If debugging with instantaneous current, check how often the reported current changes (it may update too infrequently).

Hardware methods

On-device power rails monitor (Pixel 6+)
- Uses a special chip measuring component power directly.
- Available via Power profile in Android Studio.
- Sampling frequency ~200 ms for component power readings.
External power supply / dedicated monitors
- Most accurate but impractical for routine app debugging (it’s described as “measuring directly” at a near-hardware level).
- Important for interpreting academic research: many studies were performed using high-precision setups, not battery-percentage readings.

2) Debugging approach when CPU time and battery discharge disagree

Start from the idea that battery discharge rate is imprecise and can worsen due to background system/network activity, not only the app.
Still validate systematically by:
- Measuring with available tools (software counters → hardware monitor where possible).
- Checking the component breakdown (display vs CPU vs modem).
- Accounting for systematic measurement errors (notably display behavior affecting battery-drain comparisons).

3) Display-related optimizations and what to do

Reduce frame rate / manage it correctly
- Lowering FPS is described as the most effective display energy optimization for energy-saving modes.
- Communicate frame drawing frequency to the OS (e.g., frame scheduling APIs as mentioned via setFrame... style mechanisms).
Use dark theme carefully
- Darker visuals can reduce display power substantially (example framing: ~400–600 mW dark vs ~~1000 mW light).
- Dark themes are also described as a source of systematic measurement error in battery-drain comparisons—so treat results cautiously.
Be careful with animations (avoid invisible “energy leaks”)
- Even triggering certain updates (referred to as “JL buffer update” in the transcript) can cause large energy drains.
- Ensure checks begin with animation/frame-related behavior.

4) Modem/network optimization and protocols (the key instruction set)

Recognize LTE tail energy as the major inefficiency
- The modem may remain in a higher-power “connected”/active-like state after data transfer stops.
- Tail can last seconds (example discussed: about ~10 seconds), and is not easily reducible.
Sending vs receiving costs
- Sending data costs much more energy than receiving (transcript framing: roughly ~8× more costly).
Protocol choices
- Prefer designs that avoid repeated setup/handshakes:
  - Contrast HTTP/HTTP1.1-style repeated handshakes per request vs WebSockets/HTTP/2 persistent connections.
- (Transcript framing: “websocket maintains a connection constantly.”)
Reduce header/connection overhead
- Keep protocol overhead minimal; precompute and reuse where possible.
Compress data
- Compress payloads to trade processor time for modem/network time (modem energy dominates).
Group requests to reduce modem wakeups
- If polling is required, align polling intervals so multiple requests occur together (instead of asynchronously spreading them out).
- Example guidance: grouping multiple polls into a single burst can yield large savings (transcript mentions up to ~2×).
- When requests are too frequent (example interval ~0.3 seconds), energy cost per request becomes high; making them less frequent (e.g., every 10 seconds) can change cost dynamics substantially (transcript cites large multiplicative differences in “per-request” energy).
Plan for OS batching (Android Doze-like behavior)
- Android Doze is described as having:
  - A lighter state when screen is off with periodic batching windows (~30 seconds).
  - Deeper mode where requests are restricted longer (~15 minutes).
- Implication: request grouping/batching fits OS energy-saving mechanisms.

Key concepts explained (with the “why”)

CPU time is not the whole story:
- Energy is distributed among display, CPU, and network modem; the modem can dominate.
Display energy depends on content and rendering:
- Dark vs bright content changes display power substantially.
- Frame rate changes reduce GPU/CPU load and can allow the display to reduce refresh behavior.
LTE mechanics drive modem inefficiency:
- The modem alternates between idle (low energy) and connected (higher energy).
- After sending data, it enters a “tail” period where power remains elevated.
Why modem energy is high in client-server apps:
- Apps frequently send data (not just receive).
- More transmission (including with AI-era features) increases energy cost.

Sources / speakers featured (at the end)

Speaker / source

Nikita Vasilychenko
- “I lead the speed team at Yandex Pro.” (speaker in the video)

Named organizations / studies / systems (mentioned as sources in content)

Yandex Pro
Android OS
Android Studio Profiler
Pixel 6+ “on-device power rails monitor”
LTE / Radio Resource Control
Health Stats API (Android API)
BatteryManager (Android API)
Power supply / external power monitor (“most accurate method”)
MobiCom 2024 conference paper/article (“Who, where, and how much consumes energy?” mentioned)
2012 study by an American telecom operator / “ANTNT Labs Research” about LTE tail/transition behavior (name appears as transcribed; exact spelling may be unreliable)
Sweden / iPhone mention (context for protocol grouping; reference “from Sweden” adopting iPhone behavior in 2022—exact study not clearly specified in the transcript)
Google Meet (example scenario)
Cloud/Video/app examples used in tests: YouTube, Clash of Clans, Google Meet