原创内容，转载请注明原文网址：http://homeqin.cn/a/wenzhangboke/jishutiandi/Android/2019/0607/530.html
Android 的按时使命
1，Java的API供应的Timer类
Android 中应用容易受手机的休眠体系影响（例如：手机休眠，导致了这个功效的休止）。
2，Android的Alarm机制
Alarm 机制： 要紧即是借助了AlarmManager 类来实现的。这个类和NotificationManager 有点相似，都是通过挪用Context 的
getSystemService()要领来获取实例的，只是这里必要传入的参数是Context.ALARM_SERVICE。是以，获取一个AlarmManager 的实例便写成：
AlarmManager manager = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
按时使命设置：（例如设定使命10s实行）
long triggerAtTime = SystemClock.elapsedRealtime() + 10 * 1000;
manager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,triggerAtTime,pendingIntent);
参数意思：
应用SystemClock.elapsedRealtime()要领可以获取到体系开机至今所通过光阴的毫秒数，应用System.currentTimeMillis()要领可以获取到1970 年1 月1 日0 点至今所通过光阴的毫秒数。
第一个参数有四个值可以选
------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()要领便得到实行。
设定一个使命在10 秒钟后实行还可以写成：
long triggerAtTime = System.currentTimeMillis() + 10 * 1000;
manager.set(AlarmManager.RTC_WAKEUP, triggerAtTime, pendingIntent);
建立一个可以永远在背景实行按时使命的服无
public class LongRunningService 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("LongRunningService", "executed at " + new Date().
toString());
}
}).start();
AlarmManager manager = (AlarmManager) getSystemService(ALARM_SERVICE);
int anHour = 60 * 60 * 1000; // 这是一小时的毫秒数
long triggerAtTime = SystemClock.elapsedRealtime() + anHour;
Intent i = new Intent(this, AlarmReceiver.class);
PendingIntent pi = PendingIntent.getBroadcast(this, 0, i, 0);
manager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, triggerAtTime, pi);
return super.onStartCo妹妹and(intent, flags, startId);
}
}
onStartCo妹妹and()要领里开启了一个子线程，而后在子线程里便实行详细的逻辑操纵了。
新建一个AlarmReceiver 类，并让它继承自BroadcastReceiver，代码以下所示：
public class AlarmReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
Intent i = new Intent(context, LongRunningService.class);
context.startService(i);
}
}
轮回流程
启动Service ----->onStartCommand()(实行按时使命（并发送播送）----->AlarmReceiver(汲取播送，再次启动Service)-----
| -
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
留意：
从Android 4.4 版本滥觞，Alarm 使命的触发光阴将会变得不准确，有可能会耽误一段光阴后使命才能得到实行。这并不是个bug，而是体系在耗电性方面举行的优化。体系会自动检测当前有几许Alarm 使命存在，而后将触发光阴快要的几个使命放在一起实行，这便大幅度地削减CPU 被唤醒的次数，从而有效延伸电池的应用光阴。固然，如果你要求Alarm 使命的实行光阴必须筹办无误，Android 仍旧供应打听决计划。应用AlarmManager 的setExact()要领来替换set()要领，便包管使命准时实行了。
上篇：上一篇：Android锁屏状况下保持背景唤醒WakeLock机制
下篇：下一篇：ContextCompat.checkSelfPermission失效的问题
