アラームのスケジュールを設定する

アラーム(AlarmManager クラスに基づく)を使用すると、アプリの存続期間外に時間ベースのオペレーションを実行できます。たとえば、アラームを使用して、1 日に 1 回サービスを開始して天気予報をダウンロードするなど、長時間実行オペレーションを開始できます。

アラームには以下の特徴があります。

  • 設定した時間または周期的(あるいはその両方)にインテントを開始できます。

  • ブロードキャスト レシーバと組み合わせて使用すると、ジョブまたは WorkRequests をスケジュールして他のオペレーションを実行できます。

  • これらはアプリの外部で動作するため、アプリが実行されていないときや、デバイス自体がスリープ状態であっても、イベントやアクションをトリガーできます。

  • アプリのリソース要件を最小限に抑えることができます。タイマーや連続実行サービスに依存せずにオペレーションをスケジューリングできます。

不正確なアラームを設定する

アプリで不正確なアラームを設定した場合、システムはアラームを配信します。不正確なアラームは、Doze などのバッテリー節約の制限を考慮しながら、アラーム配信のタイミングをある程度保証します。

デベロッパーは、次の API 保証を利用して、不正確なアラームの配信のタイミングをカスタマイズできます。

指定した時間の後にアラームを配信する

アプリが set()setInexactRepeating()、または setAndAllowWhileIdle() を呼び出した場合、指定されたトリガー時間の前にアラームが鳴ることはありません。

Android 12(API レベル 31)以降では、バッテリー セーバーDoze などのバッテリー節約制限が適用されていない限り、指定されたトリガー時間から 1 時間以内にアラームが呼び出されます。

時間枠内でアラームを配信する

アプリが setWindow() を呼び出した場合、指定されたトリガー時間の前にアラームが鳴ることはありません。バッテリー節約の制限が適用されない限り、アラームは指定されたトリガー時刻から指定された時間枠内で配信されます。

Android 12 以降をターゲットとするアプリの場合、期間付きの不正確なアラームの呼び出しを 10 分以上遅らせることができます。このため、600000windowLengthMillis パラメータ値は 600000 にクリップされます。

ほぼ一定間隔で繰り返しアラームを配信する

アプリが setInexactRepeating() を呼び出すと、システムは複数のアラームを呼び出します。

  1. 最初のアラームは、指定されたトリガー時間から指定された時間枠内で鳴ります。
  2. 後続のアラームは通常、指定された時間枠が経過すると鳴ります。アラームが連続して呼び出されるまでの時間は異なる場合があります。

正確なアラームを設定する

システムは、将来の正確な時点で正確なアラームを呼び出します。

ほとんどのアプリでは、不正確なアラームを使用してタスクやイベントをスケジュール設定し、いくつかの一般的なユースケースに対応できます。目覚ましアプリやカレンダー アプリなど、アプリのコア機能が正確な時刻のアラームに依存している場合は、代わりに正確なアラームを使用しても問題ありません。

正確なアラームを必要としないユースケース

正確なアラームを必要としない一般的なワークフローを以下に示します。

アプリの全期間におけるタイミング処理のスケジュール設定
Handler クラスには、アプリが実行されている間に n 秒ごとになんらかの処理を行うなど、タイミング処理を処理する優れたメソッドがいくつか用意されています: postAtTime()postDelayed()。これらの API は、リアルタイムではなくシステムの稼働時間に依存します。
アプリの更新やログのアップロードなど、バックグラウンド処理のスケジュール設定
WorkManager を使用すると、タイミングが重視される定期処理のスケジュールを設定できます。繰り返し間隔と flexInterval(最小 15 分)を指定して、処理のランタイムをきめ細かく定義できます。
一定の時間が経過した後に行う必要があるユーザー指定のアクション(システムがアイドル状態の場合でも)
不正確なアラームを使用します。具体的には、setAndAllowWhileIdle() を呼び出します。
特定の時間が経過した後に行う必要があるユーザー指定のアクション
不正確なアラームを使用します。具体的には、set() を呼び出します。
指定された時間枠内で行われる可能性があるユーザー指定のアクション
不正確なアラームを使用します。具体的には、setWindow() を呼び出します。なお、Android 12 以降をターゲットとするアプリの場合、指定できる最短のウィンドウ長は 10 分です。

正確なアラームの設定方法

アプリでは、次のいずれかの方法で正確なアラームを設定できます。これらのメソッドは、リストの一番下に近い方ほど、より時間のかかるタスクを処理するものの、より多くのシステム リソースを必要とするように順序付けされています。

setExact()

他のバッテリー節約方法が有効でない限り、ほぼ正確な時刻にアラームを呼び出します。

アプリの作業がユーザーにとって時間を重視する場合を除き、このメソッドを使用して正確なアラームを設定します。

setExactAndAllowWhileIdle()

バッテリー節約対策が有効になっている場合でも、今後ほぼ正確な時刻にアラームを呼び出します。

setAlarmClock()

将来の正確な時刻にアラームを呼び出します。これらのアラームはユーザーがよく目にするため、システムが配信時間を調整することはありません。システムはこれらのアラームを最も重要なアラームとして識別し、アラームを配信するために必要な場合は省電力モードを終了します。

システム リソースの消費

アプリが設定した正確なアラームをシステムがトリガーすると、特に省電力モードの場合、デバイスはバッテリー寿命などのリソースを大量に消費します。さらに、リソースをより効率的に使用するために、システムでこれらのリクエストを簡単にバッチ処理することはできません。

可能な限り、不正確なアラームを作成することを強くおすすめします。長時間処理を実行するには、アラームの BroadcastReceiver から WorkManager または JobScheduler を使用してスケジュールを設定します。デバイスが Doze モード中に処理を実行するには、setAndAllowWhileIdle() を使用して不正確なアラームを作成し、そのアラームからジョブを開始します。

適切な正確なアラームの権限を宣言する

Android 12 以降をターゲットとするアプリの場合、「アラームとリマインダー」の特別なアプリアクセス権を取得する必要があります。そのためには、次のコード スニペットに示すように、アプリのマニフェスト ファイルで SCHEDULE_EXACT_ALARM 権限を宣言します。

<manifest ...>
    <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/>
    <application ...>
        ...
    </application>
</manifest>

Android 13(API レベル 33)以降をターゲットとするアプリの場合、SCHEDULE_EXACT_ALARM 権限または USE_EXACT_ALARM 権限を宣言できます。

<manifest ...>
    <uses-permission android:name="android.permission.USE_EXACT_ALARM"/>
    <application ...>
        ...
    </application>
</manifest>

SCHEDULE_EXACT_ALARM 権限と USE_EXACT_ALARM 権限はどちらも同じ機能を示していますが、付与される権限は異なり、サポートされるユースケースも異なります。アプリ内のユーザー向けの機能が正確な時刻にアクションを実行する必要がある場合にのみ、正確なアラームを使用し、SCHEDULE_EXACT_ALARM 権限または USE_EXACT_ALARM 権限を宣言する必要があります。

USE_EXACT_ALARM

SCHEDULE_EXACT_ALARM

  • ユーザーが許可
  • 幅広いユースケース
  • アプリは権限が取り消されていないことを確認する必要があります

SCHEDULE_EXACT_ALARM 権限の使用

USE_EXACT_ALARM とは異なり、SCHEDULE_EXACT_ALARM 権限はユーザーが付与する必要があります。ユーザーとシステムの両方が SCHEDULE_EXACT_ALARM 権限を取り消すことができます。

アプリに権限が付与されているかどうかを確認するには、正確なアラームを設定する前に canScheduleExactAlarms() を呼び出します。アプリの SCHEDULE_EXACT_ALARM 権限が取り消されると、アプリは停止し、以降の正確なアラームはすべてキャンセルされます。つまり、canScheduleExactAlarms() から返される値は、アプリのライフサイクル全体を通して有効です。

SCHEDULE_EXACT_ALARMS 権限がアプリに付与されると、システムは ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED ブロードキャストをアプリに送信します。アプリでは、次の処理を行うブロードキャスト レシーバを実装する必要があります。

  1. アプリに引き続き特別なアプリアクセス権があることを確認します。そのためには、canScheduleExactAlarms() を呼び出します。このチェックにより、ユーザーがアプリに権限を付与してすぐに権限を取り消した場合、アプリを保護できます。
  2. 現在の状態に基づいて、アプリが必要とする正確なアラームのスケジュールを変更します。このロジックは、アプリが ACTION_BOOT_COMPLETED ブロードキャストを受信したときの動作と同様です。

ユーザーに SCHEDULE_EXACT_ALARM 権限を付与するよう依頼する

[アラームとリマインダーの設定を許可する] というオプション
図 1. システム設定の [アラームとリマインダー] の特別なアプリアクセスのページ。ユーザーはここで、アプリが正確なアラームを設定することを許可できます。

必要に応じて、図 1 に示すように、システム設定の [アラームとリマインダー] 画面にユーザーを誘導できます。そのための手順は次のとおりです。

  1. アプリの UI で、アプリが正確なアラームのスケジュールを設定する必要がある理由をユーザーに説明します。
  2. ACTION_REQUEST_SCHEDULE_EXACT_ALARM インテント アクションを含むインテントを呼び出します。

反復アラームを設定する

繰り返しアラームを使用すると、定期的なスケジュールでアプリに通知できます。

アラームの設計に問題があると、バッテリーの消耗が早まり、サーバーに多大な負荷がかかる可能性があります。このため、Android 4.4(API レベル 19)以降では、繰り返しアラームはすべて不正確なアラームです。

反復アラームには以下の特徴があります。

  • アラームの種類。詳しくは、アラームタイプを選択するをご覧ください。

  • トリガー時間。指定したトリガー時刻が過去の場合、アラームはすぐにトリガーされます。

  • アラームの間隔。たとえば、1 日 1 回、1 時間ごと、5 分ごとなどを指定できます。

  • アラームがトリガーされたときに開始するペンディング インテント。同じペンディング インテントを使用する 2 つ目のアラームを設定すると、元のアラームが置き換えられます。

PendingIntent() をキャンセルするには、FLAG_NO_CREATEPendingIntent.getService() に渡してインテントのインスタンスを取得し(存在する場合)、そのインテントを AlarmManager.cancel() に渡します。

Kotlin

val alarmManager =
    context.getSystemService(Context.ALARM_SERVICE) as? AlarmManager
val pendingIntent =
    PendingIntent.getService(context, requestId, intent,
                                PendingIntent.FLAG_NO_CREATE)
if (pendingIntent != null && alarmManager != null) {
  alarmManager.cancel(pendingIntent)
}

Java

AlarmManager alarmManager =
    (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
PendingIntent pendingIntent =
    PendingIntent.getService(context, requestId, intent,
                                PendingIntent.FLAG_NO_CREATE);
if (pendingIntent != null && alarmManager != null) {
  alarmManager.cancel(pendingIntent);
}

アラームタイプを選択する

繰り返しアラームを使用する際の最初の考慮事項の 1 つは、どのようなタイプにするかです。

アラームの一般的な時計タイプには、「リアルタイム経過時間」と「リアルタイム クロック」(RTC)の 2 種類があります。実経過時間は「システム起動からの時間」を基準として使用し、リアルタイム クロックは UTC(実時間)時間を使用します。つまり、リアルタイム経過時間はタイムゾーンやロケールの影響を受けないため、時間の経過に基づくアラーム(たとえば、30 秒ごとに発生するアラーム)の設定に適しています。リアルタイム クロックタイプは、現在のロケールに依存するアラームに適しています。

どちらのタイプにも「wakeup」バージョンがあり、画面がオフの場合にデバイスの CPU を復帰させるよう指示します。これにより、スケジュール設定した時間にアラームが起動します。 これは、アプリに時間の依存関係がある場合に便利です。たとえば、特定のオペレーションを実行するためのウィンドウが限られている場合などです。アラームタイプのウェイクアップ バージョンを使用しない場合は、デバイスが次に復帰したときに、すべての繰り返しアラームが発生します。

特定の間隔(30 分ごとなど)でアラームを発生させるだけの場合は、リアルタイム経過時間タイプのいずれかを使用します。一般的には、この方法をおすすめします。

特定の時刻にアラームを発生させる必要がある場合は、クロックベースのリアルタイム クロックタイプのいずれかを選択します。ただし、このアプローチにはいくつかの欠点があります。アプリは他の言語 / 地域に適切に変換できない場合があり、ユーザーがデバイスの時刻設定を変更すると、アプリで予期しない動作が発生する可能性があります。また、前述のように、リアルタイム クロックのアラームタイプを使用しても、スケーリングがうまくいきません。可能であれば、「リアルタイム経過時間」のアラームを使用することをおすすめします。

以下に、アラームタイプの一覧を示します。

  • ELAPSED_REALTIME: デバイスが起動してからの経過時間に基づいてペンディング インテントを呼び出しますが、デバイスは復帰しません。この経過時間には、デバイスがスリープしていた時間が含まれます。

  • ELAPSED_REALTIME_WAKEUP: デバイスの起動から指定時間の経過後に、デバイスを復帰させ、ペンディング インテントを起動します。

  • RTC: 指定された時刻にペンディング インテントを呼び出しますが、デバイスは復帰しません。

  • RTC_WAKEUP: 指定した時刻にデバイスを復帰させ、ペンディング インテントを開始します。

実経過時間タイプのアラームの例

ELAPSED_REALTIME_WAKEUP の使用例を次に示します。

30 分後にデバイスを起動し、その後 30 分ごとにアラームを起動します。

Kotlin

// Hopefully your alarm will have a lower frequency than this!
alarmMgr?.setInexactRepeating(
        AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR,
        alarmIntent
)

Java

// Hopefully your alarm will have a lower frequency than this!
alarmMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR, alarmIntent);

1 分後にデバイスのスリープを解除し、アラームを 1 回だけ(反復なし)トリガーします。

Kotlin

private var alarmMgr: AlarmManager? = null
private lateinit var alarmIntent: PendingIntent
...
alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent ->
    PendingIntent.getBroadcast(context, 0, intent, 0)
}

alarmMgr?.set(
        AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + 60 * 1000,
        alarmIntent
)

Java

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() +
        60 * 1000, alarmIntent);

リアルタイム クロックタイプのアラームの例

RTC_WAKEUP の使用例を次に示します。

午後 2 時頃にデバイスを起動してアラームを鳴らし、1 日 1 回、同じ時刻にこれを繰り返します。

Kotlin

// Set the alarm to start at approximately 2:00 p.m.
val calendar: Calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    set(Calendar.HOUR_OF_DAY, 14)
}

// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr?.setInexactRepeating(
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        AlarmManager.INTERVAL_DAY,
        alarmIntent
)

Java

// Set the alarm to start at approximately 2:00 p.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 14);

// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr.setInexactRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        AlarmManager.INTERVAL_DAY, alarmIntent);

午前 8 時 30 分ちょうどにデバイスを起動し、その後 20 分ごとにアラームを作動させます。

Kotlin

private var alarmMgr: AlarmManager? = null
private lateinit var alarmIntent: PendingIntent
...
alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent ->
    PendingIntent.getBroadcast(context, 0, intent, 0)
}

// Set the alarm to start at 8:30 a.m.
val calendar: Calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    set(Calendar.HOUR_OF_DAY, 8)
    set(Calendar.MINUTE, 30)
}

// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr?.setRepeating(
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        1000 * 60 * 20,
        alarmIntent
)

Java

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

// Set the alarm to start at 8:30 a.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 8);
calendar.set(Calendar.MINUTE, 30);

// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        1000 * 60 * 20, alarmIntent);

アラームに必要な精度を決定する

前述のように、多くの場合、アラームタイプの選択はアラーム作成の最初のステップです。さらに、必要なアラームの精度も異なります。ほとんどのアプリでは、setInexactRepeating() を使用することをおすすめします。この方法を使用すると、Android は複数の不正確な繰り返しアラームを同期し、同時に起動します。これにより、電池の消耗を抑えることができます。

可能であれば、正確なアラームの使用は避けてください。ただし、時間の要件が厳しくないアプリの場合は、setRepeating() を呼び出して正確なアラームを設定できます。

setInexactRepeating() では、setRepeating() とは異なり、カスタムの間隔を指定することはできません。間隔定数(INTERVAL_FIFTEEN_MINUTESINTERVAL_DAY など)のいずれかを使用する必要があります。完全なリストについては、AlarmManager をご覧ください。

アラームのキャンセル

アプリによっては、アラームをキャンセルする機能を追加できます。アラームをキャンセルするには、アラーム マネージャーで cancel() を呼び出し、発生させたくない PendingIntent を渡します。次に例を示します。

Kotlin

// If the alarm has been set, cancel it.
alarmMgr?.cancel(alarmIntent)

Java

// If the alarm has been set, cancel it.
if (alarmMgr!= null) {
    alarmMgr.cancel(alarmIntent);
}

デバイスの再起動時にアラームを開始する

デフォルトでは、デバイスがシャットダウンするとすべてのアラームがキャンセルされます。 これを回避するには、ユーザーがデバイスを再起動したときに、繰り返しアラームを自動的に再開するようにアプリを設計します。これにより、ユーザーが手動でアラームを再起動しなくても、AlarmManager はタスクの実行を継続できます。

