アプリケーションを終了すると、眉をひそめますか？

Androidを学ぶための私の試みに移って、私は以下を読むだけです：

質問：アプリケーションを強制終了するメニューオプションを配置しない限り、ユーザーはアプリケーションを強制終了することはできますか？そのようなオプションが存在しない場合、ユーザーはどのようにアプリケーションを終了しますか？

回答：（Romain Guy）：ユーザーは処理しません。システムがこれを自動的に処理します。これがアクティビティのライフサイクル（特にonPause / onStop / onDestroy）の目的です。何をする場合でも、「終了」または「終了」アプリケーションボタンを配置しないでください。Androidのアプリケーションモデルでは役に立たない。これは、コアアプリケーションの動作にも逆です。

へへ、私がAndroidの世界で取るすべてのステップで、ある種の問題にぶつかります=（

どうやら、Androidでアプリケーションを終了することはできません（ただし、Androidシステムは、アプリが気になったらいつでも完全に完全に破棄できます）。どうしたの？「通常のアプリ」として機能するアプリを作成することは不可能だとユーザーは思い始めています。ユーザーがアプリを終了すると、アプリを終了できるのです。これは、OSに依存すべきではありません。

私が作成しようとしているアプリケーションは、Androidマーケット用のアプリケーションではありません。一般の方が「広く利用」できるアプリではなく、非常に狭いビジネス分野で利用されるビジネスアプリです。

Androidプラットフォーム向けの開発は、Windows Mobileと.NETに存在する多くの問題に対処しているので、本当に楽しみでした。しかし、先週は私にとってはややオフになっています...私はAndroidを放棄する必要がないことを願っていますが、今はあまりよく見えません=（

アプリケーションを本当に終了する方法はありますか？

これは最終的にあなたの質問に到達しますが、私は最初に、この執筆時点ですでに与えられているさまざまな回答に対するさまざまなコメントで提起するいくつかの問題に対処したいと思います。私はあなたの考えを変えるつもりはありません。むしろ、これらは将来この投稿を読むようになる他の人のためにここにあります。

重要なのは、アプリがいつ終了するかをAndroidが判断できないようにすることです。それはユーザーの選択でなければなりません。

何百万もの人々が、環境が必要に応じてアプリケーションを閉じるモデルに完全に満足しています。これらのユーザーは、Androidアプリの「終了」については考えていません。Webページの「終了」またはサーモスタットの「終了」について考えている以上のことはありません。

多くのiPhoneアプリは、アプリが実際にシャットダウンされている場合でも、ユーザーが中断したところをピックアップするため、iPhoneユーザーはほとんど同じです。現在、一度に1つのサードパーティアプリを使用できます）。

上記で述べたように、私のアプリでは多くのことが行われています（データがデバイスにプッシュされている、常にそこにあるべきタスクのリストなど）。

「常にそこにあるべきタスクのリスト」の意味はわかりませんが、「デバイスにプッシュされるデータ」は楽しいフィクションであり、どのような場合でもアクティビティによって行われるべきではありません。スケジュールされたタスクを使用して（を介してAlarmManager）、信頼性を最大にするためにデータを更新します。

ユーザーがログインすると、電話がかかってきてAndroidがアプリを強制終了することを決定するたびに、ログインを行うことができなくなります。

これを処理する多くのiPhoneおよびAndroidアプリケーションがあります。通常は、ユーザーに手動でログインするように強制するのではなく、ログオン資格情報を保持するためです。

たとえば、アプリケーションを終了するときに更新を確認します

これは、どのオペレーティングシステムでも間違いです。ご存じのとおり、アプリケーションが「終了」している理由は、OSがシャットダウンしているため、更新プロセスが途中で失敗するためです。一般的に、それは良いことではありません。開始時に更新を確認するか、完全に非同期に（たとえば、スケジュールされたタスクを介して）更新を確認し、終了時は確認しません。

一部のコメントは、戻るボタンを押してもアプリがまったく終了しないことを示唆しています（上記の私の質問のリンクを参照）。

戻るボタンを押しても「アプリを終了」することはありません。ユーザーが[戻る]ボタンを押したときに画面に表示されていたアクティビティを終了します。

ユーザーが終了したい場合にのみ終了する必要があります-他の方法で終了することはありません。Androidでそのような動作をするアプリを作成できない場合、Androidは実際のアプリの作成には使用できないと思います=（

次に、Webアプリケーションもできません。または、WebOS（モデルを正しく理解している場合（まだモデルを使用する機会がなかった場合））。これらすべてにおいて、ユーザーは何も「終了」せず、そのままにしておくだけです。iPhoneは少し異なります。現在のところ、一度に実行できるのは1つだけです（いくつかの例外はあります）。そのため、離脱すると、アプリがすぐに終了します。

アプリケーションを本当に終了する方法はありますか？

他の誰もが言ったように、ユーザー（BACK経由）またはコード（経由finish()）は、現在実行中のアクティビティを閉じることができます。ユーザーは通常、適切に作成されたアプリケーションについては、Webアプリケーションを使用するための「終了」オプションが必要とする以上のものは何も必要としません。

定義上、2つのアプリケーション環境が同じになることはありません。つまり、新しい環境が発生し、他の環境が埋没するにつれて、環境の傾向を確認できます。

たとえば、「ファイル」の概念を排除しようとする動きが高まっています。ほとんどのWebアプリケーションは、ユーザーにファイルを考えさせることを強制しません。iPhoneアプリは通常、ユーザーにファイルのことを考えさせません。Androidアプリは通常、ユーザーにファイルを思い込ませません。等々。

