次のリストは、さまざまなタイプのプロセスを重要な順に示しています (最初のプロセスが最も重要で、最後に強制終了されます)。
- フォアグラウンド プロセス
- 目に見えるプロセス
- サービスの流れ
- バックグラウンド プロセス
- 空のプロセス
注: Android は、プロセスで現在アクティブなコンポーネントの重要性に基づいて、可能な限り高いレベルでプロセスをランク付けします。たとえば、プロセスがサービスと可視アクティビティをホストする場合、そのプロセスはサービス プロセスではなく、可視プロセスとしてランク付けされます。
これはここから参照されますProcesses and Threads
編集：
アプリケーションの優先度とプロセスの状態について
リソースを再利用するためにプロセスが強制終了される順序は、ホストされているアプリケーションの優先度によって決まります。アプリケーションの優先度は、最も優先度の高いコンポーネントと同じです。
2 つのアプリケーションの優先度が同じ場合、優先度の低いプロセスが最初に強制終了されます。プロセスの優先度は、プロセス間の依存関係の影響も受けます。アプリケーションが、2 番目のアプリケーションによって提供されるサービスまたはコンテンツ プロバイダーに依存している場合、2 番目のアプリケーションは、少なくともそれがサポートするアプリケーションと同じくらい高い優先度を持ちます。
システムが他のアプリケーションのためにリソースを必要とするまで、すべての Android アプリケーションは実行され、メモリ内に残ります。
アプリケーションの優先度が実行中の作業に適していることを確認するには、アプリケーションを正しく構造化することが重要です。そうしないと、重要な処理の最中にアプリケーションが強制終了される可能性があります。次のリストは、図 に示されている各アプリケーションの状態の詳細を示し、状態を構成するアプリケーション コンポーネントによって状態がどのように決定されるかを説明しています。
アクティブなプロセスアクティブな (フォアグラウンド) プロセスは、現在ユーザーと対話しているコンポーネントを持つアプリケーションをホストしているプロセスです。これらは、Android がリソースを再利用することで応答性を維持しようとしているプロセスです。通常、これらのプロセスはほとんどなく、最後の手段としてのみ強制終了されます。
アクティブなプロセスは次のとおりです。
1.「アクティブ」状態の活動。つまり、それらはフォアグラウンドにあり、ユーザー イベントに応答します。アクティビティの状態については、この章の後半で詳しく説明します。
2.現在 onReceive イベント ハンドラを実行しているアクティビティ、サービス、またはブロードキャスト レシーバ。
3. onStart、onCreate、または onDestroy イベント ハンドラを実行しているサービス。
可視プロセス可視だが非アクティブなプロセスは、「可視」アクティビティをホストするプロセスです。名前が示すように、目に見えるアクティビティは目に見えますが、フォアグラウンドにあるわけでも、ユーザー イベントに応答するわけでもありません。これは、アクティビティが部分的にのみ隠されている場合に発生します (非フルスクリーンまたは透明なアクティビティによって)。通常、目に見えるプロセスはほとんどなく、アクティブなプロセスを続行できるようにするために、極端な状況でのみ強制終了されます。
開始されたサービス プロセス 開始されたサービスをホストするプロセス。サービスは、目に見えるインターフェイスなしで続行する必要がある進行中の処理をサポートします。サービスはユーザーと直接対話しないため、表示されるアクティビティよりも優先度がわずかに低くなります。それらは引き続きフォアグラウンド プロセスと見なされ、アクティブなプロセスまたは可視のプロセスにリソースが必要でない限り、強制終了されません。
バックグラウンド プロセス表示されず、サービスが開始されていないアクティビティをホストするプロセスは、バックグラウンド プロセスと見なされます。通常、フォアグラウンド プロセスのリソースを取得するために Android が最後に検出されたものを最初に強制終了するパターンを使用して強制終了する多数のバックグラウンド プロセスがあります。
空のプロセスシステム全体のパフォーマンスを向上させるために、Android では多くの場合、アプリケーションが寿命に達した後もメモリに保持されます。Android は、アプリケーションが再起動されたときの起動時間を改善するために、このキャッシュを維持します。これらのプロセスは、必要に応じて定期的に強制終了されます。
詳細については、こちら (このブログで見つけました) Android のメモリ管理を参照してください。
編集：
I think Android is basic Linux so, whatever scheduler works for Linux is same in Android.
Android スケジューラと Linux スケジューラの違い
スケジューラ — 5 ファイル — Android カーネルには、CPU プロセス スケジューラと時間管理アルゴリズムへのわずかな変更も含まれています。これらの変更の履歴は不明であり、ざっと調べただけでは影響は明らかではありませんでした。
プロセス プリエンプション:
前述のとおり、Linux オペレーティング システムはプリエンプティブです。プロセスが TASK_RUNNING 状態に入ると、カーネルはその優先度が現在実行中のプロセスの優先度よりも高いかどうかを確認します。そうである場合、スケジューラーが呼び出されて、実行する新しいプロセスが選択されます (おそらく、実行可能になったばかりのプロセス)。さらに、プロセスのタイムスライスがゼロに達すると、そのプロセスは横取りされ、スケジューラが呼び出されて新しいプロセスが選択されます。
実際のスケジューリング ポリシー
テキスト エディターとビデオ エンコーダーの 2 つの実行可能なタスクを持つシステムを考えてみましょう。テキスト エディタは、ほぼすべての時間をユーザー キーの押下の待機に費やしているため、I/O バウンドです (ユーザーがどれだけ速く入力しても、それほど速くはありません)。それにもかかわらず、キーが押された場合、ユーザーはエディターがすぐに応答することを期待しています。逆に、ビデオ エンコーダーはプロセッサ バウンドです。エンコーダーは、ディスクから生データ ストリームを読み取り、後で結果のビデオを書き込む以外に、ビデオ コーデックを生データに適用することにすべての時間を費やします。いつ実行するかについて、厳密な時間制限はありません。今すぐ実行を開始したのか、0.5 秒後に実行を開始したのかは、ユーザーにはわかりません。もちろん、早ければ早いほど良いです。
このシステムでは、テキスト エディターは対話型であるため、スケジューラーはビデオ エンコーダーよりも高い優先度と大きなタイムスライスをテキスト エディターに与えます。テキスト エディタには、利用可能なタイムスライスがたくさんあります。さらに、テキスト エディターの優先度が高いため、必要に応じてビデオ エンコーダーをプリエンプトすることができます。これにより、テキスト エディターがユーザー キーの押下に即座に応答できるようになります。これはビデオ エンコーダーにとって不利益ですが、テキスト エディターは断続的にしか実行されないため、ビデオ エンコーダーが残りの時間を独占する可能性があります。これにより、両方のアプリケーションのパフォーマンスが最適化されます。