Android Service与Thread以及定时任务

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

1.Java API提供的Timer类

不太适用于那些需要长期在后台运行的定时任务。我们都知道，为了能让电池更加耐用，每种手机都会有自己的休眠策略，Android 手机就会在长时间不操作的情况下自动让 CPU 进入到睡眠状态，这就有可能导致 Timer 中的定时任务无法正常运行

//Timer + TimerTask结合的方法

private final Timer timer = new Timer();

private TimerTask timerTask = new TimerTask() { @Override public void run() { //todo } };

启动定时器方法：

timer.schedule(TimerTask task, long delay, long period)

timer.schedule(timerTask, 0, 1000); //立刻执行，间隔1秒循环执行

timer.schedule(timerTask, 2000, 1000); //等待2秒后再执行，间隔1秒循环执行

关闭定时器方法：timer.cancel();

优点：纯正的定时任务，纯java SDK，单独线程执行，比较安全，而且还可以在运行过程中取消执行

缺点：基于单线程执行，多个任务之间会相互影响，多个任务的执行是串行的，性能较低，而且timer也无法保证时间精确度，是因为手机休眠的时候，无法唤醒cpu，不适合后台任务的定时

2.ScheduledExecutorService

ScheduleExecutorService接口中有四个重要的方法，其中scheduleAtFixedRate和scheduleWithFixedDelay在实现定时程序时比较方便。

关于scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit) 方法说明：

command：需要执行的线程

initialDelay：第一次执行需要延时的时间，如若立即执行，则initialDelay = 0

period：固定频率，周期性执行的时间

unit：时间单位，常用的有MILLISECONDS、SECONDS和MINUTES等，需要注意的是，这个单位会影响initialDelay和period，如果unit = MILLISECONDS，则initialDelay和period传入的是毫秒，如果unit = SECONDS，则initialDelay和period传入的是秒

    private void initTimerJob1() {
        SimpleDateFormat simpleDateFormat = new SimpleDateFormat();
        ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);
        executor.scheduleAtFixedRate(() -> {
            Log.i(TAG, "initTimerJob: start...");
            Log.i(TAG, "initTimerJob: "+ simpleDateFormat.format(System.currentTimeMillis()));
        }, 0, 3, TimeUnit.SECONDS);
3.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;
set()方法中需要传入的三个参数稍微有点复杂，下面我们就来仔细地分析一下
第一个参数是一个整型参数，用于指定 AlarmManager 的工作类型，有四种值可选
ELAPSED_REALTIME    表示让定时任务的触发时间从系统开机开始算起，但不会唤醒CPU
ELAPSED_REALTIME_WAKEUP    同样表示让定时任务的触发时间从系统开机开始算起，但会唤醒CPU
RTC   表示让定时任务的触发时间从1970 年1月1 日0 点开始算起，但不会唤醒CPU
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, AlarmReceiver.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 类， 并让它继承自 BroadcastReceiver：
public class AlarmReceiver extends BroadcastReceiver {
    @Override
    public 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 {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Intent intent = new Intent(this, AutoUpdateService.class);
        startService(intent);
我们所用到的服务和广播接收器都要在 AndroidManifest.xml 中注册才行， 代码如下所示：
<service android:name=".AutoUpdateService" ></service> 
<receiver android:name=".AlarmReceiver" ></receiver> 
执行循环流程 ： 启动Service ——> 执行onStartCommand()方法并发送广播 ——> AlarmReceiver(接收广播，再次启动Service)
android 何时使用Service 何时使用Thread
Service是android 的四大组件之一，被用来执行长时间的后台任务，同样，线程Thread也可以实现在后台执行任务，它们的区别在哪呢？何时使用Service何时使用Thread呢？今天我也来说说我的理解和总结。
首先，需要了解Service的几个特点。
（1） 默认情况下，Service其实是运行在主线程中的，如果需要执行复杂耗时的操作，必须在Service中再创建一个Thread来执行任务。
（2） Service的优先级高于后台挂起的Activity，当然，也高于Activity所创建的Thread，因此，系统可能在内存不足的时候优先杀死后台的Activity或者Thread，而不会轻易杀死Service组件，即使被迫杀死Service，也会在资源可用时重启被杀死的Service
其实，Service和Thread根本就不是一个级别的东西，Service是系统的四大组件之一，Thread只是一个用来执行后台任务的工具类，它可以在Activity中被创建，也可以在Service中被创建。
因此，我们其实不应该讨论该使用Service还是Thread，而是应该讨论在什么地方创建Thread。
典型的应用中，它可以在以下三个位置被创建，不同的位置，其生命周期不一样，所以，我们应该根据该Thread的目标生命周期来决定是在Service中创建Thread还是在Activity中创建它。
（1） 在Activity中被创建
这种情况下，一般在onCreate时创建，在onDestroy()中销毁，否则，Activity销毁后，Thread是会依然在后台运行着。
这种情况下，Thread的生命周期即为整个Activity的生命周期。所以，在Activity中创建的Thread只适合完成一些依赖Activity本身有关的任务，比如定时更新一下Activity的控件状态等。
核心特点：该Thread的就是为这个Activity服务的，完成这个特定的Activity交代的任务，主动通知该Activity一些消息和事件，Activity销毁后，该Thread也没有存活的意义了。
（2）在Application中被创建
这种情况下，一般自定义Application类，重载onCreate方法，并在其中创建Thread，当然，也会在onTerminate()方法中销毁Thread，否则，如果Thread没有退出的话，即使整个Application退出了，线程依然会在后台运行着。
这种情况下，Thread的生命周期即为整个Application的生命周期。所以，在Application中创建的Thread，可以执行一些整个应用级别的任务，比如定时检查一下网络连接状态等等。
核心特点：该Thread的终极目标是为这个APP的各个Activity服务的，包括完成某个Activity交代的任务，主动通知某个Activity一些消息和事件等，APP退出之后该Thread也没有存活的意义了。
以上这两种情况下，Thread的生命周期都不应该超出整个应用程序的生命周期，也就是，整个APP退出之后，Thread都应该完全退出，这样才不会出现内存泄漏或者僵尸线程。
那么，如果你希望整个APP都退出之后依然能运行该Thread，那么就应该把Thread放到Service中去创建和启动了。
（3）在Service中被创建
这是保证最长生命周期的Thread的唯一方式，只要整个Service不退出，Thread就可以一直在后台执行，一般在Service的onCreate()中创建，在onDestroy()中销毁。
所以，在Service中创建的Thread，适合长期执行一些独立于APP的后台任务，比较常见的就是：在Service中保持与服务器端的长连接。
核心特点：该Thread可以为APP提供一些“服务”或者“状态查询”，但该Thread并不需要主动通知APP任何事件，甚至不需要知道APP是谁。
总之，我们不是要考虑该用Thread或者该用Service，而是应该为Thread选择合适的生命周期

1.Java API提供的Timer类

2.ScheduledExecutorService

3.Android 的 Alarm 机制

Alarm 机制 使用方法

android 何时使用Service 何时使用Thread

Alarm 机制使用方法