同様に、アプリを「終了」するという概念を排除しようとする動きが高まっています。ほとんどのWebアプリケーションは、ユーザーに強制的にログアウトさせるのではなく、一定時間操作がないと暗黙的にユーザーをログアウトさせます。Androidでも同じですが、iPhone（および場合によってはWebOS）でも同様です。

これには、ビジネス目標に焦点を当て、以前のアプリケーション環境に関連付けられた実装モデルに固執しないで、アプリケーション設計をさらに強調する必要があります。これを行う時間や傾向がない開発者は、既存のメンタルモデルを破壊する新しい環境に苛立ちます。これは、どちらの環境の障害でもありません。山を通過するのではなく、その周りを嵐が流れるための山の障害です。

たとえば、HypercardやSmalltalk などの一部の開発環境では、アプリケーションと開発ツールが1つのセットアップに混在しています。この概念は、（例えば、アプリケーションに言語拡張のあまり、外側にキャッチしていないVBAでエクセル、AutoCADでのLisp）。そのため、アプリ自体に開発ツールの存在を想定したメンタルモデルを思いついた開発者は、モデルを変更するか、モデルが成り立つ環境に限定する必要がありました。

だから、あなたが書くとき：

私が発見した他の厄介なことに加えて、私はAndroid用のアプリを開発することは起こらないと思います。

それは今のところ、あなたにとって、最高のことだと思われます。同様に、Androidで報告したのと同じ問題のいくつかがWebアプリケーションでも見つかる（たとえば、「終了」がない）ため、アプリケーションをWebに移植しようとしないように助言します。それとも、あなたは逆に、いつかあれば行うポートWebにあなたのアプリケーションを、Webアプリケーションのフローは、Androidのためのより良い試合になることを見つけることが、あなたはその時点でのAndroidのポートを再訪することができます。

このスレッドの将来の読者のために、ここに修正を加えたいと思います。この特定のニュアンスは長い間私の理解を免れてきたので、私はあなたの誰もが同じ間違いを犯さないようにしたいと思います：

System.exit()スタックに複数のアクティビティがある場合、アプリは強制終了されません。 実際に起こるのは、プロセスが強制終了され、スタック上のアクティビティが1つ少なくなるとすぐに再起動されることです。これは、アプリが強制終了ダイアログによって強制終了されたとき、またはDDMSからプロセスを強制終了しようとしたときにも起こります。これは、私の知る限り、完全に文書化されていない事実です。

簡単に言えば、アプリケーションを終了する場合は、スタック内のすべてのアクティビティとfinish()、ユーザーが終了したいときにすべてのアクティビティを追跡する必要があります（いいえ、アクティビティスタックを反復処理する方法はありません） 、そのため、このすべてを自分で管理する必要があります）。これでも、実際にプロセスやぶら下がっている参照を強制終了することはありません。単にアクティビティを終了します。また、Process.killProcess(Process.myPid())うまく機能するかどうかはわかりません。私はそれをテストしていません。

一方、スタックにアクティビティを残しても問題ない場合はActivity.moveTaskToBack(true)、処理を非常に簡単にする別の方法があります。単にプロセスをバックグラウンドにしてホーム画面を表示するだけです。

長い答えには、この行動の背後にある哲学の説明が含まれます。哲学は多くの仮定から生まれました：

1. まず、これはアプリがフォアグラウンドにある場合にのみ発生します。バックグラウンドにある場合、プロセスは正常に終了します。ただし、それがフォアグラウンドにある場合、OSはユーザーが自分のやっていることを何でもやり続けたいと考えます。（DDMSからプロセスを強制終了する場合は、まずホームボタンを押してから強制終了する必要があります）
2. また、各アクティビティは他のすべてのアクティビティから独立していると想定しています。これは多くの場合、たとえば、アプリがブラウザアクティビティを起動する場合に当てはまります。これは完全に独立しており、ユーザーが作成したものではありません。ブラウザアクティビティは、そのマニフェスト属性に応じて、同じタスクで作成される場合と作成されない場合があります。
3. それはあなたの活動のそれぞれが完全に自立していて、すぐに殺される/回復できると想定しています。（私はこの特定の仮定が嫌いです。私のアプリには大量のキャッシュデータに依存する多くのアクティビティがあり、サイズが大きすぎての間に効率的にシリアル化onSaveInstanceStateできないためですが、よくできているAndroidアプリの場合、これは当てはまります。あなたのアプリがいつバックグラウンドで終了するのかわからないからです。
4. 最後の要因はそれほど仮定ではなく、OSの制限 です。アプリを明示的に強制終了することは、アプリがクラッシュすることと同じであり、Androidがアプリを強制終了してメモリを解放することと同じです。 これは私たちのクーデターグレイスで頂点に達します。Androidは、アプリが終了したか、クラッシュしたか、バックグラウンドで強制終了されたかを判別できないため、ユーザーが中断したところに戻ることを望んでいると想定し、ActivityManagerがプロセスを再起動します。

考えてみると、これはプラットフォームに適しています。まず、これは、プロセスがバックグラウンドで強制終了され、ユーザーがプロセスに戻ったときにまさに何が起こるかです。そのため、中断したところから再起動する必要があります。2つ目は、アプリがクラッシュし、恐ろしい強制終了ダイアログが表示された場合です。

