誰が生き、誰が死ぬのか：Androidプロセスの優先順位

翻訳者のメモ：翻訳時に、Google自身が提供するロシア語版のAndroidドキュメントで用語を最大限に活用しようとしたため、「サービス」は「サービス」に、「コンテンツプロバイダー」は「コンテンツプロバイダー」などになりました。 しかし、「活動」は「操作」になることはできませんでした-私は自分自身を圧倒しませんでした。 ごめんなさい

認めましょう。モバイルデバイスには、無限のメモリ、無限のバッテリ電源、または他の無限のものがありません。 私たちにとって、これは次のことを意味します。 プロセスの死をアプリケーションのライフサイクルの自然な部分と見なさなければなりません 。 プロセスの破壊に関連するメモリの解放がユーザーに悪い結果をもたらさないことを確認することが重要です。 このタスクを達成するために、Androidのプロセスアーキテクチャのほとんどは、どのプロセスが生きて死ぬかに応じて厳格な階層を提供するように設計されています。

Androidプロセス階層

ドキュメントに目を向けると、最も重要なプロセスはフォアグラウンド プロセスと呼ばれ 、その後に目に見えるプロセス 、 サービスプロセス 、 バックグラウンド プロセス 、最後に空のプロセスが続きます 。 ところで、Androidアプリケーションのコンポーネント（サービス、 Activity



など）については説明しますが、 Androidは常にコンポーネントではなくプロセスを破棄することに注意してください。 もちろん、これはガベージコレクションと矛盾しません（その結果、他の誰も参照していないオブジェクトによって占有されているメモリがシステムに返されます）が、これは別の投稿のトピックです。

フォアグラウンドプロセス

おそらく、ユーザーがいつでもやり取りするのは、システムのコンポーネントであり、何らかの方法で（少なくともユーザーが作業を続けている限り）破壊できないものだと思います。 一つのこと：「ユーザーがいつでもやり取りするもの」は、わずかにあいまいな定義です。 このカテゴリに分類されるコンポーネントの1つは、フォアグラウンドActivity



。onResume（）が既に呼び出され、 onPause（）がまだ呼び出されていないものです。



一部のActivity



は自分の仕事のみに依存しますが、他のActivity



はその一部をバインドされたサービスにシフトします。 Activity



関連付けられたサービスを含むプロセスは、Foreground Activity



自体を含むプロセスと同じ優先度をシステムから受け取ります。 これは正しいことですActivity



が、その作業のためにサービスとの常時接続を維持する必要があると考えている場合は、 Activity



自体とAndroidの両方の利益のために、このサービスを生かして安全に保ちます。 同じ原則がコンテンツプロバイダーにも適用されます。



しかし、そのActivity



が消えるとすぐにユーザーをinさせる唯一のコンポーネントはActivity



だと誰が言ったでしょうか？ 私の音楽が突然再生を停止した場合、またはナビゲーションシステムからのヒントが霧の中に消えた場合、私は間違いなく怒ります。 幸いなことに、Androidでは、 startForeground（）メソッドを呼び出すことにより、サービスが優先順位が付けられていることをシステムに通知できます。 このメソッドを呼び出すことは、 バックグラウンドミュージックの再生を保証する最良の方法です。他のタスクに関しては、 startForeground()



呼び出す前に、「ユーザーはすぐに私のサービスが機能しなくなったことに気付くでしょうか？」計画は、作業の中断がすぐに明らかになる重大な場合にのみ使用する必要があります。

注：フロントエンドサービスでは、サービスが実行されていることをユーザーに通知する通知を投稿する必要があります。 特定のケースで通知が不要であると思われる場合は、おそらくフロントエンドサービスは必要ありません（これは正常であり、バックグラウンドで操作を保証する他の方法があります。これについては後述します）。

