オライリーの本は言う：
Android向けのプログラミングは、他のいくつかの環境向けのプログラミングとは概念的に異なります。Androidでは、アプリケーションの状態の特定の変更を自分で推進するのではなく、その変更に自分自身がより敏感に反応することがわかります。
これは、Javaアプレットまたはサーブレットのプログラミングに似た、管理されたコンテナベースの環境です。
[...]
したがって、アクティビティのライフサイクルに関しては、アクティビティがどのような状態にあるかを言うことはできませんが、状態から状態への遷移で何が起こるかを言う機会はたくさんあります。
2つの質問：
自分で変更を推進するのではなく、アプリケーションの状態の特定の変更に自分自身がより反応しているとはどういう意味ですか？」例を挙げてください。
活動とは何かを言わずに、州から州への移行時に何が起こるかを話してみませんか？
その言い回しは少し紛らわしいですが、これがあなたの質問に私が言うことです：
「応答」に関する部分は、多くのAndroidプログラミングのイベントベースの性質を指します。たとえば、各アクティビティには、アプリケーションライフサイクルの特定の段階で自動的に呼び出されるのような標準的なメソッドがonCreate(..)あります。onResume(...)これらのライフサイクルの変化に正しく対応するのはあなたの仕事です。
「活動が何であるかを言わないでください」とはどういう意味かわかりませんが、推測します。基本的に、アクティビティは、コードのブロックで定義し、1回の呼び出しで画面に表示する画面またはアクションだけではありません。アクティビティの状態を簡単に管理し、各ポイントでさまざまなアクションを実行します。たとえば、アクティビティが開始さonCreateれて呼び出されたときに、ビューをロードしてアクティビティの外観を設定する必要があります。
それらが意味するのは、基本的に、イベントキューの片側でのみ実際に作業しているということです。イベントはすべて、アプリケーションのさまざまな状態とともに事前定義されています。リスナーを追加して、どのように反応するかを決めるだけです。
モバイルプラットフォームでアプリケーションを開発すると、開発者はある程度制限されます。これは完全なOSとは異なり、モバイルデバイスで一度に複数のアプリケーションを実行するとコストがかかります。したがって、実行中のアプリケーションに何が起こるかは、ユーザーが何をしているかに大きく依存します。ユーザーがメイン画面に戻ってアプリケーションを「閉じる」と、アプリケーションの動作を制御できなくなります。制御できるのは、ユーザーがアプリケーションを操作しているときにアプリケーションが実行することであり、フォアグラウンドの喪失などのさまざまなイベントに応答できます。実際には、ユーザーの実行に基づいてアプリケーションの実行を制御することしかできません。