Binder 进程间通信

进程间通信(ipc)

IPC的主要目的是调用其他进程的函数

• 使用多进程显而易见的好处就是分担主进程的内存压力。我们的应用越做越大，内存越来越多，将一些独立的组件放到不同的进程，它就不占用主进程的内存空间了。当然还有其他好处，有些应用后台是有多个进程的，启动一个不可见的轻量级私有进程，在后台收发消息，或者做一些耗时的事情，或者开机启动这个进程，然后做监听等。还有就是防止主进程被杀守护进程，守护进程和主进程之间相互监视，有一方被杀就重新启动它。因为它们要常驻后台，特别是即时通讯或者社交应用
• 推送、融云

什么时候用服务

不需要和用户交互而且还要长期运行的任务。服务的运行不依赖于任何用户界面，即使程序被切换到后台，或者用户打开了另一个应用程序，服务仍然能够保持独立运行。音乐、播放器

如果一个 app 两个进程同时操作 sharedpreferences，如何保证数据安全。不能，使用ContentProvider、mmkv

Binder

https://blog.csdn.net/freekiteyu/article/details/70082302

Android Binder 驱动框架设计与分析

我的理解：

• Binder是Android系统中进程间通讯（IPC）的一种方式。不同进程、不同APP间就是通过binder通讯的。Binder 通信采用 C/S 架构，从组件视角来说，包含 Client、 Server、 ServiceManager 以及 Binder 驱动。
• 服务端提供服务，客户端获取数据。ServiceManager的作用查询服务和注册服务。Binder 驱动是运行在内核空间(liux)，进程间通讯的底层就是Binder 驱动。它使用的是mmap() 是操作系统中一种内存映射的方法。
• ServiceManager 将用户空间的参数等请求数据复制到内核空间，并向服务端插入一条执行方法的事务（事务（Transaction），一般是指要做的或所做的事情）。事务执行完通知 ServiceManager 将执行结果从内核空间复制到用户空间，并唤醒等待的线程(binder_send_reply发送reply、binder_write客户端写)，响应结果，通讯就结束了。
• 在 Android 开发中，可以使用 AIDL，并通过系统生成的代码来实现客户端和服务端的通信。AIDL 可以处理跨进程的方法调用、数据传输、回调等功能，简化了开发者在进行跨进程通信时的代码编写工作。

3. Binder 驱动：运行在内核空间 kernel，负责各个用户进程通过 Binder 实现通信的内核模块（Binder Dirver）底层就是 Binder 驱动

• 内存映射就是将用户空间的一块内存区域映射到内核空间。映射关系建立后不同的进程的内核地址空间是共享的。能减少数据拷贝次数，实现进程间通讯的高效互动。
• 2次拷贝，内核空间与用户空间共享内存通过 copy_from_user (), copy_to_user () 内核方法来完成用户空间与内核空间内存的数据传输。
• copy_from_user 一次拷贝就行，不需要2次了
  

不同进程之间的内核地址空间映射到相同的物理地址，即不同的进程的内核地址空间是共享的。不同进程之间的用户地址空间映射到不同的物理地址，相互之间是隔离的，无法访问的。

MMAP

Binder 只需要一次数据拷贝，性能更好
内核空间与用户空间共享内存通过 copy_from_user (), copy_to_user () 内核方法来完成用户空间与内核空间内存的数据传输

Binder IPC 机制中涉及到的内存映射通过 mmap () 来实现，mmap () 是操作系统中一种内存映射的方法。内存映射简单的讲就是将用户空间的一块内存区域映射到内核空间。映射关系建立后，用户对这块内存区域的修改可以直接反应到内核空间；反之内核空间对这段区域的修改也能直接反应到用户空间。

内存映射能减少数据拷贝次数，实现用户空间和内核空间的高效互动。两个空间各自的修改能直接反映在映射的内存区域，从而被对方空间及时感知。也正因为如此，内存映射能够提供对进程间通信的支持。

ServiceManager

