3

最近グーグルはプッシュトゥデバイスサービスを導入しましたが、それは2.2以降でのみ利用可能です。

アプリに同様のシステムが必要ですが、制限を回避しようとしています。

問題はバッテリーの寿命です。サーバーの変更についてユーザーにすぐに通知する必要があるため、バックグラウンドで動作するサービス（標準のAndroidサービス）を実装し、サーバーに更新を照会することを考えました。

もちろん、サーバーにクエリを実行すると、1秒ごとでも、バッテリーだけでなく多くの帯域幅が必要になるため、私の質問は次のとおりです。サーバーが一定期間応答を保持している場合、違いはありますか？（Cometタイプのajaxリクエストの背後にある考え方）

このように動作します：

  • デバイスがデータ更新の要求を送信します
  • サーバーはリクエストを取得し、1分間ループに入り、各反復で更新があるかどうかを確認します
    • 更新がある場合、サーバーは更新とともに応答を送り返します
    • そうでない場合、サービスは次の反復に進みます。
  • 1分後、データがまだ利用できないという応答が最終的に送信されます。
  • 応答後（空であるかデータがあるかに関係なく）、Androidは別のそのようなリクエストを起動します。

確かに帯域幅のコストは低くなりますが、バッテリーの消費量は少なくなりますか（またはさらに多くなりますか？）

4

2 に答える 2

2

あなたが提案するようにTCPソケットを保持する（そして結果としてHTTP応答を待つ）ことはおそらくあなたの最良の選択肢になるでしょう。あなたが説明したことは、実際にはHTTP継続リクエストを介してすでに実装されています。HTTPプッシュ通知用のバイユープロトコルをご覧ください。また、ここでAndroidの実装を確認してください。 それが価値があるもののために、それは間違いなく私が使うものです。私はそれについて何の分析もしていませんが、これにより、接続をできるだけ長くハングさせることで、回線を介して送信されるデータの量（消費電力に正比例）を最小限に抑えることができます。

要するに、バイユーの仕組みはあなたが提案したものと非常に似ています。クライアントはリクエストを開き、サーバーはそれを待ちます。送信するものがある場合は送信し、それ以外の場合は単に待機します。最終的に、リクエストはタイムアウトします。その時点で、クライアントは別の要求を行います。達成できるのは、HTTPヘッダーなどの情報を絶えずポーリングしたり複製したりすることなく、サーバーからクライアントにほぼ瞬時にプッシュすることです。

于 2011-01-05T15:44:21.143 に答える
1

電話がネットワークを積極的に使用しているときは、バッテリーがより多く使用されます。つまり、要求を送信するときと応答を受信するときです。また、応答を聞くだけでバッテリーを使用します。しかし、電話はデータをダウンロードし、応答があるかどうかを確認しますか？それとも、電話はそれを受信するために開いているだけで、サーバーは応答を電話にプッシュしますか？それは主にそれが依存しているものです。電話が応答を受信するために開いているが、待機している間ずっと応答をダウンロードしようとしているときに実際にネットワークを使用しない場合は、バッテリーの使用量を減らす必要があります。

さらに、ネットワークを使用する限り、毎秒ではなく毎分クエリを送信する電話は、間違いなくバッテリーの使用量が少なくなります。ただし、電話をどのように保持するかによって異なります。非常に複雑なロジックと組み合わせて待機させると、バッテリーの寿命が短くなる可能性があります。しかし、おそらくそうではないでしょう、そして私はおそらくこれがあなたのためにうまくいくと思います。

最後に、それはバッテリーを助けるはずですが、そうでない方法でそれを作ることができます。プログラムを作成してから、ある種の変数（たとえば、WAIT_TIMEを1分ではなく1秒に変更）を変更して、バッテリーの使用量をテストすることは問題ありません。

于 2011-01-05T15:36:40.597 に答える