ランタイムによってアクティビティがいつどのように強制終了されるかについて、誰かが簡単な概要を説明できますか？一時停止状態と停止状態の違いを知りたいのですが。一時停止したアクティビティをシステムに強制的に破棄させるには、停止した場合とまったく同じ（メモリ不足）理由がありますか？
電話の着信（突然メモリ不足の状況が発生する）のためにアクティビティが一時停止された場合、システムは停止されたアクティビティのリソースを解放することを単に好むと思います。しかし、それはどのように行われますか？システムがfinish（）を呼び出してアクティビティを「親切に尋ねる」のはいつですか、そうでないのはいつですか。また、onDestroy（）はいつ呼び出されますか？
あなたが尋ねたことのほとんどはドキュメンテーションによってかなりよく説明されています、しかし私はいくつかのことを明確にすることができると思います。
一時停止状態と停止状態の違いを知りたいのですが。
可視性。Dialog一時停止されたアクティビティは、テーマが適用されたアクティビティなどの別のアクティビティによって部分的にしか隠されていない可能性があるため、2つの状態は異なります。そのためには、視覚的な状態を維持するために必要なリソースをすべて保持する必要があります。停止されたアクティビティは、それらのリソースを放棄する可能性があり、リソースが不足している場合に、アクティビティが破棄されるか保存されるかによって違いが生じる可能性があります。
私は...システムは単に停止したアクティビティのリソースをリリースすることを好むと思います。しかし、それはどのように行われますか？
それはしなければなりません。停止されたアクティビティは完全に見えないため、ユーザーに表示されるものにまだ貢献しているアクティビティよりも、殺害の候補として適しています。一時停止しているが部分的に表示されているアクティビティが再開されたアクティビティからAndroidがヤンクするのを見たことがありませんが、適切な状況で発生する可能性があると思います。システムは、各アクティビティの状態を認識します。これは、アクティビティをそこに向けているためです。
システムがfinish（）を呼び出してアクティビティを「親切に尋ねる」のはいつですか、そうでないのはいつですか。また、onDestroy（）はいつ呼び出されますか？
システムは可能な場合は整然とした破棄を行いますが、APIは、アクティビティがとを確認することを保証するだけonPause()ですonSaveInstanceState()。
ETA：アクティビティがスタックから削除される正確な理由はソースにあります。決定を異なる方法で行うAndroidの将来のバージョンが存在する可能性があるため、これらの理由が普遍的な真実であることに依存するべきではありません。
コースのパー、なるほど！高価な誤った情報と混ざり合った貴重な情報がいくつかあります。いいえ、オンラインドキュメントでは、プロセスが強制終了される状況を正確に指定しているわけではありません。これは、予告なしに変更される可能性があるため、意図的なものです。確かに、onDestroy（）が呼び出される最も一般的な理由は、システムのメモリが不足していることです。これは、新しい電話ではあまり一般的ではありません（メモリが非常に多いため）。しかし、それが呼ばれる唯一の理由であるという保証はありません。
しかし、はい、Androidと開発者の間の「契約」は、ルールに従い、必要なときに必要なライフサイクルコールバックを実装すれば、それは機能し、どのような状況でonStop（）を正確に知る必要がないということです。 onSaveInstanceState（）とonDestroy（）が呼び出されます。
グーグルとは異なり、契約の文言はいくつかの点でやや曖昧であることを認めます。これは、他の理由は少ないものの、「フォアグラウンド」などの標準的な業界の意味を持つ用語を使用しているが、わずかに変更された意味で使用しているためです。そして、変更は決して説明されないか、あいまいな場所でのみ説明されます。また、図が「アクティビティが状態間でたどる可能性のあるパス」を示すことを目的としていますが、ResumedからStoppedへの遷移をバイパスしても、onDestroy（）を何度も呼び出すことができることを示すことはできません。しかし、テキストはその可能性を明確に説明しています。
残念ながら、「アプリケーションの基礎」の「アプリケーションライフサイクル」セクションを読むだけでは不十分なのはこのためです。代わりに、Activityのコールバックの各コールバックのJavadocと、プロセスの「アプリケーションの基礎」のセクションも読む必要があります。
その後、各コールバックにLog.dステートメントを配置し、アプリケーションをライフサイクル全体で循環させている間、logcatの出力を監視すると非常に役立ちます。ただし、それでも、上記のオンラインドキュメントのいずれかで正当な理由が見つからない限り、logcatに表示される順序で発生するライフサイクルイベントに依存しないでください。