プロセスの優先度が一時的にフォアグラウンドプロセスの優先度に上げられる他のいくつかのケースがあります。 これらには、次のライフサイクルメソッドを実行するサービスが含まれます： onCreate（） 、 onStartCommand（）、およびonDestroy（） メソッドonReceive（）のブロードキャストメッセージの受信者（ブロードキャスト受信者）による実行も適用されます。 これらのライフサイクルメソッドをアトミ​​ックにし、各コンポーネントがシステムによって破壊されることなくそれらを実行できるようにするには、この優先度の増加が必要です。

目に見えるプロセス

だから、やめActivity



、私はすでにActivity



について話しましたか？ 彼は言ったが、Androidは神秘的な知恵で、あなたのActivity



が見えるが、フォアグラウンドではないときにそのような状況が発生することを許している。 これは、 Activity



が、Dialogからテーマを継承する別のActivity



を開始するときに発生する可能性があります。 または、開始Activity



が半透明の場合。 または、ユーザーに特定のアクセス許可 （実際はActivity



！）を要求するシステムダイアログを呼び出したとき。



Activity



は、 onStart（）呼び出しからonStop（）呼び出しに表示されます。 これら2つの呼び出しの間に、画面の更新など、目に見えるActivity



期待されることは何でもできます。



ちなみに、可視Activity



のリンクされたサービスとコンテンツプロバイダーActivity



れているプロセスも、可視Activity



のプロセスと同じ優先度を取得します（フォアグラウンドActivity



発生することと同様）。プロセスはシステムによって破壊されません。



次の点に注意してください。プロセスが見えるという事実は、システムによって破壊されないことを保証するものではありません 。 フォアグラウンドプロセスがニーズのために大量のメモリを必要とする場合、Androidが極端になり、表示されているプロセスをバタンとする可能性があります。 ユーザーにとって、これは前景のActivity



下にある次のActivity



が黒い画面に置き換えられるように見えます。 もちろん、 キルしたActivity



正しく再作成すると、 フォアグラウンドActivity



が破棄されるとすぐに、プロセスとActivity



が状態を失うことなく再作成されます。

注： startActivityForResult（）の結果がonActivityResult（）で処理され、 requestPermissions（）の結果がコールバック関数ではなくonRequestPermissionsResult（）にある理由の1つは、可視プロセスを強制終了する可能性です。プロセスが破棄されると、その中の既存のコールバック関数もすべて破棄されます。 したがって、コールバック関数を使用したアプローチを使用するライブラリを見る場合、システムに十分なメモリがない場合、期待どおりに動作しない可能性があることに注意してください。

サービスプロセス

プロセスが上記のカテゴリのいずれにも該当せず、実行中のサービスがある場合、プロセスはサービスプロセスの優先度を取得します。 このようなケースは、バックグラウンド作業（データのダウンロードなど）を実行する多くのアプリケーションの典型ですが、この作業の結果はフロントエンドサービスの場合ほど重要ではありません。



そして、これらのプロセスは見た目ほど役に立たないわけではありません。 幅広いタスクの場合、このようなプロセスはバックグラウンドタスクを実行するための最良の方法です。これは、可視プロセスとフォアグラウンドで多くのことが発生し、どこかからメモリを緊急に取得する必要がある場合にのみ破棄されるためです。



プロセスがメモリ不足で破壊された場合のシステムの動作を決定するため、 onStartCommand（）から返す定数に特に注意してください。

• START_STICKYは、可能な場合にシステムがサービスを復活させることを意味しますが、サービスが受け取った最後のIntent
  
  
  
  を再送信しません（たとえば、自分で状態を復元したり、起動時に何をすべきかを決定する自己記述のライフサイクルを持っています）サービスのシャットダウン）。
• START_REDELIVER_INTENTは、onStartCommand（）で受け取ったのと同じIntent
  
  
  
  から再起動するサービス用です
• START_NOT_STICKYは 、霧の中に静かに消えた場合に再起動する必要のないサービスに役立ちます。 この動作は、しばらくスキップできる定期的なタスクを実行するサービスに役立つ場合があります。

