Application task process and thread analysis for the Android application model

  • 2020-12-19 21:12:31
  • OfStack

This article describes the APPLICATIONS, tasks, processes, and threads of the Android application model. To share for your reference, the details are as follows:

In most operating systems, there is a strict one-to-one relationship between the executable image hosted by the application (such as.exe in Windows), the processes it runs, and the ICONS and applications that interact with the user. In the Android system, these associations are much looser. And it's important to understand how the concepts fit together.

Because of the inherent flexibility of Android applications, there are a few basic terms to understand when implementing these different aspects:

1 Android package (.apk) file, which contains 1 application code and resources. This is the application distribution and download file that users use to install the application on their device.
1 task 1 generally refers to the user as a bootable application: usually the task has an accessible icon on the desktop (home screen) and can be switched to the foreground.
A process is a running application code of the underlying core process. Usually all code in.apk runs in a proprietary process. However, the process tag can also be used to specify where the code runs, either for the entire.apk or for the individual activity activity, receiver receiver, service or provider provider, component.

task

The key point here is that when users see an "application", they are actually dealing with a task. If you have just created a contains a number of activities. apk, one of which is the top entry point (through action android. intent. action. MAIN intent filters intent - filter and category android intent. category. LAUNCHER), then this fact will be for you. apk create a task, and from there you start any activity will be run as a part of the task.

1 task, then, from the user's point of view is your application; From the application developer's point of view, it is an activity, or an activity stack, that one or more users have experienced and have not closed in that task. 1 new task is created by starting 1 activity intent with the Intent.es42EN_ACTIVITY_ES44en_ES45en flag; This 1 intent will be used as the root intent of the task, defining what the task is. Any activity that is not started with this flag will run in the same task as the activity that started it (unless the activity has requested a special start mode, which will be discussed later). Tasks can be rescheduled: If you use the FLAG_ACTIVITY_NEW_TASK flag but there is already a task running with this intent, the active stack for the current task will be switched to the foreground instead of starting a new task.

FLAG_ACTIVITY_NEW_TASK must be used with caution: using it means that, from the user's point of view, a new application is started. If this is not the behavior you expect, you should not create a new task. Also, you should use the new task tag only if the user can return from the desktop to his original place and launch with the same intent as a new task. Otherwise, if the user presses the Desktop (HOME) key in a task you have started instead of the back (BACK) key, your task and its activities will be placed behind the desktop and there is no way to switch back.

Task sharing Affinity

In some cases, Android needs to know which task an activity belongs to even if it is not started into a specific task. This is done through task sharing (Affinities). Task sharing (Affinities) provides a unique static name for the task running one or more activities, and the default task sharing for one activity (Affinity) is the name of the package that implements the activity. This provides the expected standard feature that all activities within a specific.apk package are part of a single user application.

When starting an activity without the Intent.FLAG_ES73en_ES74en_ES75en flag, task sharing affinities does not affect the task that will run the new activity: it always runs in the task that started it. However, if the NEW_TASK flag is used, then affinity will be used to determine whether a task with the same commonality (affinity) already exists. If so, the task will be switched to the front and the new activity will start at the top level of the task.

This feature is most useful when you must use the NEW_TASK flag, especially when launching activities from status bar notifications or desktop shortcuts. As a result, when the user launches your application this way, its current task is switched to the foreground, and the activities that it wants to see are placed at the top.

You can assign your own task-common Affinites to all activities in the.apk package in the application TAB of the Application manifest (Manifest) file, or assign each activity in the activity tag. 1 Some examples of how it can be used are as follows:

If your.ES93en contains high-level applications that multiple users can launch, you may need to specify a different affinities for each activity the user sees. A good naming convention is to extend your.apk package name by appending a colon delimited string. For example, "com.android.contacts".apk can have affinities: "com.android.contacts: Dialer" and "com.android.contacts: ContactsList".
If you are replacing 1 notification, shortcut, or other "internal" activity of an application that can be initiated from outside, you may need to explicitly configure taskAffinity for your alternative activity and 1 sample of the application that you intend to replace. For example, if you want to replace the contacts details view (where users can create and invoke shortcuts), you have to set taskAffinity to "com.android.contacts".

Start mode and start flag

