Коротко: энергопотребление на мобильных устройствах почти прямо связано с количеством выполняемых CPU‑циклов, частыми переключениями состояния (wakeups), объёмом памяти/IO и работой ускорителей (GPU, модем). Правильный выбор алгоритмов и структур данных может заметно продлить время работы батареи. Ниже — сжатые практические правила и примеры.
Энергетическая модель (очень упрощённо)
- Энергия: $E=P\cdot t$ (энергия = мощность × время).
- Динамическое потребление CPU: $P_{\text{dyn}}\propto C{V}^{2}f$ (где $C$ — ёмкость, $V$ — напряжение, $f$ — частота). Снижение числа циклов и частоты уменьшает энергию.
Общие принципы оптимизации
- Снижение числа операций: предпочтительнее алгоритмы с меньшей временной сложностью ($\mathcal{O}(n\log n)$ лучше $\mathcal{O}(n^2)$ при больших $n$).
- Уменьшение IO и сетевых вызовов: сеть и флеш требуют много энергии; батчинг, компрессия и кеширование помогают.
- Минимизация переключений и wakeups: агрегируйте задачи, используйте планировщики (JobScheduler/WorkManager на Android).
- Локальность памяти: линейные/контiguous структуры (массивы) энергичнее из‑за кэш‑локальности, чем pointer‑chasing (linked lists).
- Снижение аллокаций и давления GC: реюз объектов, пулы, избегать частых небольших выделений.
- Использование аппаратного ускорения только там, где оно выгодно (аппаратные кодеки, NPU для ML) — но учитывайте, что GPU/NPU тоже потребляют энергию.
Выбор структур данных (рекомендации)
- Массивы/вектора (Array, ArrayList) — хороши из‑за последовательного доступа и кеш‑локальности.
- Хеш‑таблицы vs деревья: хешы обычно быстрее по времени, но могут иметь большие затраты памяти; для частых запросов membership хеш быстрее и экономнее по энергопотреблению.
- Bitset/Bitmap — отличны для плотных множеств; занимают мало памяти и быстры побитовые операции.
- Bloom‑фильтры — экономят сет/диск/память для проверок принадлежности с допустимой ложноположительностью.
- Сжатые/сукцинктные структуры (например, Elias‑Fano, succinct tries) — пригодны, если важно сократить IO/память.
- Избегать linked list и других структур с частыми случайными переходами для больших объёмов данных — много кэш‑промахов.
Конкретные оптимизации в коде
- Батчинг и дебаунсинг: объединяйте мелкие операции (сетевые запросы, записи в базу).
- Lazy‑evaluation, кеширование результатов и memoization для дорогих вычислений.
- Approximate/streaming алгоритмы: заменяйте точные тяжёлые алгоритмы приближенными (sketches, sampling) если допустима погрешность.
- Вычисления на более низкой точности: float вместо double, fixed‑point где возможно.
- Избегайте busy‑waiting и частого опроса; используйте событийную модель и таймеры с большими интервалами.
- Минимизируйте количество потоков: контекстные переключения тоже «дороги».
- Перемещение тяжёлой работы в периоды зарядки или в фоне (JobScheduler) — особенно для фоновых sync/аналитики.
Какие алгоритмы и практики стоит избегать
- Алгоритмы с экспоненциальным или квадратичным ростом времени при больших входных данных: $\mathcal{O}(n^2)$, $\mathcal{O}(2^n)$, $\mathcal{O}(n!)$ — ведущие к длительной загрузке CPU.
- Частые полные пересчёты/пересортировки вместо инкрементальных обновлений.
- Постоянные мелкие сетевые запросы вместо батчинга; частые записи на диск/флеш.
- Pointer‑chasing структуры при больших объёмах данных (много кеш‑промахов).
- Частые и большие аллокации/деаллокации в горячем пути — нагрузка на GC.
- Использование CPU для задач, где есть аппаратные ускорители, без необходимости (например, софт‑кодирование видео при наличии hardware encoder).
- Busy loops, polling с низким интервалом.
Баланс CPU vs IO vs память
- Иногда стоит «потратить» CPU (быстрые алгоритмы) чтобы сократить сетевой трафик/IO и тем самым сохранить энергию (например, компрессия перед отправкой).
- В других ситуациях лучше минимизировать CPU и читать меньше данных с диска/сети (кеширование, предзагрузка). Решение зависит от относительных затрат: меряйте.
Инструменты и метрики
- Измеряйте: profiler CPU, Energy Profiler (Android Studio), batterystats/adb, sysfs значения частот, power profiling hardware (если доступно).
- Оценивайте изменения по уменьшению времени работы на CPU, числу wakeups, количеству IO/трафика, частоте сборок мусора.
Короткая сводка рекомендаций
- Предпочитайте алгоритмы с меньшей временной сложностью: $\mathcal{O}(n\log n)$ вместо $\mathcal{O}(n^2)$ при больших $n$.
- Используйте contiguous структуры (массивы, буферы) для кеш‑локальности.
- Минимизируйте wakeups, сетевые вызовы и аллокации.
- Применяйте approximate и streaming алгоритмы, аппаратное ускорение и нижнюю точность, где это возможно.
- Избегайте brute‑force, частых пересчётов, pointer‑chasing и busy‑waiting.
Если нужно, могу привести конкретные примеры замены структур/алгоритмов в коде (например, LinkedList → ArrayList, naive string search → Boyer‑Moore/KMP, сортировка каждый кадр → инкрементальный update).