Android 使用Timer代替Handler 做循环任务 节省内存_android的不使用handler实现计时器

在项目开发当中经常会遇到这样的问题，就是需要监听当前网络连接的状态。使用handler不断的发送延时消息可以实现循环监听，但这样消耗的内存会很大，因为这是在主线程中运行的。这个时候使用计时器Timer去执行计时任务就很合适了，可以在TimerTask和主线程中调用Thread.currentThread().getId()比较线程的ID,发现Timer是运行在子线程的。

timer.schedule(new MyTask(),long time1,long timer2);

今天算是彻底的搞懂了这个曾经让我为之头疼的方法。下面我就重点介绍一下：

第一个参数，是 TimerTask 类，在包：import Java.util.TimerTask .使用者要继承该类，并实现public void run() 方法，因为 TimerTask 类 实现了 Runnable 接口。

第二个参数的意思是，当你调用该方法后，该方法必然会调用 TimerTask 类 TimerTask 类 中的 run()方法，这个参数就是这两者之间的差值，转换成汉语的意思就是说，用户调用 schedule() 方法后，要等待这么长的时间才可以第一次执行run() 方法。

第三个参数的意思就是，第一次调用之后，从第二次开始每隔多长的时间调用一次 run() 方法。

[附：]

　　技术人员在实现内部办公系统与外部网站一体化的时候，最重要的步骤就是从OA系统读取数据，并且根据网站模板生成最终的静态页面。这里就需要一个定时任务，循环的执行。

　　技术人员在写定时任务的时候，想当然的以为Timer.schedule(TimerTask task, longdelay)就是重复的执行task。程序运行后发现只运行了一次，总觉得是task里的代码有问题，花了很长时间调试代码都没有结果。

　　仔细研读Java api，发现：

　　schedule(TimerTask task, long delay)的注释：Schedules thespecified task for execution after the specifieddelay。大意是在延时delay毫秒后执行task。并没有提到重复执行

　　schedule(TimerTask task, long delay, long period)的注释：Schedulesthe specified task for repeated fixed-delay execution, beginningafter the specified delay。大意是在延时delay毫秒后重复的执行task，周期是period毫秒。

　　这样问题就很明确schedule(TimerTask task, longdelay)只执行一次，schedule(TimerTask task, long delay, longperiod)才是重复的执行。关键的问题在于程序员误以为schedule就是重复的执行，而没有仔细的研究API，一方面也是英文能力不够，浏览API的过程中不能很快的理解到含义。

schedule的意思（时间表、进度表）
timer.schedule(new MyTask(event.getServletContext()), 0, 60*60*1000);

第一个参数"new MyTask(event.getServletContext())":
是 TimerTask 类，在包：import java.util.TimerTask .使用者要继承该类，并实现 public void run() 方法，因为 TimerTask 类实现了 Runnable 接口。

第二个参数"0"的意思是:(0就表示无延迟)
当你调用该方法后，该方法必然会调用 TimerTask 类 TimerTask 类 中的 run() 方法，这个参数就是这两者之间的差值，转换成汉语的意思就是说，用户调用 schedule() 方法后，要等待这么长的时间才可以第一次执行 run() 方法。

第三个参数"60*60*1000"的意思就是:
(单位是毫秒60*60*1000为一小时)
(单位是毫秒3*60*1000为三分钟)
第一次调用之后，从第二次开始每隔多长的时间调用一次 run() 方法。