2

問題は、スレッドをかなり長い間実行し続ける必要があり (実際には無期限で、1 分または数か月になる可能性があります)、1 ミリ秒ごとに約 1 回 UI を更新する必要があるということです...

ExecutorAsyncTaskHandlerおよびネイティブクラスがありThreadますが、この場合はどちらが適していますか?

の問題は、 がバックグラウンドで実行を開始してから 1 時間ほど後にAsyncTask破棄 (または ? から切り離され) され、ユーザーはいつでも に戻って、それが機能していないことを確認できることです (さらにはメモリ リークを引き起こします)。 )、別のアクティビティに変更したり、通知パネルをプルダウンしたりすると、UI が遅れます。ActivityActivityActivity

UI の更新が必要になるたびpost()にメソッドが呼び出されるため、Natural Threads はさらに遅延が大きくなります (約 1 ミリ秒ごとに進行状況を報告する必要があることを思い出してください)...TextView

tl:dr ミリ秒から数日、数週間、さらには数年まで測定できる長時間実行ストップウォッチを開発しています。これに最適なUI 集中型のスレッド化手法は何ですか?

手伝っていただけませんか?ありがとう!!

---編集:解決しました。システム リソースとアプリをバックグラウンドに移動する必要がありました。最初の時間と一時停止をバンドルとして保存し、アプリの再起動時にそれらをロードする必要がありました。みんなありがとう!

4

1 に答える 1

0

私は Android の専門家ではありませんが、AsyncTask がキャンセルされる理由は、バッテリー駆動の OS である OS が、長時間実行されるバックグラウンド タスクがバッテリー消費にとって悪いことであると判断しているためだと推測しています。

あなたのプログラムがバックグラウンド スレッドを何年も実行することは、ユーザーにとって大きな失望となるでしょう。時間測定を行う別の方法を見つけることをお勧めします。デバイスのリアルタイム クロックを使用することの何が問題になっていますか?

ミリ秒ごとに GUI を更新しようとしても、ほとんど意味がありません。いずれにせよ、OS はその速度で画面を更新するわけではなく、地球上のユーザーはいずれにせよ気付くことはありません。最大で 40 ミリ秒ごとに 1 回ふくらみます。

そして、精度の問題があります。Android モバイルのようなデバイスでミリ秒単位の精度で時間を数時間測定しようとしても意味がありません。放っておくと、時計と発振器は 1 日に数秒ずれます。最良のものはリアルタイムクロックですが、それでもかなり貧弱です (常にそうです)。Android はおそらく 1 日に 2 回 NTP の更新を行っているため、ローカル クロックが正確に近い時間帯が 1 日にわずかに発生します (ただし、それでもミリ秒単位の精度にはなりません)。

したがって、ミリ秒単位の精度で数か月にわたって時間を測定できたとしても、ユーザーに表示される回答は数秒も間違っていることになります。実際の経過時間から数分以内に到達できれば幸運です。

アプリケーションがフォアグラウンドにあるときにストップウォッチの表示を迅速に更新することが目的の場合は、リアルタイム クロックの読み取りをループして、ストップウォッチが開始されてからの時間を計算/表示します。バックグラウンドで何もする必要はありません。ただ寝てください。アプリが再びフォアグラウンドになると、ループが再開されます。デバイスのリアルタイム クロックは、アプリがスリープしている間ずっと時を刻んでおり、時差を計算して表示することができます。これは、バックグラウンド スレッドを長時間実行するよりもはるかに簡単であり、選択する他の方法よりも正確です (ただし、ミリ秒単位の精度ではありません)。

于 2013-07-28T06:25:22.303 に答える