0

transferUserInfo統計データを時計に送信するために使用しています。

時計がスリープ状態またはアイドリング状態 (時計を表示) で、電話アプリが実行されている場合、多くの情報が転送されます (繰り返しタイマーによってトリガーされます)。

アプリはいくつの「userinfo」キューを送信できますか? 制限はありますか？

4

1 に答える 1

2

キューは 1 つだけです (システムによって提供されます)。

transferUserInfoキューに追加できるメッセージの数に制限があることは知りません。

ただし、次の 2 つの点を考慮する必要があります。

  • iOS はメッセージを送信し、そのキューを空にすることができますが、送信された (まだ処理されていない) メッセージは、アプリが受信できるようになるまで watchOS によって保持されます。ある時点で、時計がアプリのメッセージを保持できなくなる可能性があります。

    Apple がその状態をどのように処理するかは正確にはわかりませんが、転送が失敗するか、さらに悪い場合には破棄される可能性があることを計画する必要があります。

    特定のシステムの制限を回避しようとしてアプリを設計しないでください。特に、発生する可能性のある状況を処理するための不測の事態がない場合は、脆弱で破損する可能性があります。

  • (短い) 期間に (多数の) メッセージを絶えず送信することが予想される場合、これはメモリやエネルギーの使用に関して効率的ではありません。

    優れたユーザー エクスペリエンスを実現するには、Apple のパフォーマンスに関するヒントに従う必要があります。アプリが携帯電話や時計のバッテリー寿命の低下の原因であることが判明した場合、ユーザーはそのアプリの使用をやめます。

より良いアプローチ

電話と時計の間の雑談を避けるためのいくつかの代替アプローチを次に示します。

  • updateApplicationContext個別に処理する必要があるメッセージの長いキューではなく、電話と時計が単一のコンテキストのみを処理する必要があるなど、別の方法を使用します。

  • 携帯電話で統計を維持します。ウォッチが要求/必要とするまで、現在の統計を転送しないでください。(これは、ユーザーがアプリを起動する前にバックグラウンドでアプリを更新できるため、watchOS 3 の優れたアプローチです)。

  • データをバッチ処理して、時間の経過とともに送信する更新を減らします。

    • コンプリケーションを更新していない場合は、非アクティブなアプリを 1 時間に 1 回以上更新する予定はありません。
    • コンプリケーションを更新する場合は、1 時間に 4 回を超える更新を計画しないでください (ただし、1 時間に 1 回を超えないことが望ましいです)。

繰り返しますが、特定の数字を目指してはいけません。一般に、更新できる頻度が少ないほど良いです。

どちらの方法を選択する場合でも、アプリが堅牢であり、システムによって終了されることを含め、あらゆる種類の障害 (メモリの過剰使用やバックグラウンドでの CPU の過剰使用など) を処理できることを確認してください。

詳細については

これら 2 つの watchOS セッションでは、特に、いつ、なぜ、どのようにウォッチを更新するかについて説明し、特定の使用状況に関する更新のスケジュールについて説明します。たとえば、交通機関が運行されていない場合は、夜間に交通機関の情報を更新しないでください。

  • Watch アプリを更新するタイミングと理由を説明する優れた紹介は、優れたApple Watch エクスペリエンスの設計で説明されています。

  • 詳細については、Watch アプリを最新の状態に保つセッションで、コンプリケーション、アプリ、およびドックのスナップショットを最新の状態に保つために知っておく必要があるすべてのことをカバーしています。

于 2016-08-26T16:31:05.943 に答える