博文出處：關(guān)于使用AlarmManager的注意事項，歡迎大家關(guān)注我的博客，謝謝！

快過年了，更新春節(jié)前的最后一篇博客。

最近在做一個需求：客戶端按照規(guī)定的時間間隔向服務(wù)端發(fā)送定位。一看到這個需求就想到了使用 AlarmManager 來實現(xiàn)。 AlarmManager 經(jīng)常被用來執(zhí)行定時任務(wù)，比如設(shè)置鬧鈴、發(fā)送心跳包等。也許有人會有疑問：為什么不能使用相同具有定時效果的 Timer 和 Handler 呢？

其實答案非常簡單，相對于 Handler 來說，使用 sendEmptyMessageDelayed 方法是依賴于 Handler 所在的線程的，如果線程結(jié)束，就起不到定時任務(wù)的效果；而 AlarmManager 依賴的是 Android 系統(tǒng)的服務(wù)，具備喚醒機(jī)制。比起 Handler 也就更合適了。

而至于 Timer 可以精確地做到定時操作，但是相比于 AlarmManager 而言還是差了一截。同理，如果手機(jī)關(guān)屏后長時間不使用， CPU 就會進(jìn)入休眠模式。這個使用如果使用 Timer 來執(zhí)行定時任務(wù)就會失敗，因為 Timer 無法喚醒 CPU 。

所以，綜上所述，AlarmManager 就成為了最佳選擇。

SDK API < 19

一般情況下，使用 AlarmManager 來執(zhí)行重復(fù)定時任務(wù)的代碼如下所示：

alarmManager.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), TIME_INTERVAL, pendingIntent);

或者

alarmManager.setRepeating(AlarmManager.RTC_WAKEUP, System.currentTimeMillis(), TIME_INTERVAL, pendingIntent);

setRepeating 該方法用于設(shè)置重復(fù)定時任務(wù)。

• 第一個參數(shù)表示鬧鐘類型：一般為 AlarmManager.ELAPSED_REALTIME_WAKEUP 或者 AlarmManager.RTC_WAKEUP 。它們之間的區(qū)別就是前者是從手機(jī)開機(jī)后的時間，包含了手機(jī)睡眠時間；而后者使用的就是手機(jī)系統(tǒng)設(shè)置中的時間。所以如果設(shè)置為 AlarmManager.RTC_WAKEUP ，那么可以通過修改手機(jī)系統(tǒng)的時間來提前觸發(fā)定時事件。另外，對于相似的 AlarmManager.ELAPSED_REALTIME 和 AlarmManager.RTC 來說，它們不會喚醒 CPU 。所以使用的頻率較少；
• 第二個參數(shù)表示任務(wù)首次執(zhí)行時間：與第一個參數(shù)密切相關(guān)。第一個參數(shù)若為 AlarmManager.ELAPSED_REALTIME_WAKEUP ，那么當(dāng)前時間就為 SystemClock.elapsedRealtime() ；若為 AlarmManager.RTC_WAKEUP ，那么當(dāng)前時間就為 System.currentTimeMillis() ；
• 第三個參數(shù)表示兩次執(zhí)行的間隔時間：這個參數(shù)沒什么好講的，一般為常量；
• 第四個參數(shù)表示對應(yīng)的響應(yīng)動作：一般都是去發(fā)送廣播，然后在廣播接收 onReceive(Context context, Intent intent) 中做相關(guān)操作。

至此，一切順利，暢通無阻。

SDK API >= 19 && SDK API < 23

當(dāng)你寫好代碼、滿心歡喜地將程序跑在手機(jī)上的時候，傻眼了！你會發(fā)現(xiàn)在 Android 4.4 及以上版本的定時任務(wù)不是按照規(guī)定時間間隔來執(zhí)行的。比如你設(shè)置了每隔 3 分鐘發(fā)出一個 HTTP 請求，結(jié)果你一看莫名其妙地變成了隔 5 分鐘發(fā)一次。