バックグラウンドプロセス

Foreground Activity



があり、ユーザーが[ホーム]ボタンをクリックすると、 onStop（）コールが発生したとします。 このActivity



とは別に、プロセスの高い優先度を維持し続けることができるものがなくなった場合、プロセスはバックグラウンドプロセスのカテゴリに入ります 。 ちなみに、ユーザーが後で以前に開いたアプリケーションのいずれかに戻ることにした場合に備えて、デバイスのメモリのほとんどを占有します。



Androidは、プロセスを最初から開始するのはかなりリソースを消費するため、プロセスを左右に強制終了しません。 したがって、新しい高優先度プロセスが水平線に表示される場合、それらは破棄される前にしばらくメモリ内に残ることができます。 破壊は、長い間使用されていないものを押しつぶす順序で発生します。ほとんど使用されなかったプロセスが最初に破壊されます。 可視プロセス/ Activity



破壊の場合のように、データを失うことなくActivity



を正しく再作成できる必要があります。

空のプロセス

他の階層と同様に、常に最下位レベルがあります。 空のプロセスにはアクティブなコンポーネントはなく、Androidはいつでもそれらを破棄できますが、通常はしばらくの間メモリ内に保持されます（これは、すべてをクリーンアップすることではなく、メモリの効率的な使用に関するものです）行で）。

注意すべきこと

プロセスで実行されているコンポーネントの観点からプロセスの優先順位について説明しましたが、コンポーネントレベルではなくプロセスレベルで階層が存在することに注意してください 。 プロセス全体をフォアグラウンドプロセスのカテゴリに変換するコンポーネントは1つだけです（たとえば、フォアグラウンドサービス）。 ほとんどのアプリケーションは1つのプロセスで完全に動作しますが、アプリケーションのライフサイクルが起動ごとに大きく異なる場合、またはアプリケーションに非常に困難なタスクがある場合は、時間がかかりますが、軽量であり、最初のプロセスは2番目のプロセスに依存しません、つまり、2つのプロセスを区別することは理にかなっています。 最初のプロセスで重いタスクを実行し、2番目のプロセスで軽いタスクを実行します。その後、メモリ不足の場合は、重いタスクを中断し、軽量なタスクを続行します。



また、プロセスの優先度はコンポーネントレベルで何が起こるかによって決まることを覚えておくことが重要です 。 つまり、長時間実行する必要のある非常に重要なタスクを別のスレッドで、ただしActivity



下から実行すると、プロセスが突然バックグラウンドになったときに不快な驚きを得ることになります。 利用可能なツール（サービス、フロントエンドサービスなど）を使用して、システムが現在実行していることを確認します。

他人のことを忘れずに、ユーザーのことを覚えておいてください

必要な優先度で常に機能するようにアプリケーションを構築します-これ以上でもそれ以下でもありません。 また、開発者として、最も弱いエンドユーザーデバイスよりもはるかに強力なデバイスを手に持っていることを忘れないでください。このため、目に見えるプロセス（およびサービスプロセス-さらに）の破壊を自分の目で見ることはできませんが、決して起こらない。



通常、テストにはできるだけ弱いデバイスを購入することをお勧めしますが、フラッグシップでも、アプリケーションが破壊された場合の動作をテストできます 。 アプリケーションを（そのすべてのプロセスとともに）破棄するには、次の手順を実行します。

 adb shell am force-stop com.example.packagename
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

複数のプロセスがある場合、最初に次のコマンドの結果の2番目の列（つまり最初の数字）を見て、必要なプロセスのPIDを見つけることができます。

 adb shell ps | grep com.example.packagename
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、このプロセスを叩きます：

 adb shell kill PID
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、メモリ制限が発生するかどうかに関係なく、アプリケーションがほとんどのデバイスで正しく動作することを保証する最初のステップになります。