The primary way you control activity and task interactions is through the activity's launchMode property and intention-related flag, flags. These two parameters can cooperate in various ways to control the result of an activity startup, as described in their documentation. Here, we'll look at some common use cases and parameter combinations.

The most common startup mode you will use (in addition to the default standard mode) is singleTop. It doesn't affect the mission; It simply avoids multiple starts at the top of 1 stack with the same 1 activity.

The singleTask startup mode has a significant impact on tasks: it makes the activity always start with a new task (or its existing task brought to the front). Using this pattern requires being careful about how you interact with the rest of the system, as this affects every path in the activity. It should be used only when the activity is in the foreground of the application (that is, the MAIN actions and LAUNCHER categories are supported).

singleInstance startup mode is more professional and should only be used in an entire application that is implemented as one activity.

One of the situations you will often encounter is when another entity (such as SearchManager or NotificationManager) starts your 1 activity. In this case, the ES138en.FLAG_ES140en_ES141en_ES142en tag must be used because the activity is started outside of the task (and the application/task may not exist at all). As mentioned earlier, the standard behavior in this case is to bring the task of matching the new activity affinity to the front and start the new activity on top of it. However, there are other types of behavior that you can implement.

A common approach is to use the ES148en.es149EN_ACTIVITY_ES151en_ES152en flag in conjunction with NEW_TASK. This way, if your task is already running, it will be brought to the foreground, all the other activities in the stack will be cleared except for the root activity, and the root activity's method onNewIntent(Intent) will be called when the intention is started. Note that this activity often uses singleTop or singleTask startup mode when using this method, so that the current instance is given a new intent rather than needing to destroy it and restart a new instance.

Another option you can take is to set the task for the notification activity affinity to an empty string "" (indicating that there is no affinity) and set the finishOnBackground attribute. This approach is useful if you want the notification to take the user to a separate activity that describes it, rather than returning to the task of the application. By specifying this property, the activity will be terminated whether the user leaves it via BACK or HOME; If this property is not specified, pressing the first page causes the activity and its task to remain in the system, and there may be no way to return it.

Be sure to read the documentation on the launchMode attribute and the Intent flag for a detailed description of these options.

process

In Android, processes are all implementation details of the application, not what users usually understand. Its main uses are:

(1) Improve stability or security by placing untrusted or unstable code into another process.
Reduce overhead by running multiple.apks codes in the same 1 process.
By putting heavy code in a separate process to help the system manage resources, the process can be terminated without affecting the rest of the application.

As stated earlier, the process attribute is used to control the running process of specific application components, note that this property cannot be used for violation of system security: if there are two don't share the same user ID. apks try to run in the same process of 1, it will not be allowed, on the contrary will create different processes for each one.

See the Security documentation for more information on security restrictions.

thread

Each process contains one or more threads. For the most part, Android avoids creating additional threads in the process to keep the application single-threaded unless it creates its own threads. An important result is that all calls to active Activity, broadcast receiver BroadcastReceiver, and service Service instances are created by the main thread of this process.

Note that new threads are not created for each active, broadcast receiver, service, or content provider (ContentProvider) instance: the components of these applications are instantiated in the process (all are processed in the same process, unless otherwise noted) and are actually the main thread of the process. This means that no component (including the service) will perform remote or blocking operations (like network calls or compute loops) when called by the system, because this will block all other components in the process. You can use the standard thread class Thread or the HandlerThread convenience class of Android to perform remote operations on other threads.

Here are a few important exceptions to this thread rule:

Calls to the interface implemented by IBinder or IBinder are distributed by the thread pool of the calling thread or local process (if the call comes from another process) rather than the main thread of their process. In special cases, IBinder for 1 service can be invoked this way. (Although calling the methods in the service is already done in the main thread.) This means that the implementation of the IBinder interface must have a thread-safe method so that any thread can access it simultaneously.
Calls to the main methods of ContentProvider are distributed by the calling thread or the main thread, as in IBinder1. The method specified is recorded in the content provider's class. This means that these methods must be implemented in a thread-safe mode so that any other thread can access it at the same time.
The calls in a view and its subclasses are made by the thread running the view. Normally, this is used as the main thread of the process, and if you create a thread and display a window, the inherited window view will be launched from that thread.

I hope this article has been helpful in Android programming.


Related articles: