ヘルスサービスにおける目標の逆転
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
ヘルスサービスは、心拍数、距離、速度などの瞬間的な指標のデバウンス目標をサポートするようになりました。デバウンド目標は、ワークアウト全体を通して特定のしきい値や範囲(心拍数など)を維持したいユーザーのユーザー エクスペリエンスを向上させます。
デバウンドされた目標は、同じイベントが短期間に複数回(条件が true になるたびに)送信されることを防ぎます。代わりに、構成可能な期間(通常は数秒)にわたってしきい値が継続的に超過している場合にのみ、イベントが生成されます。[しきい値での継続時間] は、ヘルスサービスがアラート イベントを送信するまでにユーザーが指定のしきい値を超えるのに必要な中断のない時間です。
また、目標を登録した直後にイベントが送信されないようにすることもできます。初期遅延は、目標を登録してからアプリに通知されるまでの経過時間です。
「しきい値に達した期間」と「初期遅延」を組み合わせることで、ユーザーがアプリでフィットネスの目標や目標を設定できる場合に、誤検出や繰り返し表示されるアラートの数を削減できます。
ケーススタディ:心拍数
デバウンス目標の一般的なユースケースは、心拍ゾーンです。心拍数は、特に心肺機能を強化したアクティビティ中に、エクササイズを通して継続的に変動します。デバウンスをサポートしていない場合、ユーザーの心拍数が目標範囲を上回ったり下回ったりするたびに、アプリで短期間に多くのアラートを受け取る可能性があります。
「初期遅延」を導入することで、指定した期間が経過した後にのみゴールアラートを送信するようにヘルスサービスに通知できます。これは、調整期間と考えることができます。「しきい値までの時間」を導入すると、指定したしきい値をユーザーが超えてアクティブになるまでに要する時間を指定できるため、このカスタマイズをさらに進めることができます。
実際には、ユーザーが目標心拍数範囲から 15 秒間外れるのを待ってから、エクササイズの強度を増減するよう通知することがあります。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[null,null,["最終更新日 2025-07-27 UTC。"],[],[],null,["# Debounced goals in Health Services\n\nHealth Services now supports *debounced goals* for instantaneous metrics, such\nas heart rate, distance, and speed. Debounced goals improve the user experience\nfor people who want to maintain a specific threshold or range---such as heart\nrate---throughout their workout.\n\nDebounced goals prevent the same event from being emitted multiple times---every\ntime the condition is true---over a short time period. Instead, events are emitted\nonly if the threshold has been continuously exceeded for a configurable period\nof time, usually some number of seconds. **Duration at threshold** is the amount\nof uninterrupted time the user needs to cross the specified threshold before\nHealth Services sends an alert event.\n\nYou can also prevent events from being emitted immediately after goal\nregistration. **Initial delay** is the amount of time that must pass, since goal\nregistration, before your app is notified.\n\nWhen combined, \"duration at threshold\" and \"initial delay\" reduce the number of\nfalse positives and repeated alerts surfaced to users if your app lets users set\nfitness goals or targets.\n\nCase study: heart rate\n----------------------\n\nA common use case for debounced goals involves heart rate zones. Heart rate\ncontinuously fluctuates throughout an exercise, especially during\ncardio-intensive activities. Without support for debouncing, an app might get\nmany alerts in a short period of time, such as each time the user's heart rate\ndips above or below the target range.\n\nBy introducing an \"initial delay,\" you can inform Health Services to send a goal\nalert only after a specified time period has passed--you can think of this as an\nadjustment period. By introducing a \"duration at threshold,\" you can take this\ncustomization further, by specifying the amount of time that must elapse while\nthe user is in or out of the specified threshold for their goal to be activated.\n\nIn practice, this might involve waiting for the user to be out of their target\nheart rate range for 15 seconds before your app lets them know to increase or\ndecrease their exercise intensity."]]