Four, Android IPC mechanisms of (1)

Disclaimer: This article is a blogger original article, shall not be reproduced without the bloggers allowed. https://blog.csdn.net/yz_cfm/article/details/90110335

Android IPC Introduction:

    The IPC (Inter-Process Communication) , inter-process communication. That is, the process of data exchange between the two processes. Android, an open application is equivalent to a process running on the virtual machine.

IPC in Android usage scenarios:

  1. 1. A multi-process applications run.

  2. 2. between different applications in data communication through the IPC mechanism.

Android open in multi-process mode:

    Under normal circumstances, multi-process mode in Android refers to the same application where there are multiple processes. In general, we can specify in Android through to the four components (Activity, Service, BroadcastReceiver, ContentProvider ) in AndroidManifest.xml android: process attribute to open the multi-process (of course there are unconventional operations, through JNI layer in native fork () a process). In addition to the four major components, we can not specify a specific process of its operation to separate a thread or entity class in Android (Android only be specified as the four components).

eg:

// 获取进程名方法
public static String getProcessName(Context context) {
    int pid = android.os.Process.myPid();
    ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
    List<ActivityManager.RunningAppProcessInfo> runningApps = am.getRunningAppProcesses();

    if (runningApps == null) {
        return null;
    }

    for (ActivityManager.RunningAppProcessInfo procInfo : runningApps) {
        if (procInfo.pid == pid) {
            return procInfo.processName;
        }
    }
    return null;
}
<activity android:name="com.cfm.processtest.ThirdActivity"
    android:process="com.cfm.test2">
</activity>

<activity android:name="com.cfm.processtest.SecondActivity"
    android:process=":test1">
</activity>

<activity android:name="com.cfm.processtest.FirstActivity">
    <intent-filter>
        <action android:name="android.intent.action.MAIN"/>

        <category android:name="android.intent.category.LAUNCHER"/>
    </intent-filter>
</activity>

FirstActivity.java -> SecondActivity.java -> ThirdActivity.java

Log print the results:

FirstActivity 进程名: com.cfm.processtest // 不指定 process 属性就默认当前应用的包名为进程名
SecondActivity 进程名: com.cfm.processtest:test1
ThirdActivity 进程名: com.cfm.test2

adb shell results:

    The results can be seen by us to open more than two naming process:

    1. The first is ":" at the beginning of the colon , this is an additional process before the current name of the current package name.

    2. The second is a complete naming.

    The difference between these two naming way is to process the beginning of the colon is privately owned processes currently applied, components and other applications can not run it in the same process; and the process to produce second way is a global process, other applications by shareUID way and it runs in the same process.

About ShareUID explanation:

    Android default UID for each application will be assigned a unique UID (user ID), we can also specify their own application, the application having the same UID can share data, such as data directory data, information or the like components. If you have the same ShareUID between two applications and the same signature, then they can also be run in the same process, this time they not only have access to each other's private data, such as data directory, information and other components, but also the shared memory data.

eg: the same but different signatures shareUID two applications to access other data directory data

ShareUIDTest2 Application:

// AndroidManifest.xml:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.cfm.shareuidtest2"
            android:sharedUserId="com.cfm.test">
    ...

</manifest>
// MainActivity.java
@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    SharedPreferences.Editor editor = getSharedPreferences("share", MODE_PRIVATE).edit();
    editor.putString("name", "cfm");
    editor.putString("dream", "open source");
    editor.apply();
}

ShareUIDTest1 Application:

// AndroidManifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.cfm.shareuidtest1"
        android:sharedUserId="com.cfm.test">

    ...

</manifest>
// ManiActivity.java
@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    try {
        // 通过包名信息获取 shareuidtest2 的上下文对象
        Context context = createPackageContext("com.cfm.shareuidtest2", Context.CONTEXT_IGNORE_SECURITY);
        SharedPreferences preferences = context.getSharedPreferences("share", MODE_PRIVATE);
        String name = preferences.getString("name", "ym");
        String dream = preferences.getString("dream", "make money");
        Log.d("cfmtest", "name: " + name);
        Log.d("cfmtest", "dream: " + dream);
    } catch (PackageManager.NameNotFoundException e) {
        e.printStackTrace();
    }
}
// 打印的 Log 信息
cfmtest: name: cfm
cfmtest: dream: open source

Android, multi-process model brings the question:

    The main cause of the following four questions:

    1. The static and complete failure singleton

    2. Thread synchronization mechanism completely ineffective

    3. SharePreferences reliability decline

    4. Application will create many times

    Explanation 1:

    This is easy to understand, because Android System will be assigned a separate virtual machine for each application launched after the application is started, or for each process is assigned a separate virtual machine. So due to the different virtual machines on memory allocation in different address spaces, which will lead to access to the same object in different virtual machines will produce multiple copies. So when we create a static object member variable or singleton pattern in an application, each process actually acquired are these objects corresponding to the copy, when we operate the object, in fact, influence the only copy of the object attributes the current process, without affecting the object was originally created. So you can not multi-process model to share data in memory in this way.

    Explanation 2:

    With a similar, since they are not in the same block of memory, then either lock or lock object global class can not guarantee thread synchronization, because different processes, locks are they not the same object, but the object is generated multiple copies.

    Explanation 3:

    Because SharePreferences two or more processes does not support simultaneous read and write them, which can lead to a chance of data loss.

    Explanation 4:

    Used above  FirstActivity.java -> SecondActivity.java -> ThirdActivity.java example, a custom and the MyApplication :

public class MyApplication extends Application {
    private static final String TAG = "MyApplication";

    @Override
    public void onCreate() {
        super.onCreate();
        Log.d(TAG, "MyApplication 进程名: " + Untils.getProcessName(getApplicationContext()));
    }
}
// AndroidManifest.xml
<application
    android:name=".MyApplication"
    ...>
        ...
</application>

Print Log Information:

MyApplication 进程名: com.cfm.processtest
MyApplication 进程名: com.cfm.processtest:test1
MyApplication 进程名: com.cfm.test2

    Application can be seen many times created, in fact, the reason is very simple, it is because Android System to create a new virtual machine in the creation of each process is going to be, and this process is similar to actually start a new application, like so start the application will naturally create application. At the same time, it also proved that, in multi-process mode, components, different processes have separate virtual machine, Application and memory space.

Guess you like

Origin blog.csdn.net/yz_cfm/article/details/90110335
IPC