Timer与AlarmManager的区别

线程

通过调用Thread类的 start()方法来启动一个线程，这时此线程处于就绪（可运行）状态，但此时并没有运行，它需要CPU时间片。一旦得到CPU时间片，就会执行run()方法。run()的方法体称为线程体，它包含了要执行的这个线程的内容，run()方法运行结束，此线程也随即终止。

线程状态转换

一、新建(new)：新创建了一个线程对象。
二、可运行(runnable)：线程对象创建后，其他线程(比如main线程）调用了该对象的start()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获取cpu 的使用权 。
三、运行(running)：可运行状态(runnable)的线程获得了cpu 时间片（timeslice） ，执行程序代码。

四、阻塞(block)：阻塞状态是指线程因为某种原因放弃了cpu 使用权，也即让出了cpu timeslice，暂时停止运行。直到线程进入可运行(runnable)状态，才有机会再次获得cpu timeslice 转到运行(running)状态。阻塞的情况分三种： 

• 等待阻塞：运行(running)的线程执行o.wait()方法，JVM会把该线程放入等待队列(waitting queue)中。
• 同步阻塞：运行(running)的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则JVM会把该线程放入锁池(lock pool)中。
• 其他阻塞：运行(running)的线程执行Thread.sleep(long ms)或t.join()方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入可运行(runnable)状态。

五、死亡(dead)：线程run()、main() 方法执行结束，或者因异常退出了run()方法，则该线程结束生命周期。死亡的线程不可再次复生。

定时器 

Android 平台上常用的定时器主要有两个：

1. Java的Timer
2. Android的AlarmManager

Timer

Java的Timer类可以用来计划需要循环执行的任务。

简单的说，一个Timer内部封装装了“一个Thread”和“一个TimerTask队列”，这个队列按照一定的方式将任务排队处理。封装的Thread在Timer的构造方法调用时被启动，这个Thread的run方法按照条件去循环这个TimerTask队列，然后调用TimerTask的run方法。

但是，如果CPU进入了休眠状态，那么这个thread将会因为失去CPU时间片而阻塞，从而造成我们需要的定时任务失效。上述定时任务失效的场景分析：假设定时任务的条件是到了时间xx:yy才能执行，但由于cpu休眠造成线程阻塞的关系，当前系统时间超过了这个时间，即便CPU从终端中恢复了，那么由于条件不满足，定时任务在这一次自然就失效了。

解决方案是：它需要用WakeLock让CPU 保持唤醒状态。那么问题就来了，这样会大量消耗手机电量，大大减短手机待机时间。这种方式不能满足我们的需求。

注：TimerTask实现Runnable接口，但它的run方法只是简单的在Timer中封装的Thread中被调用，并未将其放在其它线程中执行。也就是说timer是单线程执行的，那么问题来了，为何要这么费劲的封装一个Runnable接口又不进行多线程调用？我的答案是，老外只是想要表示它是可执行的方法。

AlarmManager 

AlarmManager是Android 系统封装的用于管理RTC的模块，RTC(Real Time Clock) 是一个独立的硬件时钟，可以在 CPU 休眠时正常运行，在预设的时间到达时，通过中断唤醒CPU。这意味着，如果我们用 AlarmManager 来定时执行任务，CPU 可以正常的休眠，只有在需要运行任务时醒来一段很短的时间。