ユーザーが写真を撮ってアップロードできるようにしたいとします。アクティビティからカメラアクティビティを起動し、画像を返すように要求します。カメラは（独自のタスクで作成されるのではなく）現在のタスクの一番上にプッシュされます。カメラにエラーがあり、クラッシュした場合、アプリ全体がクラッシュする必要がありますか？ユーザーの観点からは、カメラのみが失敗し、以前のアクティビティに戻す必要があります。したがって、スタック内のすべての同じアクティビティからカメラを除いて、プロセスを再起動するだけです。アクティビティは帽子をかぶったときに殺して復元できるように設計する必要があるため、これは問題になりません。それはとても残念ながら、すべてのアプリケーションは、そのように設計することができないですロマンガイや他の誰かがあなたに何を言っても、私たちの多くにとって問題です。したがって、回避策を使用する必要があります。

だから、私の最後のアドバイス：

• プロセスを強制終了しないでください。どちらの呼び出しfinish()すべての活動やコールでmoveTaskToBack(true)。
• プロセスがクラッシュまたは強制終了した場合、そして私のように、現在失われているメモリ内のデータが必要な場合は、ルートアクティビティに戻る必要があります。これを行うにstartActivity()は、Intent.FLAG_ACTIVITY_CLEAR_TOPフラグを含むインテントで呼び出す必要があります。
• Eclipse DDMSの観点からアプリを強制終了する場合は、フォアグラウンドに置かないようにしてください。そうしないと、再起動します。あなたは最初のホームボタンを押して、必要があり、その後のプロセスを殺します。

すべてのアプリケーションに終了ボタンがあります。そのため、ユーザーから肯定的なコメントを頻繁に受け取ります。アプリケーションが必要としないような方法でプラットフォームが設​​計されているかどうかは気にしません。「そこに置かないで」と言うのは、とんでもないことです。ユーザーが終了したい場合...私は彼らにそれを行うためのアクセスを提供します。私はそれがAndroidの動作をまったく低下させないと思い、良い習慣のように思えます。私はライフサイクルを理解しています...そして私の観察では、Androidはそれを処理するのに良い仕事をしていません......そしてそれは基本的な事実です。

アプリケーションをモノリシックアプリケーションとして考えるのをやめます。これは、ユーザーが「アプリケーション」やAndroidサービスを介して提供される「機能」を操作できる一連のUI画面です。

神秘的なアプリが「何をする」かを知らなくても、それほど重要ではありません。非常に安全な企業のイントラネットにトンネルし、監視や対話を実行し、ユーザーが「アプリケーションを終了」するまでログインしたままであるとします。IT部門が指示するため、ユーザーはイントラネットの内部または外部にいるときは非常に意識している必要があります。したがって、ユーザーが「終了」することが重要であるというあなたの考え方。

これは簡単です。通知バーに「イントラネットにいる、または実行している」と継続的に通知するサービスを作成します。そのサービスに、アプリケーションに必要なすべての機能を実行させます。ユーザーが「アプリケーション」とのやり取りに必要なUIのビットにアクセスできるように、そのサービスにバインドするアクティビティを用意します。また、Androidメニュー-> [終了]（またはログアウトなど）ボタンを押して、サービスを終了し、アクティビティ自体を閉じます。

これは、すべての意図と目的のために、まさにあなたが望んでいることです。Androidのやり方を実行しました。この「出口」の例として考えられる可能性については、GoogleトークまたはGoogleマップナビゲーションをご覧ください。唯一の違いは、ユーザーがアプリケーションを復活させたい場合に備えて、アクティビティから[戻る]ボタンを押すと、UNIXプロセスが待機する可能性があることです。これは、最近アクセスしたファイルをメモリにキャッシュする最新のオペレーティングシステムとまったく同じです。Windowsプログラムを終了した後、必要とされた可能性が最も高いリソースはまだメモリ内にあり、他のリソースがロードされているため、不要になったため、他のリソースに置き換えられるのを待っています。Androidも同じです。

あなたの問題は本当にわかりません。

これは非常に多くの専門家が貢献している興味深い洞察に満ちた議論です。この投稿はAndroid OSのコアデザインの1つを中心に展開しているため、Android開発のメインWebサイト内からループバックする必要があると思います。

ここに2セントも加算したいと思います。

これまでのところ、Androidのライフサイクルイベントの処理方法に感銘を受け、ネイティブアプリにWebのようなエクスペリエンスのコンセプトをもたらしました。

とは言っても、Quitボタンがあるべきだと私はまだ信じています。どうして？...私やTed、またはここにいる技術の達人ではなく、エンドユーザーの要求を満たすことのみを目的としています。

私はWindowsの大ファンではありませんが、長い間、ほとんどのエンドユーザーが慣れている（Xボタン）という概念を導入しました。

これは、誰か（OS、開発者？）が独自の裁量で処理することを意味するわけではありません...それは単に「慣れている私の赤いXボタンはどこにあるのか」を意味します。私の行動は、「ボタンを押すと通話を終了する」、「ボタンを押してデバイスの電源を切る」などに似ているはずです...それは知覚です。それは私の行動が実際にその目的を達成すること自体に満足をもたらします。

開発者はここで与えられた提案を使用してこの動作を偽装することができますが、認識はまだ残っています。つまり、アプリケーションは、エンドユーザーからの要求に応じて、独立した信頼できるニュートラルソース（OS）によって（今は）完全に機能を停止する必要があります。

あなたはでき押すことによっていずれか、終了Backボタンをか呼び出すことでfinish()、あなたにActivity。明示的に終了したい場合finish()は、から呼び出してMenuItemください。

Romainは、それが無意味だというだけで、それを実行できないとは言っていません。ユーザーは、アプリケーションのライフサイクルが機能する方法によって、自動的に保存および何が起こってもその状態を復元します。

この議論は、開発者が最もよく知っているのか、それともユーザーが最もよく知っているのかという昔からの疑問に要約されます。ヒューマンファクターのあらゆる分野のプロのデザイナーが、毎日これに苦労しています。

