だから... Android用のアプリを作っています。アプリケーションはリアルタイムチャットデータを送受信する必要があります(ソケットである必要があります)が、コマンドを送信する必要もあります(これは、クライアントが何かを送信していることを認識しないためです)。
ユーザーのバッテリーを節約するという観点から、より良い解決策を知る必要があります。
a)コマンドが送信されるたびに接続を開いたり閉じたりします。チャットタブが開いている場合は、接続を一定に保ちます。
b)接続を常に一定に保ちます。
私はインターネットを調べましたが、答えはまちまちです。持続的な接続を維持することはバッテリー寿命にとって悪いことであると言う人もいれば、そうではないと言う人もいます(例:) " TCP接続を開いたままにしておくと、バッテリーの寿命が長くなりますか?多分私はここでWAYをオフにしますが、接続を開いたままにしてもバッテリーの寿命を無駄にすることはありません...どこでその情報を入手したかを知るためです。音はSO私には奇妙です。 ")
または、より良い別の解決策がある場合。この状況でも、GoogleのC2DMが非常に役立つとは思いません。
基本的に、何がより多くのバッテリーを消耗します:持続的な接続を持っているか、チャットタブが開いていない限り接続を開いたり閉じたりしますか?
ありがとう!
アイドル状態を維持するTCPソケット接続を開いたまま(データの送受信なしで)は、閉じた状態よりも多くのバッテリーを消費しません(または、少なくともそうするべきではありません)。これは、アイドル= TCP接続は帯域幅またはCPUサイクルを使用しません(*)。
TCP接続はコンピュータと適切に対話しないため、TCP接続を長期間開いたままにしておくことは、モバイルデバイスにとって適切なオプションではない可能性があります。問題が発生するシナリオは次のとおりです。Androidユーザーが自分のAndroidデバイスをアプリの実行中にスリープ状態にしてから、リモートユーザーがプログラム(またはTCP接続のもう一方の端にあるもの)はTCPストリームを介してデータを送信します。リモートユーザーのプログラムはACKを取得しませんAndroidデバイス、もちろんAndroidデバイスはスリープ状態であるため、リモートデバイスのTCPスタックは、 TCP送信したパケットは失われているはずであり、タイムアウト期間を増やして応答し、TCPウィンドウサイズ(別名-TCPパケット数- allowed-in-flight-at-once)、およびTCPパケットを再送信します。しかし、Androidデバイスはまだスリープ状態であるため、同じことがag ain。その結果、数分後、TCP接続のリモートエンドが遅くなり、Androidデバイスがウェイクアップすることになった、TCP接続が遅くなりすぎて使用できない可能性があります-この時点で、プログラムは行き詰まった接続を閉じ、TCP接続を開始する必要があります。とにかく新鮮なものなので、なぜわざわざそれを開いたままにしようとするのですか?
したがって、私の推奨事項は、オプション(a)を使用することです。TCP接続を、デバイスがis-going-to-sleep-nowルーチンの一部として閉じることを条件としています。
AndroidにTCP接続を開いたままにしておくと、WiFiまたはセルネットワークハードウェアが電源投入されたままの状態になる場合に、それ以外の場合はスリープ状態にすることができます-その場合、Androidデバイスはアンテナに電力を供給するためのバッテリーコストを支払いますが、そうでなければそれを支払う必要はありませんでした。私はAndroidロジックは認識していませんが、私はAndroidを少ししか使用していないので、私の部分では無知かもしれません。少なくとも、テストする価値があります。
(*)まあ、技術的にTCPは、TCP接続が開いている間、「キープアライブ」パケットを時々送信しますが、これはいくつかのCPUサイクルとアンテナ電力...しかし、キープアライブパケットを送信するためのデフォルトの間隔はAndroidは 2時間 なので、そのために使用された電力は顕著ではないでしょうか。
Androidデバイスとサーバーの間のステートフルルーターは比較的後に接続を忘れます)短い時間。
どちらが良いかは、サーバーに接続する必要なく、どれだけの時間を費やすかによって異なります。とにかく、30秒に1回程度接続している場合は、ほとんど常に接続を開いたままにしておきます。開いていない場合は、閉じた方がよい場合があります。
バッテリーは、3GのDCH/FACH/IDLEからの無線状態遷移に非常に関連しています。エネルギー効率の高いアプリが必要な場合は、永続的な接続に関係なく、限られた時間間隔でできるだけ多くのデータを送信する必要があります...