The difference between Systemclock.sleep and Thread.Sleep

In Java when we deal with thread synchronization problems, processing latency may use the thread class's sleep method, where some methods of the concurrent class are thrown away, in fact The Android platform also provides a Systemclock.sleep method, what is the difference between them?

The interruptedexception exception may occur every time we call Thread.Sleep, and the Systemclock.sleep method does not, as described on the SDK, will ignore the interrupt exception.

Systemclock.sleep (Millis) is a utility function very similar to Thread.Sleep (Millis), but it ignores interruptedexception. Here is to remind that this is the use of the "this function for delays if the" Thread.Interrupt (), as it will preserve the interrupted St Ate of the thread.

Three different clocks is available, and they should not being confused:

• system.currenttimemillis ()  is the standard "wall" clock (time and date) expressing milliseconds since the epoch. The wall clock can is set by the user or the phone network (see Setcurrenttimemillis (Long) ) and so the time May J UMP backwards or forwards unpredictably. This clock should only being used when correspondence with real-world dates and times are important, such as in a calendar or Alarm Clock application. Interval or elapsed time measurements should use a different clock. If you is using System.currenttimemillis (), consider listening to the  Action_time_tick , ACTION _time_changed  and  action_timezone_changed   Intent   Broadcasts to find when the time changes.

• uptimemillis ()  is counted in milliseconds since the system was booted. This clock stops while the system enters deep sleep (CPU off, display dark, device waiting for external input) Affected by clock scaling, idle, or other power saving mechanisms. The basis for most interval timing such as thread.sleep (millls) ,   object.wait (Millis) , and  system.nanotime () . This clock was guaranteed to being monotonic, and is the recommended basis for the general purpose interval timing of user int Erface events, performance measurements, and anything else, does not need to measure elapsed time during device sleep. Most methods that accept a timestamp value expect the  Uptimemillis ()  clock.

• elapsedRealtime()is counted in milliseconds since the system were booted, including deep sleep. This clock should is used when measuring time intervals the May span periods of system sleep.

There is several mechanisms for controlling the timing of events:

• Standard functions like and is always Thread.sleep(millis) Object.wait(millis) available. These functions use uptimeMillis() the clock; If the device enters sleep, the remainder of the time would be postponed until the dev Ice wakes up. These synchronous functions Thread.interrupt() is interrupted with, and you must handle InterruptedException .

• SystemClock.sleep(millis)is a utility function very similar Thread.sleep(millis) to, but it ignores InterruptedException . Use the This function for delays if-do not use Thread.interrupt() , as it would preserve the interrupted state of the thread.

• The Handler class can schedule asynchronous callbacks at an absolute or relative time. Handler objects also use uptimeMillis() the clock, and require a event loop (normally present in any GUI application).

• The AlarmManager can trigger one-time or recurring events which occur even when the device was in deep sleep or your application I s not running. Events May is scheduled with your choice currentTimeMillis() of (RTC) or elapsedRealtime() (elapsed_realtime), and cause a Intent broadcast when they occur.

The difference between Systemclock.sleep and Thread.Sleep (RPM)