Android SDK 1.5 Chinese version (Application basics-4)

1.3 processes and threads

When the first component of an application needs to run, Android starts a Linux Process and a single execution thread for it. By default, all components of the application run in this process and thread.

However, you can also schedule components to run in other processes and derive other threads from any process.

1.3.1 Process

The processes run by the component are controlled by the manifest file. Component elements -- <activity>, <service>, <javaser>, and <provider> each have a process attribute to specify the process that the component wants to run. You can set these attributes to allow each component to run in its own process, or some components share a process, while other components have independent processes. You can also set components of different applications to run in the same process. Make the components of the application share the same Linux User ID and grant the same permissions. <Application> An element also has a process attribute to set the default attribute values of all components.

All component instances are located in the main thread of the specified process, and system calls to these components will also be distributed by that thread. Generally, no threads are created for each instance. Therefore, some methods always run in the main thread of the process. These methods include response to user actions such as View. onKeyDown () and the lifecycle notifications to be discussed in the subsequent component lifecycle section. This means that when a component is called by the system, it should not take a long time or block operations (such as network-related operations or cyclic computing ), this will block the running of other components in the same process. As described in the following thread section, a separate thread is derived for these long operations for processing.

When the available memory is insufficient and another process serving the user needs more memory, Android may sometimes close a process. The applications running in this process are also destroyed. When such components are required for processing again, the process will be re-created for them.

When deciding which process to end, Android will measure their relative importance to users. For example, a process that is visible to the user is more likely to close a process that is not visible to the user. Therefore, deciding whether to close a process depends on the component Status in the process. These statuses will be described in the subsequent component lifecycle section.

1.3.2 thread

Although the application can be restricted to a single process, sometimes we still need to derive a thread to process Background tasks. Because the user interface must respond to user operations in a very timely manner, the thread controlling the Activity should not process time-consuming operations such as network downloads. All tasks that cannot be completed instantly should be arranged in different threads.

A Thread is created by a standard Java Thread object in the code. Android provides many classes used to manage threads: logoff is used to run a message loop in a thread, Handler is used for message processing, and HandlerThread is used to create a thread with a message loop.

1.3.3 Remote Procedure Call

Android has a lightweight Remote Procedure Call (RPC) mechanism: that is, to call a method locally, but to execute a remote (in other processes) process, and then return the result to the caller. In this case, the method call and its ancillary data need to be decomposed in a way that the operating system can understand, and transmitted from the local process and address space to the remote process and address space, and re-assemble and call it there. The return value must be transmitted in the opposite direction. Android provides all the code required to complete these tasks, so that we can concentrate on defining and implementing the RPC interface itself.

The RPC interface can only contain methods. All methods are executed in synchronous mode even if no return value is returned (the local method is blocked until the remote method ends ).

Simply put, this mechanism works like this: first, we use a simple IDL (Interface Definition Language) to declare the RPC interface to be implemented. Then, use the aidl tool to generate a Java interface definition for the Declaration. This definition must be visible to both local and remote processes. It contains two internal classes, as shown in:

 

The Inner class contains all the code required to manage the interface called remotely using the interface declared by IDL. Both internal classes implement the IBinder interface. One is used internally by the system, and the code we write can ignore it; the other is called Stub, which extends the Binder class. In addition to implementing the internal code of the IPC call, it also includes the declaration of the method we declare in the RPC interface. We should write a Stub subclass as shown in to implement these methods.

Generally, a remote process is managed by a service (because the service can notify the System of the process and its connection information to other processes ). It contains the interface file generated by the aidl tool and the Stub subclass that implements the RPC method. The client only needs to include the interface file generated by the aidl tool.

The following describes how to establish a connection between a service and its client:

The client (local) of the v service should implement the onServiceConnected () and onServiceDisconnected () methods. In this way, you will receive a notification when the connection to the remote service is successfully established or disconnected. They should call bindService () to establish a connection.

V and the service should implement the onBind () method to accept or reject the connection. It depends on the Intent it receives (the Intent passed to bindService ). If the connection is accepted, an instance of the Stub subclass is returned.

If the service accepts the connection, Android will call the onServiceConnected () method of the client and pass it to an IBinder object, which is the proxy of the Stub subclass managed by the Service. Through this proxy, the client can call the remote service.

Some details of the RPC mechanism are ignored. For more information, see the description of the Designing a Remote Interface Using AIDL and IBinder classes.

1.3.4 thread security method

In some cases, the methods we implement may be called by multiple threads, so they must be thread-safe.

For methods that can be remotely called in the RPC mechanism discussed in the previous section, this must be considered first. If the call to the method implemented in an ibinder object comes from the process of the ibinder object, this method will be executed in the caller's thread. However, if this call comes from other processes, this method will run in the thread selected in a thread pool, and this thread pool will be managed by Android, and it exists in the same process as ibinder. This method is not executed in the main thread of the process. Conversely, the onbind () method of the service should be called by the main thread of the service process, and the object returned by onbind () is implemented (for example, a stub subclass that implements the RPC method) will be called by the thread in the pool. Because the service can have multiple clients, and at the same time, there will also be threads in multiple pools calling the same ibinder method. Therefore, the ibinder method must be thread-safe.

Similarly, content providers may also accept data requests from other processes. Although the contentresolver and contentprovider classes hide the management details of the interactive communication process, the contentprovider method query (), insert (), delete (), update (), and GetType () will respond to these requests, these methods are called from the thread pool covered by the process of the content provider, rather than the main thread of the process. Therefore, these methods may be called by multiple threads at the same time, and they must also be thread-safe.