[[1-Android的启动流程#ServiceManager]]

• ServiceManager 分为 framework 层和 native 层，framework 层只是对 native 层进行了封装方便调用。
• ServiceManager 的作用很简单就是提供了查询服务和注册服务的功能。
• 负责管理系统中的 Service 组件，并且向 Client 组件提供获取 Service 代理对象的服务。

ServiceManager 运行在一个独立的进程中，因此，Service 组件和 Client 组件也需要通过进程间通信机制来和它交互，而采用的进程间通信机制正好也是 Binder 进程间通信机制。

ServiceManager 是由 init 进程负责启动的，而 init 进程是在系统启动时启动的，因此，ServiceManager 也是在系统启动时启动。

最后开启 loop 不断的处理共享内存中的数据，无限循环来等待和处理 Service 组件和 Client 组件的进程间通信请求

驱动

Binder是一种虚拟的物理设备驱动

• 虚拟设备驱动程序：虚拟设备驱动程序是模拟硬件设备的驱动程序。它模拟了一块硬件，因此软件可能会有访问真实硬件的错觉。一些虚拟设备驱动程序示例是虚拟网络适配器，虚拟DVD / CD驱动器，虚拟磁盘（内存）等
• 驱动是干什么的？仅从功能的角度来说，驱动程序使得应用程序可以访问硬件。
• 那应用是如何访问硬件的？linux 中一切皆文件，访问硬件就是对文件的读写操作。比如 led 灯对应的文件是 /dev/led, 读写这个文件就能操作 led 灯。而binder驱动就是读写硬件内存区域

虚拟内存

在 Linux 中，每个进程都有自己的虚拟内存地址空间。虚拟内存地址空间又分为了用户地址空间和内核地址空间。

虚拟内存 通过创建虚拟地址空间来隔离不同进程的内存访问，解决了多进程运行时的内存冲突问题。每个进程都有自己的虚拟地址空间，并通过 MMU（内存管理单元） 将虚拟地址映射到物理内存地址上，从而实现对物理内存的访问和管理。

Binder 基本原理 | Android Framework

客户端怎么执行服务端的方法

• 我们们在使用 Binder 时基本都是调用 framework 层封装好的方法，AIDL 就是 framework 层提供的傻瓜式是使用方式。假设服务已经注册完，我们来看看客户端怎么执行服务端的方法。
• 首先我们通过 ServiceManager 获取到服务端的 BinderProxy 代理对象，通过调用 BinderProxy 将参数，方法标识（例如：TRANSACTION_test，AIDL中自动生成）传给 ServiceManager，同时客户端线程进入等待状态。
• ServiceManager 将用户空间的参数等请求数据复制到内核空间，并向服务端插入一条执行执行方法的事务。事务执行完通知 ServiceManager 将执行结果从内核空间复制到用户空间，并唤醒等待的线程，响应结果，通讯结束。

Binder 通信中的代理模式

• 我们已经解释清楚 Client、Server 借助 Binder 驱动完成跨进程通信的实现机制了，但是还有个问题会让我们困惑。A 进程想要 B 进程中某个对象（object）是如何实现的呢？毕竟它们分属不同的进程，A 进程 没法直接使用 B 进程中的 object。
• 在数据流经 Binder 驱动的时候驱动会对数据做一层转换。当 A 进程想要获取 B 进程中的 object 时，驱动并不会真的把 object 返回给 A，而是返回了一个跟 object 看起来一模一样的代理对象 ProxyObject，这个 ProxyObject 具有和 object 一摸一样的方法，但是这些方法并没有 B 进程中 object 对象那些方法的能力，这些方法只需要把把请求参数交给驱动即可。对于 A 进程来说和直接调用 object 中的方法是一样的。
• 当 Binder 驱动接收到 A 进程的消息后，发现这是个 objectProxy 就去查询自己维护的表单，一查发现这是 B 进程 object 的代理对象。于是就会去通知 B 进程调用 object 的方法，并要求 B 进程把返回结果发给自己。当驱动拿到 B 进程的返回结果后就会转发给 A 进程，一次通信就完成了

常规通讯

其实进程间通信就是为了实现数据共享。一个程序不同组件在不同进程也叫多进程，和俩个应用没有本质区别。使用 process 属性可以实现多进程，但是会带来很多麻烦，主要原因是共享数据会失败，弊端有: 静态和单利失效，同步失效，sharedprefer 也变的不可靠等问题。

只有允许不同应用的客户端用 IPC 方式访问服务，并且想要在服务中处理多线程（多任务）时，才有必要使用 AIDL。 如果您不需要执行跨越不同应用的并发 IPC，就应该通过实现一个 Binder 创建接口；或者，如果您想执行 IPC，但根本不需要处理多线程，则使用 Messenger 类来实现接口。无论如何，在实现 AIDL 之前，请您务必理解绑定服务。

aidl文档

AIDL

Android interface definition language (android接口定义语言) , 用来跨进程的访问方法。

AIDL 是什么，怎么实现的，为什么要创建个文件 aidl
1）、定义AIDL文件；——类似于后台给了一个接口文档，里面描述了各种各样的接口，而在AIDL文件中描述的是类似于JAVA接口的方法定义
2）、实现AIDL文件里面定义的接口；——类似于后台实现接口文档的接口控制器，里面定义了接口的具体实现
3）、暴露接口；——这个就像后台开发人员把接口文档给App开发人员，然后App开发人员就知道有哪些接口可以调用来实现业务了
4）、调用；——这个就是App开发人员调用后台的接口来获取过程数据了。
从上面的描述可以看出，这个AIDL实际上就是一个C/S模型，一边是客户端，一边是服务器。

aidl 操作步骤

1. 在两个项目中新建aidl文件，客户端和服务端中这个文件所在的包名要保持一致，内容也要一样，在接口文件AIDLFunctions.aidl中，我们定义一个方法 show

interface AidlFunctions{
    void show();
}

2. 编译之后， 会在build目录下，自动产生同名的，后缀为 java 的文件。里面有我们要用到的 Stub内部类。 com.example.aidl.AidlFunctions是刚定义。
   里面的东西

public static abstract class Stub extends android.os.Binder implements  com.example.aidl.AidlFunctions

3. AIDL的使用，需要一个Service配合，所以我们在服务端还要声明一个Service

public class AIDLService extends Service {
//stub就是系统自动产生的
    AidlFunctions.Stub binder;

    @Override
    public void onCreate() {
        // TODO Auto-generated method stub
        super.onCreate();
    }

    @Override
    public IBinder onBind(Intent intent) {
        // TODO Auto-generated method stub
        binder = new AidlFunctions.Stub() {

            @Override
            //这里是我们在接口中声明的方法的实现
            public void show() throws RemoteException {
                System.out.println("--------------------收到----------------------");
            }
        };
        return binder;
    }   
}

https://www.jianshu.com/p/29999c1a93cd
需要把服务端的AIDL文件以及Book类复制过来，将 aidl 文件夹整个复制到和Java文件夹同个层级下，不需要改动任何代码

远端服务通过action绑定

4. 客户端：

//绑定服务，要用到ServiceConnection 
private ServiceConnection serviceConnection;
//自定义的接口，和服务端一样
private AidlFunctions aidlFunctions;

serviceConnection = new ServiceConnection() {

    @Override
    public void onServiceDisconnected(ComponentName name) {
        System.out.println("--------------------ServiceDisconnected----------------------");
    }

    @Override
    public void onServiceConnected(ComponentName name, IBinder service) {
        System.out.println("--------------------ServiceConnected----------------------");
        aidlFunctions = AidlFunctions.Stub.asInterface(service);
    }
};
Intent intent = new Intent("com.example.androidaidl.AIDLService");
bindService(intent, serviceConnection, Context.BIND_AUTO_CREATE);
//调用show方法
try {
    aidlFunctions.show();
} catch (RemoteException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
}

AIDL 生成的文件

stub 具体实现类、proxy 代理类

interface IMyAidlInterface {
    int sendData(String data);
    String getData();
}


//生成
public interface IMyAidlInterface extends android.os.IInterface {
 
    public static abstract class Stub extends android.os.Binder implements com.zero.aidleservicedemo.IMyAidlInterface {
        private static final java.lang.String DESCRIPTOR = "com.zero.aidleservicedemo.IMyAidlInterface";

        public Stub() {
            this.attachInterface(this, DESCRIPTOR);
        }

        /**
         * Cast an IBinder object into an com.zero.aidleservicedemo.IMyAidlInterface interface,
         * generating a proxy if needed.   生成代理需要
         */
        public static com.zero.aidleservicedemo.IMyAidlInterface asInterface(android.os.IBinder obj) {
            if ((obj == null)) {
                return null;
            }
            android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
            if (((iin != null) && (iin instanceof com.zero.aidleservicedemo.IMyAidlInterface))) {
                return ((com.zero.aidleservicedemo.IMyAidlInterface) iin);
            }
            return new com.zero.aidleservicedemo.IMyAidlInterface.Stub.Proxy(obj);
        }

        @Override
        public android.os.IBinder asBinder() {
            return this;
        }

        @Override
        public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
            java.lang.String descriptor = DESCRIPTOR;
            switch (code) {
               //自己的方法
                case TRANSACTION_sendData: {
           
                    return true;
                }
                case TRANSACTION_getData: {
                    data.enforceInterface(descriptor);
                    java.lang.String _result = this.getData();
                    reply.writeNoException();
                    reply.writeString(_result);
                    return true;
                }
                default: {
                    return super.onTransact(code, data, reply, flags);
                }
            }
        }

       //代理类
        private static class Proxy implements com.zero.aidleservicedemo.IMyAidlInterface {
            private android.os.IBinder mRemote;

            @Override
            public android.os.IBinder asBinder() {
                return mRemote;
            }


            @Override
            public int sendData(java.lang.String data) throws android.os.RemoteException {
                return _result;
            }

            @Override
            public java.lang.String getData() throws android.os.RemoteException {
                android.os.Parcel _data = android.os.Parcel.obtain();
                android.os.Parcel _reply = android.os.Parcel.obtain();
                java.lang.String _result;
                try {
                    _data.writeInterfaceToken(DESCRIPTOR);
                    mRemote.transact(Stub.TRANSACTION_getData, _data, _reply, 0);
                    _reply.readException();
                    _result = _reply.readString();
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
                return _result;
            }
        }
    }

    public int sendData(java.lang.String data) throws android.os.RemoteException;

    public java.lang.String getData() throws android.os.RemoteException;
}

onTransact, 典型的代理模式

• Server 则是通过 onTransact 方法接收 Client 进程传过来的数据，包括函数名称、函数参数，找到对应的函数（这里是 sum ），把参数喂进去，得到结果，返回。
• 所以 onTransact 函数经历了读数据→执行要调用的函数→把执行结果再写数据的过程
• 注意，在 AIDL 的另一端，是通过 Stub 类的 onTransact 把值从 data 中取出来，计算完得到结果，再把结果通过 reply 返回。
  

其他通讯方法

socket、binder、信号链、共享内存
Intent，binder、 Messenger、AIDL，sharedpre、广播、scheme

1. 使用intent的附加信息extras来传递，通过bundle，传递的是bundle支持的类型，比如基本数据类型、实现pracellable或serializeable的对象

/**指定包名和带包名的Activity的名字*/
ComponentName componentName = new ComponentName("com.example.androidaidl", "com.example.androidaidl.MainActivity");
Intent intent = new Intent();
intent.putExtra("id", 1001);
intent.setComponent(componentName);
startActivity(intent);      

2. 使用文件共享，序列化或是sharedpre，不过不适用于读写并发的操作
3. 广播：Android的广播是系统级的，只要传递的Action一样，就可以接收到其他进程广播的消息，广播中可以通过Intent传递数据。
4. scheme协议是android中的一种页面内跳转协议，通过定义自己的scheme协议，可以非常方便跳转app中的各个页面，并且传递数据，还是可以通过H5页面跳转指定页面等。
5. soket,长链接读网络数据

ContentProvider

（进程间数据共享）和message一样，底层也是binder，除了oncreate方法其他方法(crud)都是运行在bindler线程里。所以在oncerate里不能做耗时操作。Android本身就提供了不少的ContentProvider访问，比如联系人、相册等。 访问ContentProvider，需要通过Uri，需要以“content://”开头。在其他应用访问通过uri(主机名)：

缺点：互相传递数据麻烦，2个provider

ContentProvider

contentResolver?.call(
          MainProcessContentProvider.MAINCONTENTPROVIDER_URI,
          "getAge",
          null,
          bundleOf("student" to "小米")
      )
    

一般的跨进程通信就是基于以上方式实现，这种方式存在的缺点就是每次都需要定义一个Service，再通过BindService来进行进程间通信。也能用ContentProvider.call()来实现便捷的跨进程通信

@Override
 public Bundle call(@NonNull String method, @Nullable String arg, @Nullable Bundle extras) {
     if (!TextUtils.isEmpty(method) && TextUtils.equals(method, "setData")) {
         mBinderParcel.mProxy = extras.getBinder("binder");
     } else if (!TextUtils.isEmpty(method) && TextUtils.equals(method, "getData")) {
         Bundle bundle = new Bundle();
         bundle.putBinder("binder", mBinderParcel.mProxy);
         return bundle;
     }
     return null;
 }
    

method可以用来区分调用的逻辑，arg貌似没什么用，extras是一个Bundle类型用来存放数据。
调用的时候

getContentResolver().call(Uri.parse("content://com.example.mycontentprovider"), "setData", null, bundle); //设置数据

Bundle bundle = getContentResolver().call(Uri.parse("content://com.example.mycontentprovider"), "getData", null, null);

mBinder = IMyAidlInterface.Stub.asInterface(bundle.getBinder("binder"));

Log.i("kingiyu", "RemoteActivity-->-->onCreate-->" + mBinder.getData());

Socket

[[2-Activity进程启动流程#ams-Zygote 通信为什么用 Socket]]

Messenger

1. 通过 Messenger进行传递（handler），在远程服务里创建handler（接收客户端发送的消息）、 Messenger对像，在onbind里返回( Messenger.getbinder)。在客户端绑定服务，拿着 Messenger对象发消息(可以用bundle)。在远程服务的handlermessage方法就会收到。他是一个个处理的，如果大量并发请求用aidl， Messenger底层就是aidl

在客户端中创建一个Messenger。然后，当客户端收到 onServiceConnected() 回调时，会向服务发送一条 Message，并在其 send() 方法的 replyTo 参数中包含客户端的 Messenger。
注意：Messenger和Message是俩个东西

public void sayHello(View v) {
	if (!mBound) return;
	Message msg = Message.obtain(null, MessengerService.MSG_SAY_HELLO, 0, 0);
	try {
	   mService.send(msg);
	} catch (RemoteException e) {
		e.printStackTrace();
	}
}

2. 直接使用Binder对象：缺点是这种方式不能进行跨进程，跨应用程序的函数调用。只能实现在同一个进程之中，同一个应用程序之中的不同的组件之间通讯。

用法：继承Binder，然后在service里return
继承Binder用它的对象返回，客户端将bind对象强转成自定义Bind

ElegantBus

aidl 发送的是 JSON 字符串，然后转成对应的对象

RemoteCallbackList

RemoteCallbackList 位于 android.os 包下.顾名思义,是 Android 系统提供的用于管理远程回调列表的类.有人会问,为什么回调接口要特定维护:

1. 你的远程回调接口因为是有可能多个客户端来调用,因此你需要将每个接口与每个客户端的key进行绑定,这里我们的key可以使用远程客户端的IBinder.
2. 你的回调接口因为远程客户端会死掉, 你需要及时将死去的客户端回调接口清除掉,当然,这点我们自己写程序也可以实现
3. 你的回调接口尽可能要线程安全, 而 AIDL 是在 binder 线程池调用的. 其间可能存在诸多线程同步引起的问题

http://jerey.cn/android/2017/10/13/简介RemoteCallbackList/

RemoteCallbackList是Android框架中的一个类，用于在跨进程通信（IPC）的场景下，管理跨进程回调接口的列表。

在Android中，当应用程序需要与其他进程进行通信时，常用的方式是使用Binder机制进行跨进程通信。在这种情况下，一个进程可以将一个接口的实例注册到另一个进程中，以便在后续的操作中，另一个进程可以通过该接口回调来与注册进程进行通信。

RemoteCallbackList提供了一种安全和高效地管理跨进程回调接口的方式。它解决了在多进程环境下可能出现的线程安全问题，并提供了一些便捷的方法来添加、移除和调用回调接口。

以下是RemoteCallbackList的一些主要特性和用法：

1. 线程安全：RemoteCallbackList是线程安全的，可以在多线程环境下使用，无需额外的同步操作。
2. 添加和移除回调接口：使用register()方法向列表中添加回调接口，使用unregister()方法从列表中移除回调接口。
3. 回调接口通知：使用beginBroadcast()方法开始通知所有注册的回调接口，并使用finishBroadcast()方法结束通知。在通知期间，可以使用getBroadcastItem()和getBroadcastCount()方法来访问每个注册的回调接口。
4. 跨进程兼容性：RemoteCallbackList可以与Binder机制配合使用，以便在跨进程通信的场景下进行回调。

下面是一个简单的示例代码，展示了如何使用RemoteCallbackList：

// 创建一个RemoteCallbackList实例
private RemoteCallbackList<IMyCallback> mCallbacks = new RemoteCallbackList<>();

// 注册回调接口
public void registerCallback(IMyCallback callback) {
    mCallbacks.register(callback);
}

// 移除回调接口
public void unregisterCallback(IMyCallback callback) {
    mCallbacks.unregister(callback);
}

// 通知所有注册的回调接口
public void notifyCallbacks() {
    final int count = mCallbacks.beginBroadcast();
    for (int i = 0; i < count; i++) {
        IMyCallback callback = mCallbacks.getBroadcastItem(i);
        if (callback != null) {
            try {
                callback.onCallback();
            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }
    }
    mCallbacks.finishBroadcast();
}

在上述示例中，我们创建了一个RemoteCallbackList实例mCallbacks，并提供了注册、移除和通知回调接口的方法。在通知回调时，我们使用beginBroadcast()方法开始通知，并使用finishBroadcast()方法结束通知。在通知期间，我们通过getBroadcastItem()方法获取每个注册的回调接口，并调用其方法进行回调操作。

RemoteCallbackList是一个强大而灵活的类，为在跨进程通信中管理回调接口提供了便利。它简化了跨进程通信的复杂性，并提供了线程安全的管理机制。

注意

Binder 代理对象泄露问题

1. 跨进程回调：当一个进程通过Binder将自己的代理对象传递给另一个进程，并且在另一个进程中注册回调接口时，如果没有适时地取消注册或解除引用，就会导致泄露。例如，一个Activity通过Binder传递自己的代理对象给Service，并在Service中注册回调接口，如果Activity销毁时没有取消注册，就会导致Activity的代理对象无法释放。
2. 跨进程单例模式：当一个进程中的组件（如Service或ContentProvider）通过Binder提供单例对象给其他进程时，如果其他进程持有该对象的引用，并且没有适时地释放引用，就会导致泄露。这种情况下，其他进程可能会长时间持有对象的引用，使对象无法被垃圾回收。
3. 跨进程数据缓存：当一个进程通过Binder将数据提供给其他进程，并且其他进程持有数据的引用时，如果没有适时地释放引用，就会导致泄露。这种情况下，数据对象可能会占用大量内存，并且无法被回收，从而导致内存泄漏。

为避免Binder代理对象泄露问题，可以采取以下措施：

1. 确保在不再需要Binder代理对象时及时解除引用或取消注册回调接口，避免长时间持有代理对象的引用。
2. 在使用Binder进行跨进程通信时，遵循良好的生命周期管理原则，确保在合适的时机释放资源。
3. 对于跨进程传递的数据对象，尽量避免长时间持有引用，或者使用弱引用等机制来管理引用。