What the fuck?

what the fuck

然后你查閱 Android 官網(wǎng)中關(guān)于 Android 4.4 API 會看到如下幾句話：

Android 4.4 API

恍然大悟！原來是 Google 為了追求系統(tǒng)省電，所以“偷偷加工”了一下喚醒的時間間隔。但也正如上面官網(wǎng)中所說的那樣，如果在 Android 4.4 及以上的設(shè)備還要追求精準(zhǔn)的鬧鐘定時任務(wù)，要使用 setExact() 方法。

所以，相應(yīng)的代碼就變成了這樣：

// pendingIntent 為發(fā)送廣播
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    alarmManager.setExact(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), pendingIntent);
} else {
    alarmManager.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), TIME_INTERVAL, pendingIntent);
}

private BroadcastReceiver alarmReceiver = new BroadcastReceiver() {
    @Override
    public void onReceive(Context context, Intent intent) {
        // 重復(fù)定時任務(wù)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
            alarmManager.setExact(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + TIME_INTERVAL, pendingIntent);
        }
        // to do something
        doSomething();
    }
};

當(dāng)你寫好了“加強(qiáng)版”的 AlarmManager 之后，內(nèi)心肯定無比小激動。這下總應(yīng)該行了吧？運行一下，果然沒錯！在 Android 4.4 上的確按照規(guī)定的時間間隔在執(zhí)行任務(wù)。哈哈，這下大功告成了！??！

SDK API >= 23

在 Android 4.4 上品嘗到勝利的甜頭后，你順便在 Android 6.0 的設(shè)備上測試了一下。結(jié)果。。。。。。你又 TMD 傻眼了！

What the fuck

發(fā)現(xiàn)在設(shè)備關(guān)屏靜止一段時間后， AlarmManager 又又又不能正常工作了。相必此時你連日狗的心都有了吧！強(qiáng)忍著淚水，再次打開 Android 官網(wǎng)中關(guān)于 Android 6.0 變更 ，發(fā)現(xiàn)在 Android 6.0 中引入了低電耗模式和應(yīng)用待機(jī)模式。然后接著往下看 對低電耗模式和應(yīng)用待機(jī)模式進(jìn)行針對性優(yōu)化 ，發(fā)現(xiàn)會有下面一段話：

Android 6.0 API

啊啊啊啊啊??！之前在 Android 4.4 上能用的 setExact() 方法在 Android 6.0 上因為低電耗模式又不能正常使用了。但是，Google 又又又提供了新的方法 setExactAndAllowWhileIdle() 來解決在低電耗模式下的鬧鐘觸發(fā)。

所以，Attention！相關(guān)的代碼又被改寫為這樣：

// pendingIntent 為發(fā)送廣播
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    alarmManager.setExactAndAllowWhileIdle(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), pendingIntent);
} else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    alarmManager.setExact(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), pendingIntent);
} else {
    alarmManager.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), TIME_INTERVAL, pendingIntent);
}

private BroadcastReceiver alarmReceiver = new BroadcastReceiver() {
    @Override
    public void onReceive(Context context, Intent intent) {
        // 重復(fù)定時任務(wù)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
            alarmManager.setExactAndAllowWhileIdle(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + TIME_INTERVAL, pendingIntent);
        } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
            alarmManager.setExact(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + TIME_INTERVAL, pendingIntent);
        }
        // to do something
        doSomething();
    }
};

到了這里，總算是把因 Android 版本差異導(dǎo)致 AlarmManager 的“坑”填完了。這份代碼已經(jīng)可以滿足日常的重復(fù)定時任務(wù)了。

好了，該講的都講完了，上床睡覺。倉促地結(jié)尾，預(yù)祝大家新年快樂！

Goodbye ！

References

• AlarmManager
• Android 4.4 API
• Android 6.0 變更
• 對低電耗模式和應(yīng)用待機(jī)模式進(jìn)行針對性優(yōu)化