阿里云企業(yè)網(wǎng)站怎么收費百度競價排名多少錢
AlarmManager 定時任務
- 使用場景
- API
- 1.設置定時任務
- 1.1.單次定時任務 (set)
- 1.2.設置在時間段執(zhí)行的定時任務(setWindow)
- 1.3.設置單次準確的定時任務(setExact 、setAlarmClock)
- 1.4.設置在低功耗條件下也執(zhí)行的定時任務 (setAndAllowWhileIdle、setExactAndAllowWhileIdle)
- 1.5.設置循環(huán)的定時任務(setRepeating、setInexactRepeating)
- 1.6.設置定時任務的方法如何選擇?
- 1.7.系統(tǒng)為我們做了版本兼容的封裝
- 2.剩余
- 2.1.取消鬧鐘設置
- 2.2.獲取下次鬧鐘
- 2.3.設置系統(tǒng)時間
- 2.4.設置系統(tǒng)時間時區(qū)
- 版本變更記錄
- 參考地址
使用場景
設置鬧鈴
發(fā)送心跳包
API
1.設置定時任務
功能說明:
設置一個在未來的某個時間運行應用的PendingIntent 或者OnAlarmListener ,即使設備已經(jīng)進入睡眠(Cpu休眠)已設置的鬧鈴也會被保持,只有當設備關閉或是重啟的時候會被清除
1.1.單次定時任務 (set)
void set(@AlarmType int type, long triggerAtMillis, PendingIntent operation)
void set(@AlarmType int type, long triggerAtMillis, String tag, OnAlarmListener listener, Handler targetHandler)
含義:
設置一個鬧鐘,這個鬧鐘設置在API 19以下是準確的,API 19及以上因為系統(tǒng)的優(yōu)化(系統(tǒng)要批量處理這些鬧鐘以減少喚醒次數(shù),減少電池的使用),不再準確。如果想在API 19及以上的版本依然準備需要使用 setWindow 或者 setExact 。
API翻譯:
安排警報。<b>注意:對于計時操作(滴答聲、超時等),使用{@linkandroid.os.Handler}更容易、更高效。
如果已經(jīng)為同一個IntentSender安排了一個警報,則之前的警報將首先被取消。
如果規(guī)定的觸發(fā)時間是過去的,則會立即觸發(fā)報警。
如果已經(jīng)計劃了此意圖的警報(由{@link Intent#filterEquals}定義兩個意圖相等),則將刪除該警報并替換為此警報。
報警是一種意圖廣播,發(fā)送到您在{@link android.content.Context#registerReceiver}注冊的廣播接收器,或通過<;接收器(>);AndroidManifest中的標記。xml文件。報警意圖與類型為int的額外數(shù)據(jù)一起傳遞,該數(shù)據(jù)稱為{@link Intent#EXTRA_ALARM_COUNT Intent.EXTRA_ALARM_COUNT} ,指示有多少過去的報警事件累積到此意圖廣播中。由于手機處于睡眠狀態(tài)而無法發(fā)送的重復報警在發(fā)送時的計數(shù)可能大于1。<b>注:從API 19開始,傳遞給此方法的觸發(fā)時間被視為不精確:在此時間之前不會發(fā)出警報,但可能會推遲一段時間并在稍后發(fā)出。
操作系統(tǒng)將使用此策略在整個系統(tǒng)中“批量”報警,
將設備需要“喚醒”的次數(shù)降至最低,并將電池使用降至最低。
一般來說,只要計劃在遙遠的將來進行報警,則不會延遲計劃在不久的將來進行的報警。
有了新的批處理策略,交貨訂單保證不如以前那么有力。
如果應用程序設置了多個警報,則這些警報的實際交付順序可能與其請求的交付時間順序不匹配。
如果您的應用程序有很強的排序需求,那么您可以使用其他API來獲得必要的行為;
請參閱{@link #setWindow(int, long, long, PendingIntent)}和 {@link #setExact(int, long, PendingIntent)}.{@code targetSdkVersion}在API 19之前的應用程序?qū)⒗^續(xù)獲得以前的報警行為:所有計劃的報警都將被視為精確的。
參數(shù):
參數(shù) @AlarmType int type
事件參照物,以及是否在休眠時喚起//時間參照物是當前系統(tǒng)時間,并且喚醒CPUpublic static final int RTC_WAKEUP = 0;//時間參照物是當前系統(tǒng)時間,不喚醒CPUpublic static final int RTC = 1;//時間參照物是系統(tǒng)到目前的時間(包括系統(tǒng)休眠),且喚醒CPUpublic static final int ELAPSED_REALTIME_WAKEUP = 2;//時間參照物是系統(tǒng)到目前的時間(包括系統(tǒng)休眠),不喚醒CPUpublic static final int ELAPSED_REALTIME = 3;參數(shù) long triggerAtMillis
觸發(fā)執(zhí)行的時間參數(shù) PendingIntent operation
掛起的意圖
測試代碼
@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_alarm);AlarmManager alarmManager = (AlarmManager) getSystemService(Context.ALARM_SERVICE);Intent intent = new Intent();intent.setClass(this, AlarmActivity.class);intent.setAction("這是set過來的intent");PendingIntent pi = PendingIntent.getActivity(this, 0, intent, 0);alarmManager.cancel(pi);int interval = 5 * 1000;findViewById(R.id.btn_test_1).setOnClickListener(new View.OnClickListener() {@Overridepublic void onClick(View v) {AppLogUtils.input(TAG, "onClick btn_test_1");alarmManager.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + interval, pi);}});****}@Overrideprotected void onNewIntent(Intent intent) {super.onNewIntent(intent);AppLogUtils.input(TAG, "onNewIntent");AppLogUtils.input(TAG, "onNewIntent.getAction == " + intent.getAction());((TextView) findViewById(R.id.tv_content)).setText(intent.getAction());}
最終成功調(diào)用到 onNewIntent(),此時設置 android:launchMode=“singleTask”
1.2.設置在時間段執(zhí)行的定時任務(setWindow)
void setWindow(@AlarmType int type, long windowStartMillis, long windowLengthMillis,PendingIntent operation)
void setWindow(@AlarmType int type, long windowStartMillis, long windowLengthMillis,String tag, OnAlarmListener listener, Handler targetHandler)
含義:
如果SDK版本在 Android 4.4 (Api 19)=< SDK < Android 6.0 (Api 23)這個區(qū)間,我們對鬧鐘的時序性要求較高,但是對及時性要求不高時,可以使用 setWindow 。
setWindow 不會讓鬧鐘被系統(tǒng)批量處理(如set方法),而是按照設置的先后順序處理(嚴格的排序保證),但是同時setWindow 的鬧鐘及時性不準確。
翻譯API:
安排在給定時間窗口內(nèi)發(fā)出警報。此方法類似于{@link#set(int,long,PendingIntent)},但允許應用程序精確控制操作系統(tǒng)可能調(diào)整其交付的程度。這種方法允許應用程序利用交付批處理產(chǎn)生的電池優(yōu)化,即使它對警報的及時性要求不高。此方法還可用于通過確保每個報警請求的窗口不相交,在多個報警之間實現(xiàn)嚴格的排序保證。當不需要精確傳遞時,應用程序應該使用標準的{@link#set(int,long,PendingIntent)}方法。這將為操作系統(tǒng)提供最大的靈活性,以最小化喚醒和電池使用。對于必須在精確指定的時間發(fā)出且沒有可接受的變化的報警,應用程序可以使用{@link#setExact(int,long,PendingIntent)}。
參數(shù):
參數(shù) long windowStartMillis
觸發(fā)執(zhí)行的時間段左邊界參數(shù) long windowLengthMillis
時間段長度
測試代碼:
alarmManager.setWindow(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + interval, interval, pi);
1.3.設置單次準確的定時任務(setExact 、setAlarmClock)
void setExact(@AlarmType int type, long triggerAtMillis, PendingIntent operation)
void setExact(@AlarmType int type, long triggerAtMillis, String tag,OnAlarmListener listener, Handler targetHandler)void setAlarmClock(AlarmClockInfo info, PendingIntent operation)
setExact 含義:
如果SDK版本在 Android 4.4 (Api 19)=< SDK < Android 6.0 (Api 23)這個區(qū)間,我們對鬧鐘的時序性要求較高,同時要求及時性要求也高時,可以使用 setExact 。
setExact 不會讓鬧鐘被系統(tǒng)批量處理(如set方法),而是按照設置的先后順序處理(嚴格的排序保證),同時setExact 的鬧鐘及時性準確。
翻譯API:
安排在規(guī)定的時間準確發(fā)出警報。
此方法類似于{@link#set(int,long,PendingIntent)},但不允許操作系統(tǒng)調(diào)整傳遞時間。
警報將盡可能接近請求的觸發(fā)時間。
<b>注意:</b>只有對準確時間交付有強烈需求的報警(如在請求的時間鬧鐘響)才應安排為準確。
強烈建議應用程序不要不必要地使用精確警報,因為它們會降低操作系統(tǒng)將電池使用降至最低的能力。
setAlarmClock 含義:
SDK版本在 大于 Android 4.4 (Api 19),都可以使用 setAlarmClock
指定鬧鐘事件AlarmManager.setAlarmClock()的事件會在鬧鐘結(jié)束前,令系統(tǒng)短暫的完全退出Doze模式,并且正常處理事件,系統(tǒng)為了突顯該鬧鐘事件,將會在status bar上顯示物理鬧鐘的icon。
翻譯API:
安排一個代表鬧鐘的鬧鐘,該鬧鐘將用于在鬧鐘熄滅時通知用戶。我們的期望是,當該警報觸發(fā)時,
該應用程序?qū)⑦M一步喚醒設備,告訴用戶有關警報的信息——打開屏幕、播放聲音、振動等。
因此,如果合適,系統(tǒng)通常還會使用此處提供的信息告知用戶即將發(fā)生的警報。由于這種報警的性質(zhì)類似于{@link#setExactAndAllowHileidle},即使系統(tǒng)處于低功率閑置(又稱打盹)模式,也允許觸發(fā)這些警報。當系統(tǒng)看到出現(xiàn)此類警報時,也可能會進行一些準備工作,
為了減少在導致設備完全喚醒時可能發(fā)生的后臺工作量,這是為了避免出現(xiàn)大量設備在早上的同一時間設置了警報的情況,
所有人都在那個時候醒來,突然間,網(wǎng)絡上充斥著懸而未決的背景工作。
因此,這些類型的報警器在電池使用上可能非常昂貴,并且只能用于其預期用途。此方法類似于{@link#setExact(int,long,PendingIntent)},但暗指{@link#RTC_WAKEUP}。
1.4.設置在低功耗條件下也執(zhí)行的定時任務 (setAndAllowWhileIdle、setExactAndAllowWhileIdle)
Android 6.0 (Api 23)及以上,系統(tǒng)新增低功耗空閑(又稱doze)模式,
這種模式下setExact 和 setWindow 方法失效,因為不能喚醒系統(tǒng),除此模式以外的場景,依然是準確的。
如果想打破這種限制,可以喚醒系統(tǒng),需要使用 setAndAllowWhileIdle 或者 setExactAndAllowWhileIdle。
setAndAllowWhileIdle 含義:
setAndAllowWhileIdle 設置的警報可以被批量處理,低功耗空閑(又稱doze)模式下,準確度更低。
翻譯API:
與{@link#set(int,long,PendingIntent)}類似,但即使系統(tǒng)處于低功耗空閑(又稱doze)模式,也允許執(zhí)行此警報。
這種類型的警報必須僅用于實際需要在空閑時發(fā)出警報的情況——一個合理的例子是日歷通知,它應該發(fā)出聲音,以便用戶知道。
當警報發(fā)出時,該應用程序還將被添加到系統(tǒng)的臨時白名單中約10秒,以允許該應用程序獲取進一步的喚醒鎖,從而完成其工作。當設備閑置時,這些警報可能會嚴重影響設備的電源使用(從而導致調(diào)度警報的應用程序嚴重的電池故障),因此應謹慎使用。
為了減少濫用,對特定應用程序發(fā)出警報的頻率有限制。
在正常系統(tǒng)運行情況下,其發(fā)出這些警報的時間不會超過大約每分鐘一次(此時發(fā)出所有此類待處理警報);
在低功率怠速模式下,此持續(xù)時間可能會明顯更長,例如15分鐘。與其他警報不同,該系統(tǒng)可以自由地重新安排此類警報與任何其他警報(甚至來自同一應用程序的警報)無序發(fā)生。
當設備空閑時,這顯然會發(fā)生(因為此警報可以在空閑時熄滅,當應用程序的任何其他警報將保持到稍后),但即使在不空閑時也可能發(fā)生。無論應用程序的目標SDK版本如何,此調(diào)用始終允許成批處理警報。
setExactAndAllowWhileIdle含義:
setExactAndAllowWhileIdle 也可以喚醒系統(tǒng),和 setAndAllowWhileIdle 對比準確度更高,不會被系統(tǒng)批量處理。
翻譯API:
與{@link#setExact(int,long,PendingIntent)}類似,但即使系統(tǒng)處于低功耗空閑模式,也允許執(zhí)行此警報。
如果不需要精確的警報調(diào)度,但仍需要在空閑時執(zhí)行,請考慮使用{@link#setAndAllowWhileIdle}。
這種類型的警報必須僅用于實際需要在空閑時發(fā)出警報的情況——一個合理的例子是日歷通知,它應該發(fā)出聲音,以便用戶知道。
當警報發(fā)出時,該應用程序還將被添加到系統(tǒng)的臨時白名單中約10秒,以允許該應用程序獲取進一步的喚醒鎖,從而完成其工作。當設備閑置時,這些警報可能會嚴重影響設備的電源使用(從而導致調(diào)度警報的應用程序嚴重的電池故障),因此應謹慎使用。
為了減少濫用,對特定應用程序發(fā)出警報的頻率有限制。
在正常系統(tǒng)運行情況下,其發(fā)出這些警報的時間不會超過大約每分鐘一次(此時發(fā)出所有此類待處理警報);
在低功率怠速模式下,此持續(xù)時間可能會明顯更長,例如15分鐘。與其他警報不同,該系統(tǒng)可以自由地重新安排此類警報與任何其他警報(甚至來自同一應用程序的警報)無序發(fā)生。
當設備空閑時,這顯然會發(fā)生(因為此警報可以在空閑時熄滅,當應用程序的任何其他警報將保持到稍后),但即使在不空閑時也可能發(fā)生。請注意,由于應用程序選擇了這種行為,因此操作系統(tǒng)將允許自己比常規(guī)的精確報警更靈活地安排這些報警。
當設備空閑時,為了優(yōu)化電池壽命,可能需要更多的時間安排。
1.5.設置循環(huán)的定時任務(setRepeating、setInexactRepeating)
//循環(huán)定時,時間準確
void setRepeating(@AlarmType int type, long triggerAtMillis,long intervalMillis, PendingIntent operation)
//循環(huán)定時,時間不準確
void setInexactRepeating(@AlarmType int type, long triggerAtMillis,long intervalMillis, PendingIntent operation)
setRepeating、setInexactRepeating()方法用于Android 4.4(Api 19)以下,大于19的版本可以使用變通的方案:setExactAndAllowWhileIdle + pendintent.getBroadcast
1.6.設置定時任務的方法如何選擇?
如果你期望每次都是按照你的設想響應定時任務:
小于 API 19 :
set、setRepeating、setInexactRepeating
大于等于 API 19 小于 API 23:
setWindow、setExact 、setAlarmClock
大于 API 23:
如果想要在低功耗空閑(又稱doze)模式下使用
setAndAllowWhileIdle、setExactAndAllowWhileIdle、setAlarmClock
但是這樣會更影響電池的使用時長,非必要可以不這么選擇。
1.7.系統(tǒng)為我們做了版本兼容的封裝
https://developer.android.google.cn/reference/androidx/core/app/AlarmManagerCompat
public final class AlarmManagerCompat {public static void setAlarmClock(@NonNull AlarmManager alarmManager, long triggerTime,@NonNull PendingIntent showIntent, @NonNull PendingIntent operation) {if (Build.VERSION.SDK_INT >= 21) {alarmManager.setAlarmClock(new AlarmManager.AlarmClockInfo(triggerTime, showIntent),operation);} else {AlarmManagerCompat.setExact(alarmManager, AlarmManager.RTC_WAKEUP, triggerTime,operation);}}public static void setAndAllowWhileIdle(@NonNull AlarmManager alarmManager, int type,long triggerAtMillis, @NonNull PendingIntent operation) {if (Build.VERSION.SDK_INT >= 23) {alarmManager.setAndAllowWhileIdle(type, triggerAtMillis, operation);} else {alarmManager.set(type, triggerAtMillis, operation);}}public static void setExact(@NonNull AlarmManager alarmManager, int type, long triggerAtMillis,@NonNull PendingIntent operation) {if (Build.VERSION.SDK_INT >= 19) {alarmManager.setExact(type, triggerAtMillis, operation);} else {alarmManager.set(type, triggerAtMillis, operation);}}public static void setExactAndAllowWhileIdle(@NonNull AlarmManager alarmManager, int type,long triggerAtMillis, @NonNull PendingIntent operation) {if (Build.VERSION.SDK_INT >= 23) {alarmManager.setExactAndAllowWhileIdle(type, triggerAtMillis, operation);} else {AlarmManagerCompat.setExact(alarmManager, type, triggerAtMillis, operation);}}private AlarmManagerCompat() {}
}
2.剩余
2.1.取消鬧鐘設置
cancel
2.2.獲取下次鬧鐘
getNextAlarmClock
2.3.設置系統(tǒng)時間
setTime
2.4.設置系統(tǒng)時間時區(qū)
setTimeZone
版本變更記錄
版本4.4(19)變更說明:https://developer.android.google.cn/about/versions/android-4.4
如果您的應用使用 AlarmManager…
將您的應用的 targetSdkVersion 設置為“19”或更高版本時,您使用 set() 或 setRepeating() 創(chuàng)建的鬧鈴將變得不準確。
為提高電源效率,Android 現(xiàn)在批處理在合理的相似時間發(fā)生的所有應用的鬧鈴,以便系統(tǒng)僅喚醒設備一次,而不是多次喚醒設備來處理每個鬧鈴。
如果您的鬧鈴沒有與精確的時鐘時間關聯(lián),但您的鬧鈴仍必須在特定時間范圍(例如,在下午 2 點至 4 點之間)觸發(fā),那么您可以使用新的 setWindow() 方法,其接受鬧鈴的“最早”時間以及最早時間之后的一個時間“窗口”,在這個窗口內(nèi),系統(tǒng)應觸發(fā)鬧鈴。
如果您的鬧鈴必須固定到一個精確的時鐘時間(例如,日歷事件提醒),那么您可以使用新的 setExact() 方法。
這個精確的批處理行為僅適用于更新后的應用。如果您已將 targetSdkVersion 設置為“18”或更低版本,那么在 Android 4.4 上運行時,您的鬧鈴的行為方式和在以前版本上一樣。
Android 6.0 針對低電耗模式和應用待機模式進行優(yōu)化:https://developer.android.google.cn/training/monitoring-device-state/doze-standby
在低電耗模式下,您的應用會受到以下限制:
標準 AlarmManager 鬧鐘(包括 setExact() 和 setWindow())推遲到下一個維護期。
如果您需要設置在設備處于低電耗模式時觸發(fā)的鬧鐘,請使用 setAndAllowWhileIdle() 或 setExactAndAllowWhileIdle()。
使用 setAlarmClock() 設置的鬧鐘將繼續(xù)正常觸發(fā),系統(tǒng)會在這些鬧鐘觸發(fā)之前不久退出低電耗模式。
*使應用適應低電耗模式
低電耗模式可能會對應用產(chǎn)生不同的影響,具體取決于應用提供的功能和使用的服務。許多應用無需修改即可在低電耗模式周期內(nèi)正常運行。在某些情況下,您必須優(yōu)化應用管理網(wǎng)絡、鬧鐘、作業(yè)和同步的方式。應用應該能夠在每個維護期內(nèi)高效地管理活動。
低電耗模式尤其可能會影響 AlarmManager 鬧鐘和定時器管理的活動,因為當系統(tǒng)處于低電耗模式時,不會觸發(fā) Android 5.1(API 級別 22)或更低版本中的鬧鐘。
為了幫助安排鬧鐘,Android 6.0(API 級別 23)引入了兩種新的 AlarmManager 方法:setAndAllowWhileIdle() 和 setExactAndAllowWhileIdle()。通過這些方法,您可以設置即使設備處于低電耗模式也會觸發(fā)的鬧鐘。
注意:setAndAllowWhileIdle() 及 setExactAndAllowWhileIdle() 為每個應用觸發(fā)鬧鐘的頻率都不能超過每 9 分鐘一次。
參考地址
AlarmManager 定時任務詳解:https://blog.csdn.net/kingyc123456789/article/details/107179126
AlarmManager(系統(tǒng)服務之定時服務):https://blog.csdn.net/wuto_/article/details/110494026
Android后臺調(diào)度任務與省電:https://www.ktanx.com/blog/p/4827