android--Process and Thread 你应该记住的一些事

[1].If an application component starts and there already exists a process for that application (because
another component from the application exists), then the component is started within that process and uses the same thread of execution. However, you can arrange for different components in your application to run in separate processes, and you can create
additional threads for any process.

[2].There
are five levels in the importance hierarchy.

Foreground
process

Visible
process

Service
process

Background
process

Empty
process

[3].Because
a process running a service is ranked higher than a process with background activities, an activity that initiates a long-running operation might do well to start a service for
that operation, rather than simply create a worker thread—particularly if the operation will likely outlast the activity.

[4].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. For instance,
when the user touches a button on the screen, your app's UI thread dispatches the touch event to the widget, which in turn sets its pressed state and posts an invalidate request to the event queue. The UI thread dequeues the request and notifies the widget
that it should redraw itself.

[5].

Additionally, the Android UI toolkit is not thread-safe. So, you must not manipulate your UI from a worker thread—you must do all manipulation to your user interface from the UI thread. Thus, there are simply two rules to Android's single thread model:
Do not block the UI thread
Do not access the Android UI toolkit from outside the UI thread

[6].

 Android offers several ways to access the UI thread from other threads. Here is a list of methods that can help:

Activity.runOnUiThread(Runnable)

View.post(Runnable)

View.postDelayed(Runnable,
long)

To handle more complex interactions with a worker thread, you might consider using a 

Handler

 in
your worker thread, to process messages delivered from the UI thread. Perhaps the best solution, though, is to extend the 

AsyncTask

 class,
which simplifies the execution of worker thread tasks that need to interact with the UI.

[7].To
use it, you must subclass 

AsyncTask

 and
implement the 

doInBackground()

 callback
method, which runs in a pool of background threads. 

[8].Similarly,
a content provider can receive data requests that originate in other processes. Although the

ContentResolver

 and 

ContentProvider

 classes
hide the details of how the interprocess communication is managed, 

ContentProvider

 methods
that respond to those requests—the methods 

query()

, 

insert()

,

delete()

, 

update()

,
and 

getType()

—are
called from a pool of threads in the content provider's process, not the UI thread for the process. Because these methods might be called from any number of threads at the same time, they too must be implemented to be thread-safe.

[9].Android
offers a mechanism for interprocess communication (IPC) using remote procedure calls (RPCs), in which a method is called by an activity or other application component, but executed remotely (in another process), with any result returned back to the caller.
This entails decomposing a method call and its data to a level the operating system can understand, transmitting it from the local process and address space to the remote process and address space, then reassembling and reenacting the call there. Return values
are then transmitted in the opposite direction. Android provides all the code to perform these IPC transactions, so you can focus on defining and implementing the RPC programming interface.