6

Androidアプリを実際のデバイスでテストしていますが、アプリを2〜3時間実行した後、一部のデバイスがときどき再起動することがあります。このアプリは、3つのスレッド（GPSとネットワークを使用）と2つのアクティビティを備えた1つのサービスで構成され、そのうちの1つはリソースを消費します（地図を表示します）

デバイスが再起動する前に重要なメッセージが表示されなかったため、Logcatは役に立ちませんでした。デバイスが起動しない場合もあります。バッテリーを取り外すだけで、デバイスを再起動できます。

デバイスはさまざまなハードウェアに基づいており、さまざまな国（主にPRC、hehe）で製造され、さまざまなAndroidバージョンを使用しています。

デバイスの再起動につながる可能性のある最も一般的な問題は何ですか？また、どのようにデバッグしますか？

4

4 に答える 4

3

Androidには2種類の再起動があります。

  1. システムサーバーの障害。その場合、再起動は発生しませんが、Zygote代わりに再起動します。一般的な理由：

    • ウォッチドッグは、実行中のサービスのデッドロックが原因でsystem_serverプロセスを強制終了しました。
    • システムサービスの1つで致命的な例外が発生しました。ただし、実際の理由はハードウェアの問題である場合があります。たとえば、工場出荷時のリセット後、ext2パーティションが次のようにフォーマットされない場合があります。エラーが発生し、/data/パーティションが読み取り専用としてマウントされるため、多数のエラーが発生します。
    • まれに、メモリとCPUの使用率が高いために、ウォッチドッグがタイムアウトになることがあります。

    どちらも非常にまれであり、実際のシナリオではなく、主にサルのテストで再現できます。service_managerを使用してプロセスを強制終了すると、logcat出力の例が表示される場合がありますadb shell。

  2. カーネルパニック。その場合、デバイスは実際に再起動します。Androidの境界のレイヤーでカーネルパニックが発生すると、logcat出力は生成されません。代わりに、スタックトレースをコンソールに書き込みます。/dev/kmsgADBシェルからまたはADBシェルから読み取ることができますadb shell dmesg。

    kmsg残念ながら、ほとんどのデバイスではコンソール出力が無効になっており、再起動するたびにバッファが消去されるため、これらを読み取るのは困難です。

PSまた、再起動はハードウェアの問題が原因である可能性があります。その場合、痕跡が見つかる可能性は低いですが、特定のデバイスでのみ再現できることを願っています。

于 2012-06-29T21:57:52.060 に答える
1

私は同様の問題を抱えていました（gpsとネットワークも）ネットワーク更新タイマーを本番環境（15分）に設定するのを忘れたので、デバイスが過熱した後、15秒ごとにデバイスが更新されました（htcdesire）
CPUを最小限に抑えてください使用法（プロファイリング）または適切な冷却メカニズムを確保する

于 2012-06-29T21:27:35.023 に答える
0

あなたが提供した情報から、あなたはおそらくリークしているようですThread。DDMSを使用して、アプリの実行過程でのスレッドの使用状況を分析できます。もう1つの可能性は、単にメモリが不足していることです...DDMSを使用してこれを支援することもできます。

于 2012-06-29T20:55:48.150 に答える
0

GPS受信機がオンになっている場合は、過熱の問題である可能性があります。GPSをオフにしてセルラーネットワークから位置情報を取得すると、アプリは何時間もスムーズに実行され続けます。

回答とアイデアをありがとうございました！

于 2012-07-02T04:52:14.840 に答える