テッドは、市場で最もダウンロードされたアプリの1つが「アプリキラー」であることを指摘しました。アプリケーションを終了すると、人々は少し余分なセロトニンを摂取します。彼らはデスクトップ/ラップトップでそれに慣れています。それは物事を速く動かし続けます。プロセッサーを冷却し、ファンがオンにならないようにします。消費電力が少なくなります。

モバイルデバイスがはるかに小型の船であると考えると、「不要になったものを船外に捨てる」という彼らのインセンティブに特に感謝することができます。現在、Androidの開発者たちは、OSが最もよく知っており、アプリを終了することは骨董品であると推論しています。私はこれを心からサポートします。

ただし、ユーザーの不満が自分の無知から生まれたとしても、ユーザーを不満にすべきではないと私は思います。そのため、ビューを閉じる以外に何もしないプラセボボタンであっても、「終了」オプションを使用することは良いデザインであると私は結論付けています。

テッド、あなたが達成しようとしていることは、おそらくあなたが今それをどう考えているのかではなく、実行することができます。

アクティビティとサービスを読むことをお勧めします。「アプリ」という用語の使用をやめ、コンポーネント、つまりアクティビティ、サービスの参照を開始します。Androidプラットフォームについてもっと学ぶ必要があると思います。それは、標準的なPCアプリからの考え方の変化です。あなたの投稿に「アクティビティ」という単語（FAQの引用にない、つまりあなたの単語ではない）が含まれていないという事実から、さらに読む必要があることがわかります。

ブログ投稿Androidアプリに終了ボタンを含めるタイミング（ヒント：なし）は、私ができるよりはるかに優れています。私はすべてのAndroid開発者がそれをすでに読んでいることを望みます。

抜粋：

私の経験では、[ユーザー]が本当に望んでいる ことは、アプリがリソース（バッテリー、CPUサイクル、データ転送など）の消費を停止することを保証する明確な方法です。

多くのユーザーは、終了ボタンがこの要件を実装していることを認識し、追加するように求めています。開発者は、ユーザーを喜ばせたいと考えて、必然的に1つ追加します。その後まもなく、どちらも失敗します。

• ほとんどの場合、終了ボタンは単にを呼び出しますActivity.finish()。これは、戻るボタンを押すのとまったく同じです。 丁度。 サービスは実行し続け、ポーリングは継続して行われます。ユーザーはアプリを殺したと思っているかもしれませんが、殺していないため、すぐにさらに迷惑になります。
• 出口の動作があいまいです。終了ボタンでアクティビティを閉じるだけにする必要がありますか、それとも関連するすべてのサービス、レシーバー、およびアラームを停止する必要がありますか？何をすべきBackか Home代わりにヒットするとどうなりますか？アプリにウィジェットがある場合はどうなりますか？終了ボタンで更新も停止する必要がありますか？

解決策は、戻るボタンが期待どおりに動作するようにすることです。さらに良いのは、アプリが表示されていないときにリソースの消費を停止することです。

先に進んで、記事全体を読んでください。

回答：（Romain Guy）：ユーザーは処理しません。システムがこれを自動的に処理します。それがアクティビティのライフサイクル（特にonPause / onStop / onDestroy）の目的です。何をする場合でも、「終了」または「終了」アプリケーションボタンを配置しないでください。Androidのアプリケーションモデルでは役に立たない。これは、コアアプリケーションの動作にも逆です。

1：アプリケーションを完全に終了することは、通常は必須ではないかもしれませんが、役に立たないわけではありません。ウィンドウに終了オプションがない場合はどうなりますか？メモリがいっぱいになり、OSがどのプログラムで処理したかを推測しなければならないため、システムの処理速度は遅くなります。Romain Guyや、Larry PageやSergey Brinが何を言っているかは気にしません。これらは疑いのない事実です。新しいアプリを起動する前にメモリを取得するためにタスクを強制終了しなければならない場合、システムの実行速度は遅くなります。アプリを強制終了するのに時間がかからないとは言えません！遠くの星からの光でさえも時間がかかります... ユーザーがアプリを完全に閉じることを許可することにはいくつかの用途があります。

2：コアアプリケーションの動作に反していますか？それはどういう意味ですか？私が今のところアプリを実行し終えたとき、それはもはや何の仕事もしていない...それは、そのメモリが必要とされるとき、OSによって殺されるのを待っているだけです。

要約すると、最小化と終了には明確な違いがあり、どちらもピンチヒットがうまく機能しません。すべてのネジにドライバーを残しますか？またはすべてのドアの鍵？ブレーカーが吹くまで別のアプライアンスをオンにする必要があるまで、すべてのアプライアンスを高いままにしますか？食器洗い機に食器をいっぱいにして、新しい汚れたもののためのスペースを作るのに十分なだけ毎回取り出すのですか？私たちが私道まで走っている車をすべてそのままにしますか？

ユーザーがアプリを最小化したい場合、最善の方法はアプリを最小化することです。ユーザーがアプリを終了する場合は、必ず終了するのが最善です。

眉をひそめていますか？それはAndroidの見解です-彼らはそれに眉をひそめています。そして、多くの独立した新人Android開発者がそれに眉をひそめています。

しかし、それには、良いコーディングと悪いコーディングがあります。良いプログラムフローモデルと悪いプログラムフローモデルがあります。

ユーザーがプログラムを使い終わったことをユーザーが知っているときに、プログラムをメモリに残しておくのは、プログラムの流れとしては適切ではありません。まったく目的がなく、新しいアプリを起動したり、実行中のアプリがより多くのメモリを割り当てたりすると、動作が遅くなります。

