Binder工作机制

Binder的机制

Binder是什么

binder是什么？我们都在Activity通过getSystemService（）方法获取系统的Service（例如：ActivityManagerService，WindowManagerService等），这些Activity一般都是客户端编写的，而系统的这些Service是属于服务端的。显然它们不会在同一进程（一般来说，一个APP单独在一个进程）。两个进程之间怎么通信？Binder就是两个进程通信的中间媒介。

Binder的使用

编写一个定位的Service。

服务端：

public class LocationManagerService extends Binder {

    private static final String TAG = "LocationService";

    /**
     *
     * @param code 用于标识客户端期望调用服务端的哪个函数
     * @param data 客户端传递的参数
     * @param reply 返回给客户端的数据
     * @param flags 执行IPC的模式，分为两种一种是双向的，用常量0表示，其含义是服务端执行指定服务后返回一定的数据，另一种是单向的，用常量1表示，其含义不返回任何数据
     * @return
     * @throws RemoteException
     */
    @Override
    protected boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException {

        switch (code){
            case 101:

                data.enforceInterface(TAG);

                double lat = data.readDouble();
                double lng = data.readDouble();

                setLocation(lat,lng);
                reply.writeString("Successful");
                break;
            default:
                break;
        }
        return super.onTransact(code, data, reply, flags);
    }

    public void getMyLocation(){

    }

    public void setLocation(double lat,double lng){

    }
}

服务的很简单，从代码的角度来看：只需继承Binder类重写onTransact的方法即可。

在onTransact方法里，我们写了一些代码 switch (code)…case 101；这里就有几个问题：

  1. 为什么101，不是102或者其他的？其实code的变量是用于识别客户端期望调用服务端的哪一个函数。双放需要约定一组code值int类型的。
  2. 服务端如何知道data变量中的位置？从上面的代码来看为什么第一个参数是lat，第二个lng，为什么不能第一个lng，第二个lat？这也需要双方有个约定。

在上述代码中调用了 data.enforceInterface(TAG);是为了校验与客户端 data.writeInterfaceToken(“LocationManagerService”);相对应。

客户端：

{

        IBinder mRemote = getLocationService("LocationManagerService");

        Double lat = 1.2323;
        Double lng = 1.2434;

        int code = 101;

        Parcel data = Parcel.obtain();
        Parcel reply = Parcel.obtain();

        data.writeInterfaceToken("LocationService");
        data.writeDouble(lat);
        data.writeDouble(lng);

        try {
            mRemote.transact(code,data,reply,0);
            String replyStr = reply.readString();

        } catch (RemoteException e) {
            e.printStackTrace();
        }

    }

在客户端，我们首先远程获取服务端的Binder对象。获取到该变量后，就可以调用该变量到方法transact方法。该方法的原型是： public boolean transact(int code, Parcel data, Parcel reply, int flags)；参数与服务端的onTransact方法的参数相对应。

这里两个很重要的问题：

  1. 怎么获取远程的Binder对象？
  2. 客户端需要和服务端约定好两件事
    1. 服务端不同函数code的值
    2. 服务端函数参数的顺序。

这两个重要问题是必须要解决的。

对于第一个问题：

当我们扩展系统服务的时候可以使用Service类（四大组件之一的Service）来获取Binder对象。这是系统提供给的。这是非必需的，当然可以自己写一套方法来获取到这个远程的Binder对象。

而当我们是扩展客户端服务是必须基于Service类（四大组件之一的Service）来编写。所谓的系统服务是可以指使用getSystemService（）方法来获取的服务，所谓的客户端服务指的是应用程序提供的自定义服务。

对于第二个问题：系统给我们提供了一个aidl工具，该工具可以把一个aidl文件转换为一个Java类，在该Java类同时重载类transact方法和onTransact方法。从而统一了写入参数的顺序和读取参数的顺序。然而aidl工具也是非必需的，也是完全可以自己写一套方法来统一写入参数和读取参数顺序的算法。

