Eight of the pits in Android development: multi-process issues

This is a pit that needs to be handled carefully.

1 Memory:

In manifest, you can declare the process in which each component is located:

android:process= ": Name"

Then the corresponding acitivity, Receiver, service will run in the corresponding process.

But some classes run in all processes, such as some utils tool classes, such as the application class.

When encountering multiple processes in parallel, clarify the code for the process and avoid running process B's code in process a.

For example, there is a tool class Utils_proca. only need to work in process a , that for process B, this Utils_proca is not useful, is redundant code, if the Utils_proca is initialized in B , it consumes the CPU, also consumes memory.

2 Interaction:

In the same app, there are several different processes, and communication is a must.

There are a number of optional communication mechanisms between processes: Aidl, broadcast, and these two are Android-provided, well-understood communication mechanisms.

Use broadcast to guard against ANR and avoid processing time-consuming logic in OnReceive ().

With Aidl, there are some timing problems, and the bind service takes time. This time is uncertain, if the service process has not started at bind time, it will need to wait for the service process to start to complete. Therefore, bind may not immediately use aidl, waiting for the serviceconnection.onserviceconnected () callback to succeed.

If there is an immediate need to execute the service interface, either a callback, or another thread, round-robin determines whether the connection is OK. cut must not wait on the main thread. It will also be ANR.

Eight of the pits in Android development: multi-process issues