线程

通过调用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 能够正常的休眠，仅仅有在须要执行任务时醒来一段非常短的时间。