手順はこちらです。

  1. アプリのマニフェストで RECEIVE_BOOT_COMPLETED 権限を設定します。これにより、システムの起動後にブロードキャストされる ACTION_BOOT_COMPLETED をアプリで受信できるようになります(これは、ユーザーがアプリを少なくとも 1 回起動したことがある場合にのみ機能します)。

    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
  2. ブロードキャストを受信する BroadcastReceiver を実装します。

    Kotlin

    class SampleBootReceiver : BroadcastReceiver() {
    
        override fun onReceive(context: Context, intent: Intent) {
            if (intent.action == "android.intent.action.BOOT_COMPLETED") {
                // Set the alarm here.
            }
        }
    }
    

    Java

    public class SampleBootReceiver extends BroadcastReceiver {
    
        @Override
        public void onReceive(Context context, Intent intent) {
            if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) {
                // Set the alarm here.
            }
        }
    }
    
  3. ACTION_BOOT_COMPLETED アクションをフィルタするインテント フィルタを使用して、アプリのマニフェスト ファイルにレシーバーを追加します。

    <receiver android:name=".SampleBootReceiver"
            android:enabled="false">
        <intent-filter>
            <action android:name="android.intent.action.BOOT_COMPLETED"></action>
        </intent-filter>
    </receiver>

    マニフェストでブート レシーバが android:enabled="false" に設定されていることに注目してください。つまり、アプリが明示的に有効にしない限り、レシーバは呼び出されません。これにより、ブート レシーバが不必要に呼び出されるのを防ぐことができます。レシーバは(たとえば、ユーザーがアラームを設定した場合に)次のようにして有効にできます。

    Kotlin

    val receiver = ComponentName(context, SampleBootReceiver::class.java)
    
    context.packageManager.setComponentEnabledSetting(
            receiver,
            PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
            PackageManager.DONT_KILL_APP
    )
    

    Java

    ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
    PackageManager pm = context.getPackageManager();
    
    pm.setComponentEnabledSetting(receiver,
            PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
            PackageManager.DONT_KILL_APP);
    

    この方法でレシーバを有効にすると、ユーザーがデバイスを再起動しても有効なままになります。つまり、レシーバーをプログラムで有効にすると、再起動後もマニフェスト設定がオーバーライドされます。このレシーバは、アプリが無効にするまで有効のままになります。レシーバは、次のようにして(たとえば、ユーザーがアラームをキャンセルした場合)無効にできます。

    Kotlin

    val receiver = ComponentName(context, SampleBootReceiver::class.java)
    
    context.packageManager.setComponentEnabledSetting(
            receiver,
            PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
            PackageManager.DONT_KILL_APP
    )
    

    Java

    ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
    PackageManager pm = context.getPackageManager();
    
    pm.setComponentEnabledSetting(receiver,
            PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
            PackageManager.DONT_KILL_APP);
    

デバイスが Doze モードのときにアラームを起動する

Android 6.0(API レベル 23)を搭載したデバイスは、デバイスのバッテリー駆動時間を延ばすために役立つ Doze モードをサポートしています。デバイスが Doze モードのときは、アラームは起動しません。スケジュール済みのアラームは、デバイスが Doze モードを終了するまで延期されます。デバイスがアイドル状態の場合でも作業を完了する必要がある場合は、いくつかのオプションを使用できます。

おすすめの方法

繰り返しアラームを設計する際のすべての選択が、アプリによるシステム リソースの使用方法(または悪用)に影響を与える可能性があります。たとえば、サーバーと同期する人気のアプリについて考えてみましょう。同期処理が時刻に基づいており、アプリのすべてのインスタンスが午後 11 時に同期する場合、サーバーに負荷がかかるため、レイテンシが長くなり、「サービス拒否」が発生する可能性があります。アラームを使用する場合は、以下のおすすめの方法に従ってください。

  • アラームの繰り返しの結果としてトリガーされるネットワーク リクエストにランダム性(ジッター)を追加します。

    • アラームがトリガーされたときにローカル処理を実行します。「ローカル処理」とは、サーバーにヒットしない、またはサーバーからのデータを必要としないことを意味します。

    • 同時に、ネットワーク リクエストを含むアラームがランダムな時間で起動するようにスケジュールします。

  • アラームの頻度は最小限に維持します。

  • 不必要にデバイスを起動しないでください(この動作は、アラームタイプを選択するで説明されているように、アラームタイプによって決まります)。

  • アラームのトリガー時刻を必要以上に正確に設定しないでください。

    setRepeating() ではなく setInexactRepeating() を使用します。setInexactRepeating() を使用すると、Android は複数のアプリからの繰り返しアラームを同期し、同時にアラームを発生させます。これにより、システムがデバイスを復帰させる必要がある合計回数が減り、バッテリーの消耗が抑えられます。Android 4.4(API レベル 19)以降では、すべての繰り返しアラームは不正確なアラームです。setInexactRepeating()setRepeating() より改善されていますが、アプリのすべてのインスタンスが同時にサーバーにアクセスすると、サーバーに過剰な負荷がかかる可能性があります。そのため、ネットワーク リクエストの場合は、前述のようにアラームにランダム性を追加します。

  • 可能であれば、アラームを時計の時刻に基づいて設定することは避けてください。

    正確なトリガー時刻に基づいて繰り返しアラームが発生すると、スケーリングがうまくいきません。可能であれば、ELAPSED_REALTIME を使用してください。アラームの種類については、次のセクションで詳しく説明します。