The Android multi-process must be noted about the Android process.

The Android multi-process must be noted about the Android process.

Many projects may have a custom Application, which performs initialization operations and metadata-based data storage. If the program defines the remote service (android: process = ": remote "), the Application will be instantiated multiple times, each process is instantiated once, so onCreate in the Application will be executed multiple times, this is certainly unnecessary, especially when Application bind is a Service.

Because Application is the entry to an Application and cannot be defined by multiple ides, an error is reported when multiple ides are defined in AndroidMainfest. xml. If you need to customize the Application, you can use the process name in the Custom Application to identify the process and then perform corresponding logic processing.

Method for obtaining the process name:

　　 @Nullable    public static String getProcessName(Context context, int pid){        ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);        List<ActivityManager.RunningAppProcessInfo> runningApps = am.getRunningAppProcesses();        if (runningApps != null && !runningApps.isEmpty()) {            for (ActivityManager.RunningAppProcessInfo procInfo : runningApps) {                if (procInfo.pid == pid) {                    return procInfo.processName;                }            }        }        return null;    }

 

 

In addition, I sorted out some Application and process-related knowledge:

1. Relationship between Application, Task, and Activity:

 

There is no need to make a text description, a clear relationship diagram.

 

2. Process Priority (Level 5 ):

2. 1. Foreground process

The frontend process is a necessary process for the user to do the current thing. If one of the following conditions is met, a process is considered at the frontend:

1. The process holds an Activity that is interacting with the user (the Activity is in the onResume () State ).

2. The process holds a Service, which is bound to the Activity that the user is interacting.

3. The process holds a Service, which runs on the frontend, that is, it callsstartForeground().

4. The process holds a Service, which is executing its lifecycle callback function (onCreate(),onStart(), OronDestroy()).

5. The process holds a BroadcastReceiver, Which is executing itsonReceive()Method.

Killing the foreground process requires user interaction because the foreground process has the highest priority.

 

2. Visible process

If a process does not contain any front-end components, but still affects what you can see on the screen, it is a visible process.

It can be seen that the process meets one of the following conditions:

1. The process holds an Activity, which is not in the foreground, but is still visible to the user (in the onPause () status after the onStop () call ).

This happens. For example, the foreground activity opens a dialog box, so that the activity is visible after it.

2. The process holds a Service, which is bound to a visible (or foreground) Activity.

Visible processes are also considered very important and will not be destroyed unless they are used to ensure that all foreground processes run and have to kill visible processes.

 

2. Service process

If a service is running in a processstartService()Enabled, and does not belong to the above two high priority situations, this process is a service process.

Although service processes are not bound to what users can see, what they do is the concern of users, such as playing music in the background and downloading data in the background.

 

2. 4. Background process

If the process does not belong to the preceding three cases, but the process holds an activity invisible to the user (the onStop () of the activity is called, but onDestroy () is not called ), the process is considered as a background process.

Background processes do not directly affect user experience. The system will randomly kill background processes for foreground processes, visible processes, and service processes.

There are usually many background processes that will be stored in a LRU (least recently used) list. This ensures that the activity recently used by the user is destroyed, that is, the activity with the longest destruction time.

 

2. 5. Empty Process

If a process does not contain any active application components, it is considered as a blank process.

The only reason for saving this process is to cache the need, in order to speed up the next time you want to start the components in this process.

To balance the process cache and underlying kernel cache resources, the system often kills empty processes.

 

2.6 Description

1. Android puts processes at a high priority as much as possible.

For example, if a process has a visible activity and a service, the process is regarded as a visible process rather than a service process.

2. The level of a process may increase because of the dependency of other processes. If a process serves another process, its priority will not be lower than that of the process it serves.

For example, A content provider in process A provides services to A customer in process B, or A service in process A is bound to A component in process B, the priority of process A is at least as high as that of process B.

3. because the priority of a service process is higher than that of a background process, it is better to enable a service for an activity that requires a long operation, especially when the operation is likely to exceed the activity duration.

For example, to upload an image file, you should enable a service to upload the file, so that the work is still ongoing when the user leaves the activity. Using service ensures that the operation has at least the priority of the service process.

 

You are welcome to discuss anything wrong!