使用系统提供的Service（四大组件之一）和aidl工具来了解Binder的运行的机制。

创建ILocationManager.aidl文件：

interface ILocationManager {

    Location getLocation();

    void setLocation(double lat,double lng);
}

如果.aidl文件中用到了自定义的Parcelable对象，必须新建一个和它同名的aidl文件，并在其中声明它为Parcelabe类型。

在ILocationManager.aidl中我们使用Location这个类。

创建Location.aidl:

// Location.aidl
package com.example.maimingliang.test;
parcelable Location;

创建aidl的包结构在服务端和客户端要保持一致，否则运行会出错。

aidl只支持声明方法，不支持声明静态常量。

aidl支持的数据类型：

  1. 基本数据类型（int,long,char,boolean,double）
  2. String和CharSequence
  3. List：只支持ArrayList，里面的每个元素都必须能够被aidl支持
  4. Map：只支持HashMap，里面的每个元素都必须能够被aidl支持，包括key和value。
  5. Parcelable：所有实现Parcelable接口的对象。
  6. aidl：所有的aidl接口本身也可以在aidl文件中使用。

我们创建了一个ILocationManager.aidl文件，第一个字母的‘I‘是非必需的，是为了统一程序风格，‘I‘即IInterface类，是一个能够提供远程服务的类。aidl工具以该名称输出一个Java类。我们去看看这个生成的ILocationManager.java文件的代码：

/*
 * This file is auto-generated.  DO NOT MODIFY.
 * Original file: /Users/maimingliang/AndroidStudioProjects/Test/app/src/main/aidl/com/example/maimingliang/test/ILocationManager.aidl
 */
package com.example.maimingliang.test;
public interface ILocationManager extends android.os.IInterface {
    /**
     * Local-side IPC implementation stub class.
     */
    public static abstract class Stub extends android.os.Binder implements com.example.maimingliang.test.ILocationManager {
        private static final java.lang.String DESCRIPTOR = "com.example.maimingliang.test.ILocationManager";

        /**
         * Construct the stub at attach it to the interface.
         */
        public Stub() {
            this.attachInterface(this, DESCRIPTOR);
        }