自動車のようなものです。ストップライトで停止したり、ファストフードドライブを通過したり、ATMで停止したりするなど、車を走らせたままにする場合があります。しかし、あなたがそれをシャットオフしたい他の状況があります-あなたが仕事に着いたとき、または食料品店や家さえです。

同様に、ゲームをプレイしているときに電話が鳴った場合も同様です。ゲームを一時停止し、実行し続けます。ただし、ユーザーがしばらくゲームを終了した場合は、必ずユーザーを終了させて​​ください。

一部のアプリケーションの終了ボタンは、他のアプリケーションよりも前面に表示されます。たとえば、ゲーム、またはユーザーが完全に終了する可能性が高いプログラムには、明確な終了が必要です。（おそらくメールをチェックし続けることができるように）終了があまり望めない、おそらく電子メールプログラムのような他のプログラム-これらのプログラムは、終了オプションを使用して主要な制御入力画面スペースを無駄にすべきではありませんが、良好なプログラムフローのためには、終了オプションが必要です。誰かがカバレッジエリアが悪いときや、Skype通話などでメールプログラムがメールをチェックしたくないと決めた場合はどうなりますか？必要に応じて、メールプログラムを終了させます。

一時停止と終了は2つの重要なタスクであり、どちらも他方の役割を果たしません。

問題は、バグのあるソフトウェアがない限り、アプリを終了する必要はないということです。Androidは、ユーザーがアプリを使用していないときにアプリを終了し、デバイスがより多くのメモリを必要とします。バックグラウンドでサービスを実行する必要があるアプリがある場合、サービスをオフにする方法が必要になる可能性があります。

たとえば、アプリが表示されていない場合でも、Google Listenはポッドキャストを再生し続けます。しかし、ユーザーがポッドキャストを使い終わったら、ポッドキャストをオフにするための一時停止ボタンが常にあります。私が正しく覚えている場合、Listenは通知バーにショートカットを配置しているので、いつでも一時停止ボタンにすばやく移動できます。別の例としては、インターネット上のサービスを絶えずポーリングするTwitterアプリなどのアプリがあります。これらの種類のアプリでは、サーバーをポーリングする頻度、またはバックグラウンドスレッドでポーリングするかどうかをユーザーが実際に選択できるようにする必要があります。

終了時に実行するコードが必要な場合は、必要に応じてonPause（）、onStop（）、またはonDestroy（）をオーバーライドできます。 http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

データ/接続（および「アプリケーション」）を永続化する方法を理解できない場合、Androidで「必要な」ことを行うことができなくなります。

これらのかわいらしい小さなアプリキラーをダウンロードする人は、通常、バッテリーの寿命やメモリの使用には役立ちませんが、OSがメモリを効率的に管理するのを妨げます...

http://android-developers.blogspot.com/2010/04/multitasking-android-way.html

Addison-Wesleyが発行している「Android Wireless Application Development」を読んでみてください。私はちょうどそれを仕上げています、そしてそれは非常に徹底しています。

Androidプラットフォームに関するいくつかの根本的な誤解があるようです。私も最初はAndroidアプリのアプリケーションライフサイクルに少し不満を感じていましたが、理解が深まり、このアプローチを本当に楽しむようになりました。この本はあなたの質問のすべてとはるかに答えます。それは本当に私が新しいAndroid開発者のために見つけた最高のリソースです。

また、既存のアプリのラインごとの移植を手放す必要があると思います。アプリケーションをAndroidプラットフォームに移植するために、アプリケーションの設計の一部が変更されます。モバイルデバイスはデスクトップシステムに比べてリソースが非常に限られており、Androidデバイスが複数のアプリケーションを整然としたリソース認識方式で実行できるようにするため、使用されるアプリケーションライフサイクルが必要です。プラットフォームについてさらに深く調べてみてください。そうすれば、自分がやりたいことが完全に実現可能であることに気付くでしょう。幸運を祈ります。

ちなみに、私はAddison-Wesleyやこの本に関連する人物や組織とは何の関係もありません。私の投稿をもう一度読んだ後、私は少しファンボーイっぽくなったように感じました。私は本当に本当に本当に楽しんで、それが非常に役に立ったと感じました。:)

ほぼ99％の時間で、Androidアプリケーションが自身のライフサイクルを引き継ぐ必要はありません。ほとんどの場合、それはアプリケーションのより良い計画またはよりスマートな設計に帰着します。たとえば、ダウンロードなどを処理する内部サービス（エクスポートされない）を構築するか、ユーザーワークフローに関連するアクションとタスクを設計します。

しかし、言われていることには、意志があるところに道があります。Androidが提供する-android.os.Processクラスを介して、基盤となるプロセスを制御するためのJavaよりもはるかに優れたAPI。そして、Javaとは異なり、単純なjava.lang.System.exit（）呼び出しの背後にすべてを隠すことで、開発者をmoronのように扱いません。

では、Androidでアプリケーションに自殺を依頼するにはどうすればよいでしょうか。まあ、トリックは簡単です：

標準のandroid.app.Applicationクラスから継承して、独自のAndroidアプリケーションクラスを作成します（AndroidManifest.xmlファイルで宣言することを忘れないでください）。

onCreate（）メソッドをオーバーライドし、アプリケーションを起動したプロセスIDを保存します。

this.pid = android.os.Process.myPid(); // Save for later use.

アプリケーションを強制終了するには、kill（）メソッドを提供します。

android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);

アプリが自殺する必要があるときはいつでも、アプリケーションコンテキストを型キャストし、killメソッドを呼び出します

