Я пишу спортивное приложение, которое должно отслеживать прошедшее время квартала/половины/периода. Истекшее время должно быть точным для второго. Часы игры должны продолжать работать, даже если пользователь явно помещает устройство в спящий режим, нажав кнопку питания.
Моя первая попытка в этом заключалась в использовании Handler.postDelayed(), чтобы вызвать тактирование часов каждые 200 мс и WindowManager.LayoutParms.FLAG_KEEP_SCREEN_ON, чтобы гарантировать, что "часы" были t остановлен таймаутом экрана. Но вскоре я узнал, что можно обойти этот подход, нажав кнопку питания, чтобы вручную перевести устройство в режим сна. Кроме того, метод postDelayed() испытывает некоторый дрейф синхронизации, по-видимому, результат времени, затраченного на метод run(). Фактические цифры по-прежнему точны, но вместо выравнивания, например, на 5-секундных границах, которые легко понятны пользователям - задействованные таймеры начинают дрейфовать, что приводит к некоторой понятной путанице пользователя.
После небольшого исследования я нашел технику использования сервисов, java timers, AlarmManager и PartialWakeLock для реализации таймеров. Сервисы сами по себе не будут решать проблему, связанную с устройством, которое будет спать. Таймеры Java, такие как службы, не решают проблему с устройством, которое будет спать. AlarmManager кажется хорошим подходом, но я обеспокоен тем, что это неправильное использование AlarmManager (т.е. Очень короткие интервалы между сигналами тревоги). Использование PartialWakeLock также выглядит многообещающим, но само по себе оно не касается проблемы с дрифтом часов, с которой я столкнулся.
Я собираюсь попробовать сочетание AlarmManager и PartialWakeLock. Идея состоит в том, что AlarmManager поможет бороться с дрейфом часов и PartialWakeLock, чтобы помочь сохранить код простым (скрещенными пальцами). Я надеюсь, что такой подход приведет к разумному балансу между энергосбережением, сложностью кода и ожиданиями пользователей. Любые советы приветствуются.
Спасибо,
Рич