        /**
         * Cast an IBinder object into an com.example.maimingliang.test.ILocationManager interface,
         * generating a proxy if needed.
         */
        public static com.example.maimingliang.test.ILocationManager asInterface(android.os.IBinder obj) {
            if ((obj == null)) {
                return null;
            }
            android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
            if (((iin != null) && (iin instanceof com.example.maimingliang.test.ILocationManager))) {
                return ((com.example.maimingliang.test.ILocationManager) iin);
            }
            return new com.example.maimingliang.test.ILocationManager.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 {
            switch (code) {
                case INTERFACE_TRANSACTION: {
                    reply.writeString(DESCRIPTOR);
                    return true;
                }
                case TRANSACTION_getLocation: {
                    data.enforceInterface(DESCRIPTOR);
                    com.example.maimingliang.test.Location _result = this.getLocation();
                    reply.writeNoException();
                    if ((_result != null)) {
                        reply.writeInt(1);
                        _result.writeToParcel(reply, android.os.Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
                    } else {
                        reply.writeInt(0);
                    }
                    return true;
                }
                case TRANSACTION_setLocation: {
                    data.enforceInterface(DESCRIPTOR);
                    double _arg0;
                    _arg0 = data.readDouble();
                    double _arg1;
                    _arg1 = data.readDouble();
                    this.setLocation(_arg0, _arg1);
                    reply.writeNoException();
                    return true;
                }
            }
            return super.onTransact(code, data, reply, flags);
        }

        private static class Proxy implements com.example.maimingliang.test.ILocationManager {
            private android.os.IBinder mRemote;

            Proxy(android.os.IBinder remote) {
                mRemote = remote;
            }

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

            public java.lang.String getInterfaceDescriptor() {
                return DESCRIPTOR;
            }

            @Override
            public com.example.maimingliang.test.Location getLocation() throws android.os.RemoteException {
                android.os.Parcel _data = android.os.Parcel.obtain();
                android.os.Parcel _reply = android.os.Parcel.obtain();
                android.location.Location _result;
                try {
                    _data.writeInterfaceToken(DESCRIPTOR);
                    mRemote.transact(Stub.TRANSACTION_getLocation, _data, _reply, 0);
                    _reply.readException();
                    if ((0 != _reply.readInt())) {
                        _result = com.example.maimingliang.test.Location.CREATOR.createFromParcel(_reply);
                    } else {
                        _result = null;
                    }
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
                return _result;
            }

            @Override
            public void setLocation(double lat, double lng) throws android.os.RemoteException {
                android.os.Parcel _data = android.os.Parcel.obtain();
                android.os.Parcel _reply = android.os.Parcel.obtain();
                try {
                    _data.writeInterfaceToken(DESCRIPTOR);
                    _data.writeDouble(lat);
                    _data.writeDouble(lng);
                    mRemote.transact(Stub.TRANSACTION_setLocation, _data, _reply, 0);
                    _reply.readException();
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
            }
        }

        static final int TRANSACTION_getLocation = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
        static final int TRANSACTION_setLocation = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1);
    }

    public com.example.maimingliang.test.Location getLocation() throws android.os.RemoteException;

    public void setLocation(double lat, double lng) throws android.os.RemoteException;
}

该java文件包含了三个类：

定义一个 Java interface内部包含 aidl 文件所声明的服务函数,类名称为 ILocationManager,并且该类基于 IInterface 接口,即需要 供一个 asBinder()函数

Stub类：

基于Binder和实现了ILocationManager接口的一个抽象类，之所以是抽象类也没有实现ILocationManager接口的方法，是因为具体的服务函数必须由程序员实现。

重写了onTransact()统一写入参数顺序和读出参数的顺序。

在Stub类中还定义了一些int常量，这些常量就是onTransact()和 transact()第一个参数code值的来源。

还有一个asInterface（）的方法：返回客户端所需的接口类型对象。这个方法是区分进程的。如果是当前进程：返回Stub对象本身。否则返回Stub.Proxy对象。

Stub.Proxy类

该类是当客户端远程获取Binder对象的使用的代理对象，该代理对象最主要的作用也是统一写入参数的顺序和读取参数的顺序。里面的方法被客户端所调用。

服务端

public class LocationManagerService extends Service {

    private static final String TAG = "LocationManagerService";

    private Binder mBinder = new ILocationManager.Stub(){

        @Override
        public Location getLocation() throws RemoteException {

            Log.d(TAG,"-------->getLocation");
            return null;
        }

        @Override
        public void setLocation(double lat, double lng) throws RemoteException {
            Log.d(TAG,"----> lat = " + lat +"  --- > lng = " + lng);
        }
    };

    @Nullable
    @Override
    public IBinder onBind(Intent intent) {
        return mBinder;
    }

    @Override
    public void onCreate() {
        super.onCreate();
    }

服务端代码很简单，继承与四大组件之一的Service。创建一个Binder对象，并在onBind（）方法返回。

在清单文件注册：

  <service android:name=".service.LocationManagerService"
            android:process=":remote"></service>

让该服务类单独在一个进程，模拟跨进程通信。为了方便测试把服务端代码和客户端代码编写在同一工程。虽然同一工程，但其本质是一样的。

客户端

public class LocationManagerActivity extends AppCompatActivity {

    private ServiceConnection mServiceConn = new ServiceConnection() {
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            ILocationManager locationManager = ILocationManager.Stub.asInterface(service);

            try {
                locationManager.setLocation(1.414,1.321);

                locationManager.getLocation();

            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {

        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_location_manager);

        initData();
    }

    private void initData() {
        Intent intent = new Intent(this,LocationManagerService.class);
        bindService(intent,mServiceConn, Context.BIND_AUTO_CREATE);
    }

    @Override
    protected void onDestroy() {
        unbindService(mServiceConn);
        super.onDestroy();
    }
}

可以看出，只需绑定一个Service，在ServiceConnection接口的onServiceConnected()方法的第二个变量 service，如果该Service启动正常，AmS会调用ActivityThread类中ApplicationThread对象，回调onServiceConnected()会带上serivce的Binder引用。

可以看到通过Service（四大组件之一）和aidl工具很容易就可以获取到远程到Binder对象，同时参数到写入和读出的顺序也无须关心。

分析整一个调用的流程：

当客户端在onServiceConnected获取到Binder对象后，调用

ILocationManager locationManager = ILocationManager.Stub.asInterface(service);转化我们定义的接口的类型。而locationManager引用的指向的真正类型是Stub.Proxy。

接着调用locationManager.setLocation(1.414,1.321);其实调用了是Stub.Proxy的set Location方法，在看看这个方法：


            @Override
            public void setLocation(double lat, double lng) throws android.os.RemoteException {
                android.os.Parcel _data = android.os.Parcel.obtain();
                android.os.Parcel _reply = android.os.Parcel.obtain();
                try {
                    _data.writeInterfaceToken(DESCRIPTOR);
                    _data.writeDouble(lat);
                    _data.writeDouble(lng);
                    mRemote.transact(Stub.TRANSACTION_setLocation, _data, _reply, 0);
                    _reply.readException();
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
            }

在这个方法里，aidl工具定义transact（）方法内部给_data和_reply 写入参数的顺序。接着调用transact（）方法来发送远程请求，同时当前的线程会被挂，直到服务端进程返回数据（耗时的操作）。之后会调用Stub类的onTransact（）方法，进入该方法（只看set Location方法）：

 case TRANSACTION_setLocation: {
                    data.enforceInterface(DESCRIPTOR);
                    double _arg0;
                    _arg0 = data.readDouble();
                    double _arg1;
                    _arg1 = data.readDouble();
                    this.setLocation(_arg0, _arg1);
                    reply.writeNoException();
                    return true;
                }

transact（）方法内部_data， _reply的参数顺序是由aidl工具定义，在onTransact（）方法中，aidl工具自然的知道应该怎么读取参数。

END

时间： 2024-10-06 00:17:51

Binder工作机制的相关文章

Binder的工作机制浅析

在Android开发中,Binder主要用于Service中,包括AIDL和Messenger,其中Messenger的底层实现就是AIDL,所以我们这里通过AIDL来分析一下Binder的工作机制. 一.在Android Studio中建立AIDL 首先,我们需要建立一个AIDL 1.在建立了对应的实现Parcelable接口的实体类和AIDL接口后,文件结构如下: 2.点击clean Project/reBuild Project,出现如下错误:提示无法找到Book实体类. 3.解决方案 这

Android IPC机制—Binder的工作机制

进程和线程的关系 IPC机制即为跨进程通信,是inter-Process Communication的缩写.是指两个进程之间进行通信.在说进程通信之前,我们的弄明白什么是线程,什么是进程.进程和线程是两个截然不同的概念.按照操作系统中的描述,线程是CPU调度的最小单位,同时线程也是一种有限的系统资源.而进程一般是指一个执行单元,在pc端或者移动端上是指一个程序或者一个应用.一个进程中可以包含一个或者是多个线程.所以他们的关系应该是包含和被包含的关系. 跨进程的种类 在Android中跨进程通信的

android binder 进程间通信机制1-binder 驱动程序

以下内容只大概列个提纲,若要明白其中细节,还请看源码: 申明:本人菜鸟,希望得到大神指点一二,余心足已 binder 设备:/dev/binder binder 进程间通信涉及的四个角色: Client  Service  ServiceManager  Binder驱动程序 一,Binder驱动程序 源码位置:kernel/[vendor]/[codename]/drivers/staging/android/binder.c kernel/[vendor]/[codename]/driver

Binder核心机制分析揭秘跨进程得实现原理

前言 想写篇关于Binder的文章,可对其一无所知,无从下手.在阅读了大量的优秀文章后,心惊胆战的提笔,不怕文章被贻笑大方,怕的是误人子弟!望各位大佬抽空阅读本文的同时,能够对文章的知识点持怀疑态度,共同探讨,共同进步! 一.序列化 日常开发中,通过Intent携带数据跳转Activity时,数据通常要通过实现Serializable或Parcelable接口,才能在被Intent所携带,而Serializable接口和Parcelabel接口主要是完成对象的序列化过程.将对象持久化到设备上或者

重读《深入理解Java虚拟机》五、虚拟机如何执行字节码？虚拟机执行引擎的工作机制

Class文件二进制字符流通过类加载器和虚拟机加载到内存(方法区)完成在内存上的布局和初始化后,虚拟机字节码执行引擎就可以执行相关代码实现程序所定义的功能.虚拟机执行引擎执行的对象是方法(均特指非本地方法),方法是 着一个程序所定义的一个功能的载体,实现预定的业务功能或者特定的功能等. Java虚拟机内存内针对方法的执行专门划分了一个区域即虚拟机栈.虚拟机栈内通过栈帧结构来存储调用方法和执行方法需要的局部变量,操作数栈.方法返回值等,通过栈帧的出入栈来表示方法的执行顺序. 1.栈帧结构:虚拟机内

Java IO工作机制分析

Java的IO类都在java.io包下,这些类大致可分为以下4种: 基于字节操作的 I/O 接口:InputStream 和 OutputStream 基于字符操作的 I/O 接口:Writer 和 Reader 基于磁盘操作的 I/O 接口:File 基于网络操作的 I/O 接口:Socket 1 IO类库的基本结构 1.1 基于字节操作的IO接口 基于字节操作的IO接口分别是InputStream和OutputStream,InputStream的类结构图如下所示: 同InputStream

深入分析 Java I/O 的工作机制

I/O 问题可以说是当今互联网 Web 应用中所面临的主要问题之一,因为当前在这个海量数据时代,数据在网络中随处流动.这个流动的过程中都涉及到 I/O 问题,可以说大部分 Web 应用系统的瓶颈都是 I/O 瓶颈.本文的目的正是分析 I/O 的内在工作机制,你将了解到:Java 的 I/O 类库的基本架构:磁盘 I/O 工作机制:网络 I/O 的工作机制:其中以网络 I/O 为重点介绍 Java Socket 的工作方式:你还将了解到 NIO 的工作方式,还有同步和异步以及阻塞与非阻塞的区别,最

深入struts2(三)---工作机制和运行流程图

1     工作原理 1.1     体系架构 图2.1 struts2.0体系架构图 1.2     工作机制 针对上节体系架构图,以下分步说明运行流程 ?  client初始化一个指向Servlet容器(比如Tomcat)的请求: ?  这个请求经过一系列的过滤器(Filter)(这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器,这个过滤器对于Struts2和其它框架的集成非常有帮助,比如:SiteMesh Plugin): 注:从struts2.1.3后就不须要配

BrnShop开源网上商城第三讲：插件的工作机制

这几天BrnShop的开发工作比较多,所以这一篇文章来的晚了一些,还请大家见谅呀!还有通知大家一下BrnShop1.0.312版本已经发布,此版本添加了报表统计等新功能,需要源码的园友可以点此下载.好了,我们现在进入今天的正题.关于BrnShop插件内容比较多,所以我分成两篇文章来讲解,今天先讲第一部分内容:插件的工作机制. 对于任意一种插件机制来说,基本上只要解决以下三个方面的问题,这个插件机制就算成功了.这三个方面如下: 插件程序集的加载 视图文件的路径和编译 插件的部署 首先是插件程序集的