((MySuicidalApp) context.getApplicationContext()).kill()

特にサービスに関連するAndroidのプロセス管理ポリシーにより、Androidはサービスの再起動を選択する場合があることを覚えておいてください（Androidでタスクキラーを使用しないでください）。

Androidでアプリケーションを考案すると、次のように見えます。

• アプリケーションで作業しています
• 電話が鳴りました
• あなたは電話に出る
• 通話の最後に、以前と同じ場所でアプリケーションに戻ります。

そのためには、BackボタンまたはHome電話のボタン（短押しまたは長押し）と通知バーのみが必要です。

アプリケーションを終了するときはBack、Homeボタンまたはボタンがなくなるまでボタンを使用します。

これが、ほとんどのアプリケーションが考えられる方法だと思います。しかし、何らかのセッションや接続が必要な場合は、ログイン/ログアウトボタンと通知（タイトルバーなど）を使用してユーザーに明確に示しました。これは、純粋な「exit」スタイルのアプリケーションとはかなり異なるスタイルです。

PCにはマルチGUIデスクトップがあり、Androidには明らかにマルチタスクがありますが、一度に1つのアプリしか表示しません（ここではウィジェットは考慮しません^^）。また、携帯電話では、いつでも、自分がしていることよりも重要なことについて通知を受けることができます。

したがって、アプリケーションの全体的な概念は、「アプリケーションに入る-仕事-アプリケーションの終了」とは異なる何かに依存しています。

うーん...

Androidアプリが正しい方法で表示されていないだけだと思います。あなたはあなたが望むものとほぼ同じようなことを簡単に行うことができます：

• 開発者のライフサイクルのドキュメントで推奨されているように、アプリアクティビティで状態を保存/復元します。

• 復元段階でログインが必要な場合（ログイン/セッション情報が利用できない場合）、それを実行します。

• 最終的にボタン/メニュー/タイムアウトを追加します。この場合finish()、ログインやその他のセッション情報を保存せずにを実行し、暗黙的にアプリセッションを終了します。そのため、アプリが起動/前面に戻ると、新しいセッションが開始されます。

そうすれば、アプリが本当にメモリから削除されているかどうかを気にする必要はありません。

本当にそれをメモリから削除したい場合（これはお勧めできませんが、BTWはどのような目的で使用しますか？）、最後にonDestroy()with java.lang.System.exit(0)（またはおそらくrestartPackage(..)？）で条件付きで削除できます。もちろん、これは「本当にアプリを終了する」場合にのみ行ってください。これonDestroy()は、アプリの終了ではなく、アクティビティの通常のライフサイクルの一部であるためです。

Androidコンテキストのアプリケーションは、漠然と関連するアクティビティの集まりにすぎないため、アプリケーションを終了しても、あまり意味がありません。アクティビティをfinish（）すると、アクティビティスタック内の前のアクティビティのビューが描画されます。

私はテッドに同意します。アプリケーションを終了することは「Androidの方法」ではないことを理解していますが、除外する必要はないようです。（アクティビティだけでなく）アプリケーションを実際に終了する必要がある3つの理由を次に示します。

1. ユーザーは、メモリが少ない場合にどのアプリを強制終了するかを制御したい場合があります。重要なアプリAがバックグラウンドで実行されている場合、アプリAがオペレーティングシステムによって強制終了されないように、アプリBを使い終わったら終了します。

2. アプリケーションの機密データがメモリにキャッシュされている場合は、ウイルス/ワーム/不正アプリがアクセスできないようにアプリを強制終了することができます。私はセキュリティモデルがそれを防ぐことになっていることを知っていますが、念のために...

3. アプリケーションが、電話に悪影響を与える可能性のあるリソース（ネットワーク、CPU、センサーなど）を使用している場合、それらのリソースを確実に解放する1つの方法は、アプリケーションを終了することです。適切に動作するアプリは、不要になったときにリソースを解放する必要があることを理解しています。しかし、繰り返しになりますが、アプリケーションを終了することは、それを確実にするための合理的な方法のようです。

LinuxカーネルにはOut-of-memory killerと呼ばれる機能があります（前述のように、ポリシーはユーザー空間レベルで構成可能であり、カーネルは最適なものではありませんが、決して不必要ではありません）。

そしてそれはAndroidで頻繁に使用されています：

• OOMキラーはユーザースペース向けではありません

• Androidノート（OOM Killer Info-AndroidでOOM機能を設定できる場所）

• 実際のターゲットでのAndroid移植

これらのkillアプリを支援するために、いくつかのユーザースペースアプリを利用できます。次に例を示します。

• Autokiller / Androidの内部タスクキラーの構成

あなたはどうやらfinish（）コマンドであなたが望む答えを見つけました。これによってアプリがメモリから削除されることはありませんが、Androidはリソースが必要になるたびに削除するため、明示的に実行しないことには何の違いもありません。

アプリケーション出口が通常持つ完全な効果を達成するために、デバイスの起動後、最初に実行されたときの直前の通常の状態にアプリの状態をリセットすることを追加します。すべてのアクティビティでfinish（）を呼び出す。このようにして、ユーザーがアプリを再度選択すると、シミュレートされた「exit」の前の時点から残っている状態なしに、「fresh」で実行されたように見えます。

ユーザーの作業の保存など、「出口」でのみ発生する特別なアクションがある場合は、上記のルーチンの再初期化部分の前にそれらを実行することもできます。

このアプローチにより、アプリの終了を含むOSリソースの管理をオペレーティングシステムの手に委ねるというAndroidの哲学に違反することなく、「exit」コマンドの目標を達成できます。

