Androidアプリケーションでsystem.exit(0)を使用することは推奨されていないことは知っていますが、その時点でアプリケーションを強制終了できるので、onDestroy()で使用しても大丈夫かどうか疑問に思いました。
私が尋ねている理由は、この質問に関連しています。
Androidアプリケーションでsystem.exit(0)を使用することは推奨されていないことは知っていますが、その時点でアプリケーションを強制終了できるので、onDestroy()で使用しても大丈夫かどうか疑問に思いました。
私が尋ねている理由は、この質問に関連しています。
onDestroy
呼び出されることに依存しないでください。OSがを呼び出さずにアプリケーションを強制終了する状況がありますonDestroy
。もちろん、シナリオに直接当てはまらないので、一言アドバイスします。アプリがすでに強制終了されているために呼び出されなかった場合system.exit(0)
は、大丈夫だと思います。;-)
Activity.onDestroy
、それはプロセスが2つの状態のいずれかにあることを意味します。--OSが認識しているアプリで実行されている他のコンポーネント(Service
または)はありません。ContentProvider
これは、プロセスがOSによってすぐに強制終了される可能性が高いこと、またはシステムの他の部分や他のアプリが物理メモリを必要とする場合に最初に再利用されることを意味します。したがって、呼び出しexit(0)
はあまり達成されません。
-システムが認識しているプロセスで実行されている別のコンポーネントがあります。この場合に呼び出すexit()
と、プロセスが終了し、他のコンポーネントが強制終了され、データが破損する可能性があります。もちろん、OSはそれほど気にしないかもしれませんが、ユーザーはそれを高く評価しないかもしれません。:-)
Dalvikヒープ制限はOEMで構成可能ですが、実際にデバイスに合わせて調整する努力をしているOEMはほとんどなく、OSのデフォルトを使用しています。特定のデフォルトは覚えていませんが、各アプリはローエンドのフローズンヨーグルト/ジンジャーブレッドで16MBからハイエンドのICS/JB電話で48MBまで許可されていると考えて間違いありません。ちなみに、私は楽観的で、上限を128MBに上げます(そのようなデバイスについてはまだ聞いたことがありませんが)。:-)
ContentProvider
またはをスローした瞬間、(前述のように)もうService
呼び出す余裕がなく、問題を適切に解決する必要があります。exit()
弾丸を噛んで今すぐやったほうがいいでしょう。Bitmap.recycle()
最も簡単なアプローチは、特定のビットマップを使い終わったときに確実に呼び出しを行うことです。もちろん、メモリよりも多くのビットマップをメモリに保持する必要がない限り、これは機能しますが、とにかく、それは完全に別の獣です。:-)sytem.exit(0)を呼び出さないでください。Androidにアプリケーションを管理させてください。メモリリークの問題があることを理解している場合。ビットマップのせいだと思います。したがって、ビットマップを効率的に表示するためにこれを見てくださいhttp://developer.android.com/training/displaying-bitmaps/index.html
onDestroy()メソッドでsystem.exit(0)を呼び出すと、横向きと縦向きを切り替えることができなくなります。
ショートカットソリューション:アプリの使用が終了したら、アクティビティでSystem.exit(0)ではなくfinish()を呼び出します。
適切な方法は、アプリでのビットマップの使用を最適化することです。こちら
のhttp://developer.android.com/training/displaying-bitmaps/index.htmlをご覧ください
次のようなオプションを確認することをお勧めします:http: //developer.android.com/reference/android/app/Application.html#onLowMemory%28%29