2

アプリケーション バックグラウンド サービスは、sqlite データベースを更新します。したがって、私の活動は時代遅れになっています。アクティビティ インテントには古いパラメーターも含まれているため、onCreate、onResume によってアプリケーションがクラッシュします。最も簡単な解決策は、アプリケーション全体を再起動することです。1 つの特殊なケースを処理するために、すべてのアクティビティのすべての onCreate、onResume メソッドに IF を追加したくありません。

例外が処理された後にACRAが次のコードを実行していることに気付きました。

android.os.Process.killProcess(android.os.Process.myPid());
System.exit(10);

ただし、多くの人は の使用を思いとどまらせますSystem.exit(0)。System.exit(0)Android アプリケーションのデータの整合性にとって本当に危険なのでしょうか? もちろん、私のコードは存在する前にデータベースを閉じます。

アップデート：

、コンテンツ プロバイダーの使用方法finish()、ブロードキャストの送信方法、SO で多くの回答を読む方法などを知っていました。ただし、これらの各アプローチには、さらに数千行のコードが必要です。System.exit(0)10分で解決策を実装しました。再起動は非常に高速であるため、通常の startActivity アクションと区別がつきません。データベースの更新/再起動は、ユーザーの非アクティブ状態が長くなった後に行われるため、アプリはシステムによって既に中断されています。私のアプリはリアルタイム同期を必要としません。テスト中、アプリケーションは正しく動作します。これは迅速で汚い解決策です。

そのため、副作用の可能性について質問しましたSystem.exit(0)。どうやってデザインを変えるかではありません。現在の設計が完璧ではないことは承知しています。

4

5 に答える 5

2

System.exit(0)Javaはランタイムからのアーティファクトであり、 Android. したがって、いずれにしてもそれを使用することは最悪の解決策になります。

Activity.finish()を優雅に使ってみませんか?

使用中のプロセスを終了すると、ほとんどのキャッシュが失われ、再起動時間 (ユーザーの目には ~resume) が失われ、次回はより長くなります。

詳細については、Android デベロッパーのアクティビティ ライフサイクル ドキュメントをご覧ください。

于 2013-09-06T12:38:37.647 に答える
1

プロセスを強制終了しても、プロセスの外部から登録されたリソースはクリーンアップされません。たとえば、BroadcastReceivers。これはリークであり、デバイスがそれを教えてくれます。

バックグラウンド サービスからデータベーススキーマを更新するべきではありません。あなたの活動が再開されたらそれをしてください。

データを更新するだけの場合、アクティビティを再開すると、インテントで指定されたデータが検証され、たとえばアイテム X がなくなったかどうかがユーザーに通知されます。

于 2013-09-06T12:39:19.617 に答える
0

したがって、私の活動は時代遅れになっています。

ContentProviderand ContentObserver(またはフレームワーク) を使用Loaderするか、メッセージ バス ( LocalBroadcastManager、Otto など) を使用して、その場でアクティビティを更新します。

アクティビティ インテントには古いパラメーターも含まれているため、onCreate、onResume はアプリケーションをクラッシュさせます

関連する「params」をアクティビティのデータ メンバーにコピーします。これらのデータ メンバーを必要に応じて更新します (たとえば、メッセージ バスで発生したイベントのハンドラーから)。構成変更のためのインスタンス状態の一部としてそのデータを保持します (例: onSaveInstanceState())。onCreate()、onResume()などからのこのデータを使用します。

最も簡単な解決策は、アプリケーション全体を再起動することです

ユーザーを大切にしている場合、ユーザーはアプリを使用している間に自然に蒸発することを評価しないため、簡単なことではありません。メールが届くたびに、Gmail が独自のアプリをクラッシュさせると思いますか?

次に、何らかのエクスプロイトを使用してブラウザーをクラッシュさせる Web アプリケーションを作成することを提案します。これは、Web ページを更新する方法がわからないためです。

例外が処理された後に ACRA が次のコードを実行していることに気付きました。

トップレベルの例外ハンドラは、この種のコードを持つ唯一の適切な場所であり、そこでさえ、このコードが決して実行されないようにする (つまり、未処理の例外を持たない) ことが目的です。

于 2013-09-06T12:49:33.943 に答える
0

慎重に、よく考え抜かれた特定の目的のために使用すれば、それほど危険なツールはありません。

System.exit()ただし、あなたの場合、それが正しい方法だとは思いません。アプリケーションがデータベースのデータに依存している場合は、アプリケーションに変更を通知し、データを更新するバックグラウンド サービス (必要に応じていくつか) を作成します。私の意見では、変更を処理する正しい方法です。

使用したいシナリオについては、System.exit()個人的には、重大なエラーから回復できず、グレースフル デグラデーションが不可能な場合に使用することがあります。このような場合は、アプリケーションに関連するすべてのリソースを強制的に停止する方が、絡み合ったままにしておくよりも適切です。明確にするために、根本的なことを行う前に、常にエラー処理を使用する必要があります。多くの場合、適切なエラー処理が有効です。

しかし、これは非常にデリケートなトピックであり、かなりの数の異なる回答を受け取る可能性があります。

于 2013-09-06T12:38:58.627 に答える
-1

System.Exit()の使用が悪いと人々が言う理由について、いくつかの助けになるかもしれない既存の回答がここにあります。

于 2013-09-06T12:38:02.470 に答える