Processes and Threads
2014-05-09 13:58
369 查看
The manifest entry for each type of component element—
and
that can specify a process in which that component should run. You can set this attribute so that each component runs in its own process or so that some components share a process while others do not. You can also set
that components of different applications run in the same process—provided that the applications share the same Linux user ID and are signed with the same certificates.
The
supports an
Foreground process
A process that is required for what the user is currently doing. A process is considered to be in the foreground if any of the following conditions are true:
It hosts an
the user is interacting with (the
has been called).
It hosts a
bound to the activity that the user is interacting with.
It hosts a
running "in the foreground"—the service has called
It hosts a
executing one of its lifecycle callbacks (
or
It hosts a
executing its
Generally, only a few foreground processes exist at any given time. They are killed only as a last resort—if memory is so low that they cannot all continue to run. Generally, at that point, the device has reached
a memory paging state, so killing some foreground processes is required to keep the user interface responsive.
Visible process
A process that doesn't have any foreground components, but still can affect what the user sees on screen. A process is considered to be visible if either of the following conditions are true:
It hosts an
is not in the foreground, but is still visible to the user (its
has been called). This might occur, for example, if the foreground activity started a dialog, which allows the previous activity to be seen behind it.
It hosts a
bound to a visible (or foreground) activity.
A visible process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.
Service process
A process that is running a service that has been started with the
and does
4000
not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing music in the background or downloading data on
the network), so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes.
Background process
A process holding an activity that's not currently visible to the user (the activity's
has been called). These processes have no direct impact on the user experience, and the system can kill them at any time to reclaim memory for a foreground, visible, or service process. Usually there are many background processes running, so they are kept
in an LRU (least recently used) list to ensure that the process with the activity that was most recently seen by the user is the last to be killed. If an activity implements its lifecycle methods correctly, and saves its current state, killing its process
will not have a visible effect on the user experience, because when the user navigates back to the activity, the activity restores all of its visible state. See the Activities document
for information about saving and restoring state.
Empty process
A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The
system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.
is also the thread in which your application interacts with components from the Android UI toolkit (components from the
As such, the main thread is also sometimes called the UI thread.
The system does not create a separate thread for each instance of a component. All components that run in the same process are instantiated in the UI thread, and system calls to each component are dispatched from that thread. Consequently, methods
that respond to system callbacks (such as
report user actions or a lifecycle callback method) always run in the UI thread of the process.
<activity>,
<service>,
<receiver>,
and
<provider>—supports an
android:processattribute
that can specify a process in which that component should run. You can set this attribute so that each component runs in its own process or so that some components share a process while others do not. You can also set
android:processso
that components of different applications run in the same process—provided that the applications share the same Linux user ID and are signed with the same certificates.
The
<application>element also
supports an
android:processattribute, to set a default value that applies to all components.
Foreground process
A process that is required for what the user is currently doing. A process is considered to be in the foreground if any of the following conditions are true:
It hosts an
Activitythat
the user is interacting with (the
Activity's
onResume()method
has been called).
It hosts a
Servicethat's
bound to the activity that the user is interacting with.
It hosts a
Servicethat's
running "in the foreground"—the service has called
startForeground().
It hosts a
Servicethat's
executing one of its lifecycle callbacks (
onCreate(),
onStart(),
or
onDestroy()).
It hosts a
BroadcastReceiverthat's
executing its
onReceive()method.
Generally, only a few foreground processes exist at any given time. They are killed only as a last resort—if memory is so low that they cannot all continue to run. Generally, at that point, the device has reached
a memory paging state, so killing some foreground processes is required to keep the user interface responsive.
Visible process
A process that doesn't have any foreground components, but still can affect what the user sees on screen. A process is considered to be visible if either of the following conditions are true:
It hosts an
Activitythat
is not in the foreground, but is still visible to the user (its
onPause()method
has been called). This might occur, for example, if the foreground activity started a dialog, which allows the previous activity to be seen behind it.
It hosts a
Servicethat's
bound to a visible (or foreground) activity.
A visible process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.
Service process
A process that is running a service that has been started with the
startService()method
and does
4000
not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing music in the background or downloading data on
the network), so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes.
Background process
A process holding an activity that's not currently visible to the user (the activity's
onStop()method
has been called). These processes have no direct impact on the user experience, and the system can kill them at any time to reclaim memory for a foreground, visible, or service process. Usually there are many background processes running, so they are kept
in an LRU (least recently used) list to ensure that the process with the activity that was most recently seen by the user is the last to be killed. If an activity implements its lifecycle methods correctly, and saves its current state, killing its process
will not have a visible effect on the user experience, because when the user navigates back to the activity, the activity restores all of its visible state. See the Activities document
for information about saving and restoring state.
Empty process
A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The
system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.
Threads
When an application is launched, the system creates a thread of execution for the application, called "main." This thread is very important because it is in charge of dispatching events to the appropriate user interface widgets, including drawing events. Itis also the thread in which your application interacts with components from the Android UI toolkit (components from the
android.widgetand
android.viewpackages).
As such, the main thread is also sometimes called the UI thread.
The system does not create a separate thread for each instance of a component. All components that run in the same process are instantiated in the UI thread, and system calls to each component are dispatched from that thread. Consequently, methods
that respond to system callbacks (such as
onKeyDown()to
report user actions or a lifecycle callback method) always run in the UI thread of the process.
相关文章推荐
- 【Android 官方文档】翻译Android官方文档 Processes and Threads(五)
- Processes and Threads
- Processes and Threads
- The Java™ Tutorials — Concurrency :Processes and Threads 进程和线程
- Jobs, Processes, Threads and Fibers (Windows)
- Processes and Threads 进程和线程
- Communications of Processes and Threads
- Processes and Threads --译-- androidSDK
- Google Android官方文档进程与线程(Processes and Threads)翻译
- Processes and Threads
- Processes and Threads 进程与线程
- Android开发者指南-进程和线程-Processes and Threads[原创译文]
- Managing Processes and Threads in Windows Forms
- PROCESSES AND THREADS
- Processes and Threads
- Java Processes and Threads 进程与线程
- processes, threads and signals in Linux
- Android Guide Dev 之Processes and Threads
- Processes and Threads
- [译]Android应用程序基础 >> 进程和线程(Processes and Threads)