В описании метода uptimeMillis говорится:
Возвращает миллисекунды с момента загрузки, не считая времени, проведенного в глубоком сне. Примечание. Это значение может время от времени сбрасываться (до того, как оно будет циклически повторяться).
Как часто это может происходить и (что более важно) повлияет ли это на исполняемые модули, которые должны выполняться Handler.postAtTime?
Вызов uptimeMillis завершается в systemTime(), который в системе Linux превращается в clock_gettime(CLOCK_MONOTONIC, struct timespec *).
Структура timespec содержит секунды в time_t, которое выглядит как 32-битное значение. Если он начнет считать около нуля, вы вряд ли будете живы, когда он завершится.
Если вам нужны более конкретные сведения, вам следует изучить поведение clock_gettime(CLOCK_MONOTONIC) в ядре Linux.
Если вам довелось вызвать uptimeMillis сразу после завершения, то да, это повлияет на ваш вызов postAtTime.
Длинный знак со знаком в Java имеет диапазон:
-9,223,372,036,854,775,807 to 9,223,372,036,854,775,807 (~9.2E18)
9,2E18 миллисекунд — это 292 277 266 лет. Если вы работаете над космическим зондом, вы, вероятно, захотите принять это во внимание, в противном случае вам, вероятно, может сойти с рук предположение, что он не завершится при вашей жизни.
Самое главное для меня то, что документация по Android для uptimeMillis претензии
Эти часы гарантированно монотонны. . .
Затем вскоре после этого они говорят, что uptimeMillis будет сброшен из-за переноса переменных - полная противоположность монотонным часам!
Я использовал его для обслуживания и никогда не видел, чтобы он сбрасывался. Я бы действительно предположил, что не будет. Проблема с postAtTime() в том, что он не будет вызываться во время сна (поскольку uptimeMillis() не будет обновляться). Если это проблема, то я бы использовал другой метод.
