Androidサーバ時間キャリブレーション

http://www.fanjun.me/?p=551
Androidサーバ時間とクライアント時間のキャリブレーション
Androidの時間はユーザーが調整し、時間の同期が必要になる場合があるため、サーバとの時間のキャリブレーションをどのように行うかは気持ち悪い問題かもしれません.
以前に考えられた比較的簡単な(ミリ秒単位)の手順は以下の通りである:1.サーバが1時間来て、サーバの現在の時間にほぼ等しく、s 1に設定する2.サーバを持って帰るときのローカル時間ミリ秒、c 1に設定する3.ローカル時間c 2の場合、サービスのキャリブレーション時間を取得する必要があり、s 1+(c 2-c 1)
に質問
ローカルの時間が途中でユーザーに修正された場合、c 2がc 1よりも小さい可能性がありますが、この場合は確かにお父さんです.
しかしAndroidは友好的で、ユーザーが時間を変更したり、タイムゾーンを変更したりしてもブロードキャストを送信する場合は、receiverを設定していくつかのブロードキャストを傍受し、サーバ時間を再設定することができます.

Intent.ACTION_TIME_CHANGED
Intent.ACTION_DATE_CHANGED

しかし,この放送があったとしても,ユーザがサーバを再引き取りする時間を除いてどのくらい修正したかは不明であるが,サーバ引き取りに失敗したり,サーバ引き取り時間のこの要求内にサーバ時間を使用する必要がある場合の処理は面倒である.
実は私たちがこんなに多くして、こんなに複雑なのは実は携帯電話のローカルの現在の時間とサーバーの時間を設定する時の絶対的な時間の差を知る必要があるだけです.
解決する
具体的な解決策はシステムが本当にこのような絶対的な時間を持っていることであり、これはユーザーが変更できないことであり、ユーザーが電源を入れた後にクロックを維持することである.それはSystemClock.elapsedRealtime()とSystemClock.elapsedRealtimeNanos()である.
ドキュメントがどのように書かれているかを見てみましょう.

>elapsedRealtime() and elapsedRealtimeNanos() return the time since the system was booted,
> and include deep sleep. This clock is guaranteed to be monotonic, and continues to tick
>even when the CPU is in power saving modes, so is the recommend basis for general purpose
> interval timing.

だから、このようにして、私たちはc 1とc 2を取るときにこの時間を使うと問題はありません.