個人的には、私はこのアプローチを使用しません。Androidユーザーは、アプリに再度アクセスしたときにアプリの継続性が維持されることを期待しているため、アプリを「終了」する方法に慣れていないためです。代わりに、ユーザーがアプリをデフォルトの初期状態にリセットするために呼び出すことができる「クリア」機能をサポートします。その際、アプリを「残す」必要はありません。

1つの例外は、ユーザーが戻るボタンをアプリを閉じるのに十分な回数押した場合です。そのような状況では、ユーザーの側で状態が保存されることは想定されていません（アプリに保存されていない状態がある場合、開発者は、その保存されていないデータを検出する戻るボタンを処理するコードを持っている必要があります。 SharedPreferences、ファイル、またはその他の不揮発性メディアに保存するようにユーザーに要求します）。

system.exit（0）について：

system.exit（0）を使用して失礼なファイナリティでアプリを閉じることにした場合（たとえば、最後の[戻る]ボタンを押した結果として）、警告が表示されます。ケースは、アプリの痕跡を残さずにアプリを閉じることができた唯一の方法でした。このアプローチを使用すると、Jelly Beanで1つの小さな不具合が発生します。

具体的には、最近のアプリリストを使用してアプリを開いてから、戻るボタンを使用してアプリを閉じると（system.exit（0）を介してそのクローズを実装して）、最近のアプリリストが再び表示されます。決して閉鎖されていません。あなたはそれを実行するためにそのリストでアプリのエントリをタップする場合は二度目に同じ、既に開いて、最近使ったアプリのリストから、何の応答はありません。

これの原因は、system.exit（0）を使用してアプリを閉じたために機能しなくなったアプリへの参照が[最近のアプリ]リストに保持されているためと思われます。finish（）を使用してより文明的にアプリを閉じると、最近のアプリリストを更新できるようにOSに通知された可能性がありますが、system.exit（0）は明らかにこれを行いません。

最近のアプリからアプリを開いて終了し、同じ開いている最近のアプリリストからすぐに再び開く人はほとんどいないため、これ自体は大きな問題ではありません。ホームボタンをタップしてから、最近使ったアプリリストを再度開くと、アプリのエントリが表示され、完全に機能します。 しかし、system.exit（0）を使用すると、アプリとOSの間の適切な通信が妨げられる可能性があることを示していると思います。これは、このアプローチを使用した結果、他のより深刻で微妙な可能性があることを示唆しています。

時間の経過とともに物事が変化することを願っています。アプリプロセスがOSによって正しくサンドボックス化されている場合、ユーザーはアプリまたはプロセスを強制終了できる必要があります。アプリは完全に記述する必要がある、またはユーザーがすべてのSDK推奨事項に従うアプリのみを使用するという考えがあります。それは難しい注文だと思います。

（比較的）シンプルなデザインで、「出口」の難問を回避できます。アプリに「基本」状態（アクティビティ）を持たせます。これは単なる空白の画面です。アクティビティの最初のonCreateで、アプリの主な機能が含まれている別のアクティビティを起動できます。「exit」は、この2番目のアクティビティをfinish（）実行し、空白の画面のベースに戻ることで実行できます。OSは、この空白の画面を必要な間メモリに保持できます...

本質的に、OSに出られないので、あなたは単に自分で作成した無に変身します。

アプリケーション開発者が自分のアプリケーションを強制終了するための終了関数がないと、設計が非常に悪くなります。

私のアプリケーションでは、ユーザーが実行時に動的にデータを動的に変更できるようにする必要があり、ユーザーは変更を有効にするためにアプリケーションを再起動する必要がありますが、Androidではアプリケーション自体を再起動できませんでした。Android OSの設計アプリケーションのライフサイクルは非常に悪いです。

いつでもアプリを閉じるにはFLAG_ACTIVITY_CLEAR_TOP、Intentのフラグを使用してからsystem.exit();

または、同様の方法がありsystem.exit()ますが、終了したくない場合は、このメソッドを呼び出します。

public void exit() {
    startActivity(new Intent(this, HomeActivity.class).
    setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true));
}

あなたのHomeActivity.onCreate()追加の次のコードで

protected void onCreate(Bundle savedInstanceState) {
    if (getIntent().getBooleanExtra(EXIT_FLAG, false)) {
        if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) {
            finish();
        }
    }
......................

これは、Androidのライフサイクルを壊すことなく機能します。

まず、System.exit（0）を決して使用しないでください。それは、人を眠らせ、頭を殴るようなものです。

第二に、私はこの問題に直面しています。私のソリューションを共有する前に、私の考えを共有したいと思います。

「終了ボタン」ってばかだと思います。本当に本当に本当に愚かです。また、アプリケーションの終了ボタンを要求するユーザー（消費者）も愚かだと思います。彼らは、OSがどのように機能し、どのようにリソースを管理しているのかを理解していません（それは素晴らしい仕事をしています）。

適切なタイミングで適切な処理（更新、保存、プッシュ）を行う適切なコードを記述し、適切な処理（サービスとレシーバー）を使用すると、かなりうまく機能し、誰も文句を言わないでしょう。 。

しかし、それを行うには、Androidでの動作を研究して学ぶ必要があります。とにかく、これはユーザーに「終了ボタン」を提供するための私の解決策です。

各アクティビティで常に表示されるオプションメニューを作成しました（それを行うスーパーアクティビティがあります）。

ユーザーがそのボタンをクリックすると、次のようになります。

