プロセスとアプリのライフサイクル
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
ほとんどの場合、どの Android アプリケーションも独自の Linux プロセスで動作します。このプロセスは、アプリケーションのコードの一部を実行する必要があるときに作成され、システムが他のアプリケーションで使用するためにメモリを再利用する必要があるときまで残ります。
Android の基本的な特徴のうち、一般的ではないものとして、アプリケーション プロセスの存続期間がアプリケーションによって直接制御されないということがあります。存続期間は、システムによって、実行中であることが認識されているアプリケーション、ユーザーにとっての重要度、システム全体での空きメモリ量の組み合わせから決定されます。
アプリケーション デベロッパーにとっては、さまざまなアプリケーション コンポーネント(特に、Activity
、Service
、BroadcastReceiver
)がアプリケーションのプロセスの存続期間にどのように影響するかを理解することが重要です。これらのコンポーネントを正しく使用しないと、重要な作業を行っている間にシステムがアプリケーション プロセスを終了させる場合があります。
プロセスのライフサイクルに関連する不具合としてよくあるのは、BroadcastReceiver
が BroadcastReceiver.onReceive()
メソッド内で Intent
を受け取る際にスレッドを開始し、関数から戻ってしまう場合です。関数から戻ると、BroadcastReceiver
が無効になったため、ホストプロセスが不要になった(プロセス中で他のアプリケーション コンポーネントが有効でない場合)とシステムにみなされます。
したがって、システムはメモリを再請求するためにいつでもプロセスを終了でき、プロセスで実行中の生成済みスレッドを終了させます。この問題への対応策は、BroadcastReceiver
から JobService
のスケジュールを設定するのが一般的です。そうすることで、プロセス内に有効な実行中処理が残っていることをシステムに認識させられます。
メモリが不足している場合に終了させるプロセスを決定するために、Android は実行中のコンポーネントとその状態に基づいて、各プロセスの重要度を階層中に位置付けます。プロセスには、次のタイプがあります(重要度の高い順)。
- フォアグラウンド プロセス: ユーザーが現在行っている作業に必要なプロセスです。さまざまなアプリケーション コンポーネントが、さまざまな方法で、そのプロセスをフォアグラウンドとみなされるようにします。次のいずれかの条件が満たされている場合、プロセスはフォアグラウンドであるとみなされます。
このようなプロセスはシステム内にわずかしか存在せず、空きメモリが非常に少なくプロセスを実行し続けることができない場合にのみ、最後の手段として終了させられます。通常、この時点でデバイスはメモリ ページング状態になっているため、この動作はユーザー インターフェースの応答性を維持するために必要です。
- 表示プロセス: 処理がユーザーに認識されているプロセスです。そのため、終了させるとユーザー エクスペリエンスが大きく損なわれます。以下の条件に該当する場合、表示プロセスとみなされます。
- フォアグラウンドではないが、画面上でユーザーに表示されている
Activity
を実行している(onPause()
メソッドが呼び出されている)。たとえば、フォアグラウンドの Activity
がダイアログとして表示されており、以前の Activity
の背後に表示することが許可されている場合に起こります。
Service.startForeground()
を使って、フォアグラウンド サービスとして実行している Service
がある(サービスをユーザーが認識しているか、実質的に見えているものとして扱うように要求します)。
- ライブ壁紙やインプット メソッド サービスなど、ユーザーに認識されている特定の機能のためにシステムが使用しているサービスをホストしている。
実行中のプロセスの数は、フォアグラウンド プロセスほど制限されていませんが、ある程度管理されています。これらのプロセスは、非常に重要であるとみなされ、すべてのフォアグラウンド プロセスを実行し続けるために必要となる場合を除いて、終了されることはありません。
- サービス プロセス:
startService()
メソッドで開始された Service
を保持しているプロセスです。これらのプロセスはユーザーに直接表示されませんが、通常はユーザーが関心を持つ処理(バックグラウンド ネットワーク データのアップロードやダウンロードなど)を行っています。そのため、フォアグラウンドと表示されているすべてのプロセスを保持するのに十分なメモリがない限り、システムは常にこのようなプロセスを実行し続けます。長時間実行されるサービス(30 分以上など)は重要度が下げられ、プロセスがキャッシュに保存されたリストに追加されるようになります。
長時間実行する必要があるプロセスは、setForeground
で作成できます。厳密な実行時間を必要とする定期的なプロセスの場合は、AlarmManager
でスケジュールできます。詳細については、長時間実行ワーカーのサポートをご覧ください。これにより、メモリリークなどによりリソースを過剰に使用している長時間実行サービスが、システムで優れたユーザー エクスペリエンスを提供できない状況を回避できます。
- キャッシュ済みプロセス: その時点では必要ではなく、他の場所でメモリなどのリソースが必要な場合には自由に終了させることができるプロセスです。正常に動作するシステムでは、これらがリソース管理に関連する唯一のプロセスです。
正常に実行されているシステムには、アプリケーション間の切り替えを効率的に行うため、常に利用可能なキャッシュ済みプロセスが複数あり、必要に応じてキャッシュに保存されたアプリが定期的に強制終了されます。すべてのキャッシュ済みプロセスを終了させ、さらにサービス プロセスの終了を始める必要があるのは、非常に重大な状況が生じた場合のみです。
キャッシュに保存されたプロセスはシステムによっていつでも強制終了される可能性があるため、アプリはキャッシュに保存された状態の間はすべての処理を停止する必要があります。ユーザーにとって重要な処理をアプリで実行する必要がある場合は、上記のいずれかの API を使用して、アクティブなプロセス状態から処理を実行する必要があります。
キャッシュに保存されたプロセスは、多くの場合、ユーザーに表示されていない(onStop()
メソッドが呼び出されて戻った)Activity
インスタンスを 1 つ以上保持します。システムがこのようなプロセスを強制終了するときに Activity
ライフサイクルを正しく実装していれば、そのアプリに戻ったときのユーザー エクスペリエンスに影響はありません。関連するアクティビティが新しいプロセスで再作成されると、以前に保存された状態を復元できます。プロセスがシステムによって強制終了された場合、onDestroy()
が呼び出されるとは限りません。詳しくは、Activity
をご覧ください。
Android 13 以降では、アプリプロセスが上記のアクティブなライフサイクル状態のいずれかに移行するまで、実行時間が制限されるか、実行時間がまったく割り当てられない場合があります。
キャッシュに保存されたプロセスはリストに保持されます。このリストの正確な順序付けポリシーは、プラットフォームの実装の詳細です。通常、ユーザーのホーム アプリケーションをホストしているプロセスや最後に表示したアクティビティなど、より有用なプロセスを他の種類のプロセスより先に保持します。プロセスを終了させるポリシーとして、プロセス数のハードリミット、プロセスをキャッシュに保持できる時間の制限など、他のポリシーも適用できます。
プロセスの重要度付けの方法を決める際には、プロセスで現在有効なすべてのコンポーネントの中で最も重要なレベルに基づいて決定します。各コンポーネントがプロセスとアプリケーションのライフサイクル全体にどのように貢献しているかについて詳しくは、Activity
、Service
、BroadcastReceiver
のドキュメントをご覧ください。
プロセスの他の依存関係に基づいて、プロセスの優先度を上げることもできます。たとえば、プロセス A が、プロセス B の Context.BIND_AUTO_CREATE
フラグの付いた Service
にバインドされているか、プロセス B の ContentProvider
を使用している場合、プロセス B の重要度は最低でもプロセス A と同じになります。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[null,null,["最終更新日 2025-07-27 UTC。"],[],[],null,["# Processes and app lifecycle\n\nIn most cases, every Android application runs in its own Linux process.\nThis process is created for the application when some of its code needs to\nrun and remains running until the system needs to reclaim its memory for use\nby other applications and it is no longer needed.\n\nAn unusual and fundamental feature of Android is that an application process's\nlifetime *isn't* directly controlled by the application itself.\nInstead, it is determined by the system through a combination of the parts of the application\nthat the system knows are running, how important these things are to the user,\nand how much overall memory is available in the system.\n\nIt is important that\napplication developers understand how different application components\n(in particular [Activity](/reference/android/app/Activity), [Service](/reference/android/app/Service),\nand [BroadcastReceiver](/reference/android/content/BroadcastReceiver)) impact the lifetime\nof the application's process. **Not using these components correctly can\nresult in the system killing the application's process while it is doing\nimportant work.**\n\nA common example of a process lifecycle bug is a\n`BroadcastReceiver` that starts a thread when it\nreceives an `Intent` in its [BroadcastReceiver.onReceive()](/reference/android/content/BroadcastReceiver#onReceive(android.content.Context, android.content.Intent))\nmethod and then returns from the function. Once it returns, the system\nconsiders the `BroadcastReceiver` to no longer be active, and its hosting\nprocess to no longer be needed, unless other application components are active in\nit.\n\n\nSo, the system can kill the process at any time to reclaim memory, and in doing so,\nit terminates the spawned thread running in the process. The solution to this problem\nis typically to schedule a [JobService](/reference/android/app/job/JobService)\nfrom the `BroadcastReceiver` so the\nsystem knows that there is active work occurring in the process.\n\nTo determine which processes to kill when low on memory, Android\nplaces each process into an importance hierarchy based on the components running in\nthem and the state of those components. In order of importance, these process types are:\n\n1. A **foreground process** is one that is required for what the user is currently doing. Various application components can cause its containing process to be considered foreground in different ways. A process is considered to be in the foreground if any of the following conditions hold:\n - It is running an [Activity](/reference/android/app/Activity) at the top of the screen that the user is interacting with (its [onResume()](/reference/android/app/Activity#onResume()) method has been called).\n - It has a [BroadcastReceiver](/reference/android/content/BroadcastReceiver) that is currently running (its [BroadcastReceiver.onReceive()](/reference/android/content/BroadcastReceiver#onReceive(android.content.Context, android.content.Intent)) method is executing).\n - It has a [Service](/reference/android/app/Service) that is currently executing code in one of its callbacks ([Service.onCreate()](/reference/android/app/Service#onCreate()), [Service.onStart()](/reference/android/app/Service#onStart(android.content.Intent, int)), or [Service.onDestroy()](/reference/android/app/Service#onDestroy())).\n2. There are only ever a few such processes in the system, and these are only killed as a last resort if memory is so low that not even these processes can continue to run. Generally, if this happens the device has reached a memory paging state, so this action is required to keep the user interface responsive.\n3. A **visible process** is doing work that the user is currently aware of, so killing it has a noticeable negative impact on the user experience. A process is considered visible in the following conditions:\n - It is running an [Activity](/reference/android/app/Activity) that is visible to the user on-screen but not in the foreground (its [onPause()](/reference/android/app/Activity#onPause()) method has been called). This might occur, for example, if the foreground `Activity` is displayed as a dialog that lets the previous `Activity` be seen behind it.\n - It has a [Service](/reference/android/app/Service) that is running as a foreground service, through [Service.startForeground()](/reference/android/app/Service#startForeground(int, android.app.Notification)) (which asks the system to treat the service as something the user is aware of, or essentially as if it were visible).\n - It is hosting a service that the system is using for a particular feature that the user is aware of, such as a live wallpaper or an input method service.\n\n The number of these processes running in the system is less bounded than foreground\n processes, but still relatively controlled. These processes are\n considered extremely important and aren't killed unless doing so is\n required to keep all foreground processes running.\n4. A **service process** is one holding a [Service](/reference/android/app/Service) that has been started with the [startService()](/reference/android/content/Context#startService(android.content.Intent)) method. Though these processes are not directly visible to the user, they are generally doing things that the user cares about (such as background network data upload or download), so the system always keeps such processes running unless there is not enough memory to retain all foreground and visible processes.\n\n Services that have been running for a long time (such as 30 minutes or more) might be\n demoted in importance to let their process drop to the cached list.\n\n Processes that do need to be run over a long period can be created with\n [setForeground](/reference/kotlin/androidx/work/CoroutineWorker#setForeground(androidx.work.ForegroundInfo)).\n If it is a periodic process that requires strict time of execution, it can be\n scheduled through the [AlarmManager](/reference/android/app/AlarmManager).\n For more information, refer to [Support for long-running workers](/topic/libraries/architecture/workmanager/advanced/long-running).\n This helps avoid situations where long-running services that use excessive resources, for\n example, by leaking memory, prevent the system from delivering a good user experience.\n5. A **cached process** is one that is not currently needed, so the system is free to kill it as needed when resources like memory are needed elsewhere. In a normally behaving system, these are the only processes involved in resource management.\n\n \u003cbr /\u003e\n\n A well-running system has multiple cached processes always available, for efficient\n switching between applications, and regularly kills the cached apps as needed.\n Only in very critical situations does the system get to a point where\n all cached processes are killed and it must start killing service processes.\n\n Since cached processes can be killed by the system at any time, apps should cease all work while\n in the cached state. If user-critical work must be performed by the app,\n it should use one of the above APIs to run work from an active process state.\n\n Cached processes often hold one or more [Activity](/reference/android/app/Activity) instances\n that are not currently visible to the user (their\n [onStop()](/reference/android/app/Activity#onStop()) method has been called and has returned).\n Provided they implement their `Activity` lifecycle correctly when the system\n kills such processes, it doesn't impact the user's experience when returning to that app.\n It can restore the previously saved state when the associated activity recreates in\n a new process. Be aware that [onDestroy()](/guide/components/activities/activity-lifecycle#ondestroy)\n is not guaranteed to be called in the case that a process is killed by the system.\n For more details, see [Activity](/reference/android/app/Activity).\n\n Starting in Android 13, an app process may receive limited or no execution time until it enters\n one of the above active lifecycle states.\n\n Cached processes are kept in a list. The exact ordering policy for this list\n is an implementation detail of the platform. Generally, it tries to keep more\n useful processes, such as those hosting the user's home application or the last activity the user saw,\n before other types of processes. Other policies for killing processes can also\n be applied, like setting hard limits on the number of processes allowed or limiting the amount of\n time a process can stay continually cached.\n\nWhen deciding how to classify a process, the system bases its decision on the most\nimportant level found among all the components currently active in the process.\nSee the [Activity](/reference/android/app/Activity), [Service](/reference/android/app/Service), and\n[BroadcastReceiver](/reference/android/content/BroadcastReceiver) documentation for more detail on how\neach of these components contributes to the overall lifecycle of a process and of\nthe application.\n\nA process's priority might also be increased based on other dependencies\na process has to it. For example, if process A has bound to a\n[Service](/reference/android/app/Service) with\nthe [Context.BIND_AUTO_CREATE](/reference/android/content/Context#BIND_AUTO_CREATE)\nflag or is using a\n[ContentProvider](/reference/android/content/ContentProvider) in process B, then process B's\nclassification is always at least as important as process A's."]]