Android Service 定时任务
Android 中的定时任务一般有两种实现方式
(这里我们使用的是Android 的 Alarm 机制 )
1.Java API提供的Timer类
不太适用于那些需要长期在后台运行的定时任务。我们都知道,为 了能让电池更加耐用,每种手机都会有自己的休眠策略,Android 手机就会在长时间不操作 的情况下自动让 CPU 进入到睡眠状态,这就有可能导致 Timer 中的定时任务无法正常运行
2.Android 的 Alarm 机制
Alarm 机制具有唤醒 CPU 的功能,即可以保证每次需要执行定时 任务的时候 CPU 都能正常工作
Alarm 机制 使用方法
Alarm 机制: 主要就是借助了AlarmManager 类来实现的。
这个类和NotificationManager 有点类似,都是通过调用Context 的
getSystemService()方法来获取实例的,只是这里需要传入的参数是Context.ALARM_SERVICE。
因此,获取一个AlarmManager 的实例就可以写成:
AlarmManager manager = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
定时任务设置:(例如设定任务 8小时 执行)
int anHour = 8 * 60 * 60 * 1000; // 这是8小时的毫秒数long triggerAtTime = SystemClock.elapsedRealtime() + anHour;manager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, triggerAtTime, PendingIntent);
set()方法中需要传入的三个参数稍微有点复杂,下面我们就来仔细地分析一下
第一个参数是一个整型参数,用于指定 AlarmManager 的工作类型,有四种值可选
------ELAPSED_REALTIME
ELAPSED_REALTIME 表示让定时任务的触发时间从系统开机开始算起,但不会唤醒CPU
------ELAPSED_REALTIME_WAKEUP
ELAPSED_REALTIME_WAKEUP 同样表示让定时任务的触发时间从系统开机开始算起,但会唤醒CPU
------RTC
RTC 表示让定时任务的触发时间从1970 年1月1 日0 点开始算起,但不会唤醒CPU
------RTC_WAKEUP
RTC_WAKEUP 同样表示让定时任务的触发时间从1970 年1 月1 日0 点开始算起,但会唤醒CPU
第二个参数,是定时任务触发的时间,以毫秒为 单位
如果第一个参数使用的是ELAPSED_REALTIME 或ELAPSED_REALTIME_WAKEUP,则这里传入开机至今的时间再加上延迟执行的时间。
如果第一个参数使用的是RTC 或RTC_WAKEUP,则这里传入1970 年1 月1 日0 点至今的时间再加上延迟执行的时间。
第三个参数
PendingIntent
一般会调用getBroadcast()方法来获取一个能够执行广播的PendingIntent。这样当定时任务被触发的时候,广播接收器的onReceive()方法就可以得到执行。
下面我们就来创建一个可以长期在后台执行定时任务的服务
public class AutoUpdateService extends Service { @Override public IBinder onBind(Intent intent) { return null; } @Override public int onStartCommand(Intent intent, int flags, int startId) { new Thread(new Runnable() { @Override public void run() { Log.d("AutoUpdateService ", "executed at " + new Date().toString()); } }).start(); AlarmManager manager = (AlarmManager) getSystemService(ALARM_SERVICE); int anHour = 8 * 60 * 60 * 1000; // 这是8小时的毫秒数 long triggerAtTime = SystemClock.elapsedRealtime() + anHour; Intent i = new Intent(this, AutoUpdateService.class); PendingIntent pi = PendingIntent.getBroadcast(this, 0, i, 0); manager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, triggerAtTime, pi); return super.onStartCommand(intent, flags, startId); }}
我们在 onStartCommand()方法里开启了一个子线程,然后在子线程里就可以执行具体的逻辑操作了。这里简单起见,只是打印了一下当前的时间。
创建线程之后的代码就是我们刚刚讲解的 Alarm 机制的用法了,先是获取到 了 AlarmManager 的实例,然后定义任务的触发时间为一小时后,再使用 PendingIntent 指定处 理定时任务的广播接收器为 AlarmReceiver,最后调用 set()方法完成设定。
显然,AlarmReceiver 目前还不存在呢,所以下一步就是要新建一个 AlarmReceiver 类, 并让它继承自 BroadcastReceiver,代码如下所示:
public class AlarmReceiver extends BroadcastReceiver {@Overridepublic void onReceive(Context context, Intent intent) {Intent i = new Intent(context, AutoUpdateService.class);context.startService(i);}}
onReceive() 方法里的代码非常简单,就是构建出了一个 Intent 对象,然后去启动 AutoUpdateService 这个服务。那么这里为什么要这样写呢?其实在不知不觉中,这就已经 将一个长期在后台定时运行的服务完成了。因为一旦启动 AutoUpdateService ,就会在 onStartCommand()方法里设定一个定时任务,这样一小时后 AlarmReceiver 的 onReceive()方 法就将得到执行,然后我们在这里再次启动 AutoUpdateService ,这样就形成了一个永久的 循环,保证 AutoUpdateService 可以每隔8小时就会启动一次,一个长期在后台定时运行的 服务自然也就完成了。
接下来的任务也很明确了,就是我们需要在打开程序的时候启动一次 AutoUpdateService , 之后 AutoUpdateService 就可以一直运行了。修改 MainActivity 中的代码,如下所示:
public class MainActivity extends Activity {@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);Intent intent = new Intent(this, AutoUpdateService.class);startService(intent);}}
最后别忘了,我们所用到的服务和广播接收器都要在 AndroidManifest.xml 中注册才行, 代码如下所示:
更多相关文章
- Android USB HID设备通信controlTransfer 接口参数
- 一点见解: Android事件分发机制(二)
- Android开发知识(八):Android事件处理机制:事件分发、传递、拦截、处
- Android 复盘——帮你彻底了解消息机制
- Android中动态初始化布局参数以及ConstraintLayout使用中遇到的