Süreçler ve uygulama yaşam döngüsü
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Çoğu durumda her Android uygulaması kendi Linux işleminde çalışır.
Bu işlem, kodunun bir kısmının çalışması gerektiğinde uygulama için oluşturulur ve sistem diğer uygulamalar tarafından kullanılmak üzere belleğini geri aldığında ve artık ihtiyaç duyulmadığında çalışmaya devam eder.
Android'in alışılmadık ve temel özelliklerinden biri, uygulama sürecinin ömrünün doğrudan uygulama tarafından kontrol edilmemesidir.
Bunun yerine, sistem tarafından uygulamanın çalıştığı bilinen kısımların, bu kısımların kullanıcı için ne kadar önemli olduğunun ve sistemde ne kadar genel bellek bulunduğunun bir kombinasyonuyla belirlenir.
Uygulama geliştiricilerin, farklı uygulama bileşenlerinin (özellikle Activity, Service ve BroadcastReceiver) uygulama sürecinin ömrünü nasıl etkilediğini anlaması önemlidir. Bu bileşenleri doğru şekilde kullanmamak, sistem önemli bir iş yaparken uygulamanın sürecini sonlandırabilir.
Süreç yaşam döngüsü hatası için yaygın bir örnek, BroadcastReceiver.onReceive() yönteminde Intent aldığında bir iş parçacığı başlatan ve ardından işlevden dönen bir BroadcastReceiver'tir. Bu işlem tamamlandıktan sonra sistem, BroadcastReceiver'ün artık etkin olmadığını ve içinde başka uygulama bileşenleri etkin olmadığı sürece barındırma işlemine artık ihtiyaç olmadığını düşünür.
Bu nedenle sistem, belleği geri almak için işlemi istediği zaman sonlandırabilir ve bu işlem sırasında, işlemde çalışan oluşturulan iş parçacığını sonlandırır. Bu sorunun çözümü genellikle, sistemin süreçte etkin bir çalışma olduğunu bilmesi için BroadcastReceiver'dan bir JobService planlamaktır.
Android, bellek azaldığında hangi işlemlerin sonlandırılacağını belirlemek için her bir işlemi, çalıştırılan bileşenlere ve bu bileşenlerin durumuna göre bir önem hiyerarşisine yerleştirir. Önem sırasına göre bu işlem türleri şunlardır:
- Ön plan işlemi, kullanıcının şu anda yaptığı işlem için gereken işlemdir. Çeşitli uygulama bileşenleri, içeren sürecinin farklı şekillerde ön planda kabul edilmesine neden olabilir. Aşağıdaki koşullardan herhangi biri geçerliyse bir işlemin ön planda olduğu kabul edilir:
Sistemde bu tür yalnızca birkaç işlem bulunur ve bunlar yalnızca bellek bu işlemlerin bile çalışmasını sürdüremeyecek kadar düşük olduğunda son çare olarak sonlandırılır. Genellikle bu durum, cihazın bellek sayfalama durumuna ulaştığını gösterir. Bu nedenle, kullanıcı arayüzünün duyarlı kalması için bu işlem gereklidir.
- Görünür bir işlem, kullanıcının şu anda farkında olduğu bir iş yapıyordur. Bu nedenle, işlemin sonlandırılması kullanıcı deneyiminde belirgin bir olumsuz etkiye sahiptir. Bir işlem aşağıdaki durumlarda görünür olarak kabul edilir:
- Kullanıcının ekranda görebildiği ancak ön planda olmayan bir
Activity çalıştırıyor (onPause() yöntemi çağrıldı). Bu durum, örneğin ön plandaki Activity, önceki Activity'ün arkasında görülebilmesini sağlayan bir iletişim kutusu olarak gösterilirse ortaya çıkabilir.
Service.startForeground() aracılığıyla ön plan hizmeti olarak çalışan bir Service'si vardır (bu, sistemden hizmeti kullanıcının farkında olduğu veya görünür olduğu şekilde işleme koymasını ister).- Sistem, kullanıcının bildiği belirli bir özellik (ör. canlı duvar kağıdı veya giriş yöntemi hizmeti) için kullandığı bir hizmeti barındırıyor olabilir.
Sistemde çalışan bu işlemlerin sayısı, ön plan işlemlerine kıyasla daha az sınırlıdır ancak yine de nispeten kontrol altındadır. Bu işlemler son derece önemli kabul edilir ve tüm ön plan işlemlerinin çalışmaya devam etmesi için gerekli olmadığı sürece sonlandırılmaz.
- Hizmet işlemi,
startService() yöntemiyle başlatılmış bir Service içeren işlemdir. Bu işlemler kullanıcı tarafından doğrudan görülemese de genellikle kullanıcının önemsediği işlemleri (ör. arka planda ağ verisi yükleme veya indirme) gerçekleştirir. Bu nedenle, tüm ön plan ve görünür işlemleri tutacak yeterli bellek olmadığı sürece sistem bu tür işlemleri her zaman çalışır durumda tutar.
Uzun süredir (ör. 30 dakika veya daha uzun) çalışan hizmetler, işlemlerinin önbelleğe alınmış listeye düşmesine izin vermek için önem açısından düşürülebilir.
Uzun bir süre boyunca çalıştırılması gereken süreçler setForeground ile oluşturulabilir.
Kesin bir yürütme zamanı gerektiren düzenli bir işlemse AlarmManager aracılığıyla planlanabilir.
Daha fazla bilgi için Uzun süre çalışan çalışanlar için destek başlıklı makaleyi inceleyin.
Bu sayede, aşırı kaynak kullanan uzun süre çalışan hizmetlerin (ör. bellek sızıntısı yaparak) sistemin iyi bir kullanıcı deneyimi sunmasını engellediği durumlar önlenebilir.
- Önbelleğe alınmış bir işlem şu anda ihtiyaç duyulmayan bir işlemdir. Bu nedenle, sistem başka bir yerde bellek gibi kaynaklara ihtiyaç duyduğunda gerektiği gibi bu işlemi sonlandırabilir. Normal şekilde çalışan bir sistemde, kaynak yönetimiyle ilgili tek süreçler bunlardır.
İyi çalışan bir sistemde, uygulamalar arasında verimli geçiş yapmak için her zaman hazır olan birden fazla önbelleğe alınmış işlem bulunur ve gerektiğinde önbelleğe alınmış uygulamalar düzenli olarak kapatılır.
Sistem yalnızca çok kritik durumlarda tüm önbelleğe alınmış işlemlerin sonlandırıldığı ve hizmet işlemlerini sonlandırmaya başladığı bir noktaya gelir.
Önbelleğe alınan işlemler sistem tarafından herhangi bir zamanda sonlandırılabileceğinden, uygulamalar önbelleğe alınmış durumdayken tüm çalışmalarını durdurmalıdır. Uygulamanın kullanıcı için kritik öneme sahip bir işlemi gerçekleştirmesi gerekiyorsa bu işlemi etkin bir işlem durumunda çalıştırmak için yukarıdaki API'lerden birini kullanmalıdır.
Önbelleğe alınan işlemler genellikle şu anda kullanıcı tarafından görülemeyen bir veya daha fazla Activity örneği içerir (onStop() yöntemleri çağrılmış ve döndürülmüştür).
Sistem bu tür işlemleri sonlandırdığında Activity yaşam döngüsünü doğru şekilde uyguladıkları sürece, kullanıcının ilgili uygulamaya geri dönerken yaşadığı deneyim etkilenmez. İlişkili etkinlik yeni bir işlemde yeniden oluşturulduğunda daha önce kaydedilen durum geri yüklenebilir. Bir işlemin sistem tarafından sonlandırılması durumunda onDestroy() işlevinin çağrılmasının garanti edilmediğini unutmayın.
Daha fazla bilgi için Activity başlıklı makaleyi inceleyin.
Android 13'ten itibaren, bir uygulama işlemi yukarıdaki etkin yaşam döngüsü durumlarından birine girene kadar sınırlı veya hiç yürütme süresi alamayabilir.
Önbelleğe alınan işlemler bir listede tutulur. Bu listenin tam sıralama politikası, platformun uygulama ayrıntılarından biridir. Genellikle, kullanıcının ana ekran uygulamasını veya kullanıcının gördüğü son etkinliği barındıran işlemler gibi daha yararlı işlemleri diğer işlem türlerinden önce tutmaya çalışır. İzin verilen işlem sayısına katı sınırlar belirleme veya bir işlemin sürekli olarak önbelleğe alınabileceği süreyi sınırlama gibi, işlemleri sonlandırmaya yönelik başka politikalar da uygulanabilir.
Sistem, bir işlemin nasıl sınıflandırılacağına karar verirken şu anda işlemde etkin olan tüm bileşenler arasında bulunan en önemli düzeye dayanır.
Bu bileşenlerin her birinin bir sürecin ve uygulamanın genel yaşam döngüsüne nasıl katkıda bulunduğu hakkında daha fazla bilgi için Activity, Service ve BroadcastReceiver dokümanlarına bakın.
Bir işlemin önceliği, işlemin sahip olduğu diğer bağımlılıklara göre de artırılabilir. Örneğin, A işlemi Context.BIND_AUTO_CREATE işaretiyle bir Service'e bağlandıysa veya B işleminde bir ContentProvider kullanıyorsa B işleminin sınıflandırması her zaman en az A işleminin sınıflandırması kadar önemlidir.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
