2 votes

Que se passe-t-il avec les minuteries en cours d'exécution lorsque l'heure du système est modifiée ?

Que se passe-t-il avec les minuteries en cours lorsque l'heure du système est modifiée ?

J'ai une application Android et j'utilise handler.postDelayed(Runnable,interval) pour envoyer un Runnable qui sera appelé (la méthode run()) à la fin de l'intervalle.

La question que je me pose est la suivante : Que se passe-t-il si l'heure du système sous-jacent est modifiée de manière externe ? J'ai l'impression que l'affichage se produit toujours, mais qu'au moment du changement d'heure du système, le compte à rebours recommence... Quelqu'un peut-il m'éclairer ?

Le comportement change-t-il si le changement de temps est en avant ou en arrière ?

1voto

Dibzmania Points 1351

Non, cela n'a pas d'importance. Si vous creusez dans le code, le délai est assuré par le mécanisme suivant -

SystemClock.uptimeMillis() + delayMillis

Il est donc purement relatif. Et le changement du temps du système n'a aucun effet sur elle.

1voto

Baoyang Points 36

D'abord, vous devez savoir Handler est basé sur SystemClock.uptimeMillis() . Handler Les méthodes sendMessageXXX() de l'entreprise telles que sendMessageDelayedsendEmptyMessage tous utilisent la méthode interne ci-dessous :

//calcute the milliseconds we hope to handle the message since the system was booted
sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis)

Ensuite, la valeur de l'intervalle de temps SystemClock.uptimeMillis() + delayMillis sera conservé dans Message Le champ d'action when ,et nous mettons le message dans le MessageQueue en attendant Looper pour le sonder.

Pendant que le boucleur reçoit le message suivant de la file d'attente, il va comparer SystemClock.uptimeMillis() con msg.when Si le message suivant n'est pas prêt, il définira un délai d'attente pour se réveiller jusqu'à ce que le message soit prêt.

Deuxièmement, vous confondez SystemClock.uptimeMillis() con System.currentTimeMillis() .Below fait partie de la documentation de SystemClock qui explique les deux concepts :

  • SystemClock.uptimeMillis() est comptée en millisecondes depuis le démarrage du système. Cette horloge s'arrête lorsque le système entre en sommeil profond (CPU éteint, affichage sombre, périphérique en attente d'une entrée externe), mais n'est pas affectée par la mise à l'échelle de l'horloge, l'inactivité ou d'autres mécanismes d'économie d'énergie. C'est la base de la plupart des chronométrages par intervalles tels que Thread.sleep(millls), Object.wait(millis) et System.nanoTime(). Cette horloge est garantie comme étant monotone et convient au chronométrage par intervalles lorsque l'intervalle ne couvre pas le sommeil du dispositif.
  • System.currentTimeMillis() est l'horloge "murale" standard (heure et date) exprimant les millisecondes depuis l'époque. L'horloge murale peut être réglée par l'utilisateur ou le réseau téléphonique (voir setCurrentTimeMillis(long)), l'heure peut donc avancer ou reculer de manière imprévisible. Cette horloge ne doit être utilisée que lorsque la correspondance avec les dates et heures du monde réel est importante, par exemple dans une application de calendrier ou de réveil. Les mesures d'intervalles ou de temps écoulé doivent utiliser une autre horloge. Si vous utilisez System.currentTimeMillis(), pensez à écouter les émissions d'intention ACTION_TIME_TICK, ACTION_TIME_CHANGED et ACTION_TIMEZONE_CHANGED pour savoir quand l'heure change.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X