Intent intent = new Intent(this, DashBoardActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

SharedPreferences settings = getSharedPreferences(getString(PREF_ID), Context.MODE_PRIVATE);
SharedPreferences.Editor editor = settings.edit();
editor.putBoolean(FORCE_EXIT_APPLICATION, true);

  // Commit the edits!
editor.commit();
startActivity(intent);
finish();

アプリを強制終了するためにSharedPreferencesに保存し、インテントを開始します。それらのフラグを見てください。これらは、私の「ホーム」アクティビティであるDashBoardアクティビティを呼び出すすべてのバックスタックをクリアします。

したがって、私のダッシュボードアクティビティでは、onResumeでこのメソッドを実行します。

private void checkIfForceKill() {

    // CHECK IF I NEED TO KILL THE APP

    // Restore preferences
    SharedPreferences settings = getSharedPreferences(
            getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE);
    boolean forceKill = settings.getBoolean(
            MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false);

    if (forceKill) {

        //CLEAR THE FORCE_EXIT SETTINGS
        SharedPreferences.Editor editor = settings.edit();
        editor.putBoolean(FORCE_EXIT_APPLICATION, false);

        // Commit the edits!
        editor.commit();

        //HERE STOP ALL YOUR SERVICES
        finish();
    }
}

そして、それはかなりうまくいきます。

それがなぜ起こっているのか私が理解していない唯一のことは、最後の仕上げを行ったとき（そしてチェックしたところ：onPause→onStop→onDestroyのすべての正しいフローに従っている）、アプリケーションはまだ最近のアクティビティにあります（しかし空白です）。

（DashboardActivityを開始した）最新のインテントがまだシステムにあるようです。

それも削除するためにもっと掘る必要があります。

Androidアプリケーションのライフサイクルは、コンピューターユーザーではなく、携帯電話ユーザー向けに設計されています。

アプリのライフサイクルは、Linuxサーバーをコンシューマーアプライアンスに変えるために必要な、非常に単純化したパラダイムです。

AndroidはLinux上のJavaであり、実際のクロスプラットフォームサーバーOSです。それはそれがとても速く広まった方法です。アプリのライフサイクルは、OSの根本的な現実をカプセル化します。

モバイルユーザーにとって、アプリは単にインストールされるか、インストールされません。実行または終了の概念はありません。実際、アプリプロセスは、OSが保持しているリソースに対してそれらを解放するまで実行されることを意図しています。

これはスタックオーバーフローであるため、これを読む人はすべてコンピューターユーザーであり、モバイルアプリのライフサイクルを理解するには、知識の90％をオフにする必要があります。

このQ＆Aを読むのに、実際に半適切なAndroidアプリケーションライフサイクルを実装するよりも時間がかかりました。

これは、ポイントをポーリングし、スレッドを使用して数秒ごとに現在位置をWebサービスに送信するGPSアプリです...これは、Tedの場合、更新のために5分ごとにポーリングする可能性があります。onStopは、更新アクティビティを開始できます。見つかったかどうかを心配します（非同期のTed、Windowsプログラマのようにコーディングしないでください。そうしないと、プログラムはWindowsプログラムのように実行されます...ええ、それほど難しくありません）。

onCreateでいくつかの初期コードを実行して、アクティビティのライフタイムの設定を行いましたcheckUpdate.start();。

...

@Override
public void onStart() {
    super.onStart();
    isRemote = true;
    checkUpdate.resume();

    locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh);
}

@Override
public void onPause() {
    isRemote = false;
    checkUpdate.suspend();
    locationManager.removeUpdates(luh);
    super.onStop();
}

このコードは完全に間違っている可能性がありますが、機能します。これは私の最初のAndroidアプリケーションの1つです。

バックグラウンドでCPUを消費しないアプリケーションであるVoilàは、RAM内にあるため（AndroidライフサイクルのようにRAMを保持していませんが）、すぐに再開する準備ができています...アプリは常に準備ができており、電話です、みんな/ギャル。アプリがすべてのRAMを使い果たし、OSによってシャットダウンできない場合、リンギングが停止する可能性があります= Pこれが、バックグラウンドにあるときにOSがアプリを閉じる必要がある理由です（アプリケーションが閉じ込められないリソースを消費するわけではないので）、より良いアプリケーションを作成してみましょう。

インテントを介して次のページに移動するたびに、以下を使用します。

`YourActivityname.this.finish()`;

例：

Intent intent = new Intent(getApplicationContext(), SMS.class);

startActivity(intent);
MainActivity.this.finish();

バックグラウンドでアクティビティが実行されないようにして、アプリを終了する場合は、次を使用します。

MainActivity.this.finish();
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
getParent().finish();

この存在は私にとって魅力のように働きました:)

いずれにせよ、アプリケーションを終了したい場合は、いつでもを呼び出すことができますSystem.exit(0);。

10,20 ..複数のアクティビティを実行していて、それらすべてを終了してシステムを終了したい場合。

application classまたはで静的配列を作成するconstants class.

定数

public class Constants {

public static ArrayList<Activity> activities = new ArrayList<Activity>();

}

MainActivity 現在のアクティビティ参照をこの配列に追加します

activity = MainActivity.this; Constants.activities.add(activity);

public class MainActivity extends Activity {

    private ImageView imageButton;
    private Activity activity;


    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        activity = MainActivity.this;
        Constants.activities.add(activity);

        imageButton = (ImageView) findViewById(R.id.camera);
        imageButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {

                // existing app.
                if (Constants.activities != null) {
                    for (int i = 0; i < Constants.activities.size(); i++) {
                        Activity s = Constants.activities.get(i);
                        s.finish();
                    }
                }
                //super.finish();
                finish();
                android.os.Process.killProcess(android.os.Process.myPid());
                System.exit(1);
            }
        });
    }
}