Androidプロセスのスケジューリング
Android app/serviceを作成するときに、相互運用性の潜在的な問題による信頼性への影響を特定できるように、理解を深めようとしています。プロセスの優先順位がどのように決定されるかを理解したいと思います。違いはサービスとアクティビティの間の優先順位と、スケジューラがそれらの優先順位を異なる方法で処理するかどうか。基本的に、アクティビティまたはサービスが別のアプリケーション（またはLinuxカーネル。）
誰かがあなたが推薦できる良いリンクを持っていますか...私の検索はまだあまり現れていません。
ありがとう！
編集：私の懸念は、メモリ時間ではなく、プロセッサ時間のスライシング/スケジューリングに関するものです（メモリ時間は、Androidのドキュメントに詳しく説明されています。）よろしくお願いします。
次のリストは、さまざまなタイプのプロセスを重要度の高い順に示しています（最初のプロセスが最も重要であり、最後に強制終了されます）。
- フォアグラウンドプロセス
- 目に見えるプロセス
- サービスプロセス
- バックグラウンドプロセス
- 空のプロセス
注：Androidは、現在アクティブなコンポーネントの重要性に基づいて、可能な最高レベルでプロセスをランク付けしますたとえば、プロセスがサービスと可視アクティビティをホストしている場合、そのプロセスはサービスプロセスではなく可視プロセスとしてランク付けされます。
これはここから参照されます プロセスとスレッド
編集：
アプリケーションの優先順位とプロセスの状態について
リソースを再利用するためにプロセスが強制終了される順序は、ホストされているアプリケーションの優先順位によって決まります。アプリケーションの優先度は、最高の優先度のコンポーネントと同じです。
2つのアプリケーションの優先度が同じ場合、優先度が最も低いプロセスが最長で強制終了されます。プロセスの優先順位は、プロセス間の依存関係にも影響されます。アプリケーションが2番目のアプリケーションによって提供されるサービスまたはコンテンツプロバイダーに依存している場合、セカンダリアプリケーションは、サポートするアプリケーションと少なくとも同じ優先度を持ちます。
すべてのAndroidアプリケーションは、システムが他のアプリケーションのリソースを必要とするまで、実行中およびメモリ内に残ります。
アプリケーションを正しく構造化して、その優先度が現在の作業に適切であることを確認することが重要です。そうしないと、重要なものの途中でアプリケーションが強制終了される可能性があります。次のリストは、図に示されている各アプリケーション状態の詳細を示し、状態を構成するアプリケーションコンポーネントによって状態がどのように決定されるかを説明しています。
アクティブプロセスアクティブ（フォアグラウンド）プロセスは、現在ユーザーと対話しているコンポーネントを持つアプリケーションをホストしているプロセスです。これらはプロセスですAndroidはリソースを再利用することで応答性を維持しようとしています。これらのプロセスは一般的に非常に少なく、最後の手段としてのみ強制終了されます。
アクティブなプロセスは次のとおりです。
1.「アクティブ」な状態のアクティビティ。つまり、フォアグラウンドにあり、ユーザーイベントに応答しています。この章の後半で、アクティビティの状態を詳しく見ていきます。
2. onReceiveイベントハンドラーを現在実行しているアクティビティ、サービス、またはブロードキャストレシーバー。
3. onStart、onCreate、またはonDestroyイベントハンドラーを実行しているサービス。
可視プロセス可視ですが、非アクティブプロセスは「可視」アクティビティをホストするプロセスです。名前が示すように、可視のアクティビティは可視ですが、フォアグラウンドではなく、ユーザーイベントに応答していません。これは、アクティビティが部分的にしか隠されていない場合に発生します（非フルスクリーンまたは透明なアクティビティによって）。一般的に目に見えるプロセスはほとんどなく、アクティブなプロセスを続行できるようにするために、極端な状況でのみ強制終了されます。
開始されたサービスプロセス開始されたサービスをホストするプロセス。サービスは、目に見えるインターフェースがなくても継続する必要がある進行中の処理をサポートします。サービスはユーザーと直接対話しないため、表示されるアクティビティよりもわずかに優先度が低くなります。これらは引き続きフォアグラウンドプロセスと見なされ、アクティブプロセスまたは可視プロセスにリソースが必要でない限り、強制終了されません。
バックグラウンドプロセス表示されておらず、開始されているサービスがないアクティビティをホストしているプロセスは、バックグラウンドプロセスと見なされます。一般に、Androidは、last-seen-first-killedパターンを使用して、フォアグラウンドプロセス用のリソースを取得するために強制終了する多数のバックグラウンドプロセスがあります。
空のプロセスシステム全体のパフォーマンスを向上させるために、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秒以内に実行を開始したりしても、ユーザーにはわかりません。もちろん、早く終了するほど良いです。
このシステムでは、テキストエディターがインタラクティブであるため、スケジューラーはテキストエディターにビデオエンコーダーよりも高い優先度と大きなタイムスライスを与えます。テキストエディタには、多くのタイムスライスが用意されています。さらに、テキストエディターは優先度が高いため、必要に応じてビデオエンコーダーをプリエンプトできます。これにより、テキストエディターがユーザーのキー入力に即座に応答できるようになります。これはビデオエンコーダーに悪影響を及ぼしますが、テキストエディターは断続的にしか実行されないため、ビデオエンコーダーは残りの時間を独占できます。これにより、両方のアプリケーションのパフォーマンスが最適化されます。
この点でのAndroidは、通常のLinuxシステムとは少し異なります。 Androidがスケジューリングに影響を与えるために使用するものは2つあります：プロセス/スレッドの「Nice」レベルとcgroupです。
プロセスの「ナイス」レベルは、Linuxの通常の「フェア」スケジューリングポリシーに影響を与えます。 nicenessが高いスレッドは、nicenessが低いスレッドよりも実行頻度が低くなります。 「デフォルト」の優先順位（ Process.THREAD_PRIORITY_DEFAULT で定義されている）のスレッドが1つある状況では、バックグラウンドの優先順位（または Process.THREAD_PRIORITY_BACKGROUND ）。
理論的には、これにより、フォアグラウンド/ UIスレッドがバックグラウンド作業の影響を大幅に受けないようにすることができます。ただし、実際には、それだけでは不十分です。すべて実行したいバックグラウンドスレッドが10個あるが、UIを駆動するフォアグラウンドスレッドが1つあるかどうかを検討します。これにより、フォアグラウンドスレッドの動作に顕著な影響が生じる可能性があります。
これに対処するために、Androidは、より厳密なフォアグラウンドスケジューリングとバックグラウンドスケジューリングを作成する簡単な方法でLinux cgroupも使用します。フォアグラウンド/デフォルトcgroupは、通常どおりスレッドスケジューリングを許可します。ただし、バックグラウンドcgroupには制限が適用されますそのcgroup内のallスレッドで使用可能な合計CPU時間のほんの一部の割合にすぎません。したがって、その割合が5％であり、10個のバックグラウンドスレッドがある場合すべてを実行したい場合と1つのフォアグラウンドスレッドの場合、10個のバックグラウンドスレッドは、フォアグラウンドから使用可能なCPUサイクルの最大5％しか取得できません（もちろん、フォアグラウンドスレッドを実行する必要がない場合、バックグラウンドスレッドは使用可能なすべてのスレッドを使用できます。 CPUサイクル。）
Androidは、パブリックAPIを使用してスレッドの優先順位を設定すると、デフォルトのcgroupとバックグラウンドのcgroupの間で暗黙的にスレッドを移動します。したがって、スレッドの優先度を Process.THREAD_PRIORITY_BACKGROUND 以上に設定すると、スレッドもバックグラウンドcgroupに配置されます。 Process.THREAD_PRIORITY_DEFAULT に設定すると、デフォルトのcgroupに配置されます。
このため、バックグラウンドワーカースレッドをバックグラウンドの優先順位にするという通常の規則に従うことで、フォアグラウンドUIスレッドが中断されないようにすることができます。
さらに、Androidは、プロセス内のすべてのスレッドを、ユーザーにとって重要ではないことがわかっているプロセスのバックグラウンドcgroupに移動します。バックグラウンドプロセスまたはサービスプロセスのスレッドはバックグラウンドに置かれます。個々のスレッドがフォアグラウンドのスケジューリング優先順位を要求したかどうかに関係なく、cgroup。
はい、プロセスが不足するのは可能です。
AndroidはLinux 2.6を使用しています リソースの低レベルの管理に使用します。 Linux 2.6は マルチレベルフィードバックキュー をスケジューリングアルゴリズムとして使用しています。これは、I/Oバウンドプロセスと短いCPUバーストプロセスを優先します（応答性/相互作用のために電話に最適です）。ただし、これはCPUを集中的に使用するプロセスと優先度の低いプロセスが不足するリスクがあることを意味します。 Linux 2.6が待機中のプロセスの優先度を定期的に上げて、最終的にサービスが提供されて飢餓を回避できるかどうかはわかりません。
ただし、現実的には、アクティブアクティビティまたはサービスになるため、これについて心配する必要はありません。どちらも、前の回答が示すようにどちらも比較的優先度が高くなります。