浅谈Android IPC机制之Binder的工作机制

进程和线程的关系

按照操作系统中的描述,线程是CPU调度的最小单位,同时线程也是一种有限的系统资源。而进程一般是指一个执行单元,在pc端或者移动端上是指一个程序或者一个应用。一个进程中可以包含一个或者是多个线程。所以他们的关系应该是包含和被包含的关系。

跨进程的种类

在Android中跨进程通信的方式有很多种,Bundle,文件共享,AIDL,Messenger,ContentProvider,Socket,这些都能实现进程间之间的通信,当然,虽然都能够实现进程间通信,但是他们之间的实现原理或者说是底层的实现方式都是不一样的。下面,我们将会一一说明。

注:很多同学觉得创建进程就应该创建一个新的应用。其实不是的。只要我们在AndroidMenifest上加上这一句代码就可以了android:process=“:remote”具体的,同学们可以自己的了解。

在说IPC之前,先说一下一些基础概念,这样对后面的内容能够更好的理解。

Serializable,Parcelable接口

Serializable接口是java提供的一个序列化的接口,这是一个空的接口,为对象提供标准的序列化和反序列化操作。

Serializable序列化和反序列化,都是采ObjectOutputStream和ObjectInputStream就可以实现,当然这些系统基本已经为我们实现了。

Parcelable接口,是Android自带的一种序列化方式。序列化和反序列化都是通过writeToParcel方法来完成的。

两者的区别:Serializable是java的序列化接口使用简单,但是由于序列化和反序列化的过程需要大量的I/o操作,所以性能较差。Parcelable接口使用较为麻烦,但是效率很高,但是存在一个很大的缺点,就是被Parcelable将对象序列化以后,要将对象保存到磁盘中的,将会很麻烦。所以建议是使用Serializable。

Binder

直观来说,Binder是Android中的一个类,它实现了IBinder接口,从IPC的角度来说,Binder是Android中的一种跨进程通信的一种方式,同时还可以理解为是一种虚拟的物理设备,它的设备驱动是/dev/binder/。从Framework角度来说,Binder是ServiceManager的桥梁。从应用层来说,Binder是客户端和服务端进行通信的媒介。

在Android开发中,Binder主要用在Service中,包括AIDL和Messenger,由于Messenger的底层其实就是Aidl,所以现在我们以AIDL来分析一下binder的工作机制。

上代码:

/*

 * This file is auto-generated.  DO NOT MODIFY.

 * Original file: /Users/huangjialin/MyApplication/service/src/main/aidl/aidl/MyAIDLService.aidl

 */

package aidl;

// Declare any non-default types here with import statements

public interface MyAIDLService extends android.os.IInterface {

    /**

     * Local-side IPC implementation stub class.

     */

    public static abstract class Stub extends android.os.Binder implements aidl.MyAIDLService {

        private static final java.lang.String DESCRIPTOR = "aidl.MyAIDLService";

        /**

         * Construct the stub at attach it to the interface.

         */

        public Stub() {

            this.attachInterface(this, DESCRIPTOR);

        }

        /**

         * Cast an IBinder object into an aidl.MyAIDLService interface,

         * generating a proxy if needed.

         */

        public static aidl.MyAIDLService asInterface(android.os.IBinder obj) {

            if ((obj == null)) {

                return null;

            }

            android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);

            if (((iin != null) && (iin instanceof aidl.MyAIDLService))) {

                return ((aidl.MyAIDLService) iin);

            }

            return new aidl.MyAIDLService.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_getString: {

                    data.enforceInterface(DESCRIPTOR);

                    java.lang.String _result = this.getString();

                    reply.writeNoException();

                    reply.writeString(_result);

                    return true;

                }

            }

            return super.onTransact(code, data, reply, flags);

        }

        private static class Proxy implements aidl.MyAIDLService {

            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 java.lang.String getString() 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_getString, _data, _reply, 0);

                    _reply.readException();

                    _result = _reply.readString();

                } finally {

                    _reply.recycle();

                    _data.recycle();

                }

                return _result;

            }

        }

        static final int TRANSACTION_getString = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);

    }

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

}

上面这段代码是系统生成的,在gen目录下可以看到根据MyAIDLService.aidl系统为我们生成了MyAIDLService.java这个类。我们先来了解一下这个类中每个方法的含义:

DESCRIPTOR:Binder的唯一标识,一般用于当前Binder的类名表示。

asInterface(android.os.IBinder obj):用于将服务端的Binder对象转换成客户端所需的AIDL接口类型的对象,这种转化过程是区分进程的,如果客户端和服务端位于同一个进程,那么这个方法返回的是服务端的stub对象本身,否则返回的是系统封装后的Stub.proxy对象。

asBinder():用于返回当前Binder对象。

onTransact:该方法运行在服务端的Binder线程池中,当客户端发起跨进程通信请求的时候,远程请求通过系统底层封装后交给该方法处理。注意这个方法public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags),服务端通过code可以确定客户端所请求的目标方法是什么,接着从data中取出目标方法所需的参数,然后执行目标方法。当目标方法执行完毕后,就像reply中写入返回值。这个方法的执行过程就是这样的。如果这个方法返回false,客户端是会请求失败的,所以我们可以在这个方法中做一些安全验证。

public java.lang.String getString() throws android.os.RemoteException:

这个方法运行在客户端中,当客户端调用此方法的时候,它的内部实现是这样的:首先创建该方法所需要的输入类型Parcel对象_data,然后调用transact方法发起远程调用请求,同时当前线程挂起,然后服务端的OnTransact方法会被调用,直到RPC过程返回后,当前线程继续执行,并从_reply中读取返回的数据。

如图:Binder的工作机制

从上面分析,我们明白了Binder的工作机制但是要注意一些问题:

1.当客户端发起请求时,由于当前线程会被挂起,直到服务端返回数据,如果这个远程方法很耗时的话,那么是不能够在UI线程,也就是主线程中发起这个远程请求的。

2.由于Service的Binder方法运行在线程池中,所以Binder方法不管是耗时还是不耗时都应该采用同步的方式,因为它已经运行在一个线程中了。

以上就是浅谈Android IPC机制之Binder的工作机制的详细内容,更多关于Android IPC机制之Binder的工作机制的资料请关注我们其它相关文章!

(0)

相关推荐

  • 分析Android Choreographer源码

    一.前言 目前大部分手机都是 60Hz 的刷新率,也就是 16.6ms 刷新一次,系统为了配合屏幕的刷新频率,将 Vsync 的周期也设置为 16.6 ms,每个 16.6 ms , Vsync 信号唤醒 Choreographer 来做 App 的绘制操作,这就是引入 Choreographer 的主要作用.了解 Choreographer 还可以帮助 App 开发者知道程序每一帧运行的基本原理,也可以加深对 Message.Handler.Looper.MessageQueue.Measur

  • 详解Android性能优化之启动优化

    1.为什么要进行启动优化 网上流行一种说法,就是8秒定律,意思是说,如果用户在打开一个页面,在8秒的时间内还没有打开,那么用户大概的会放弃掉,意味着一个用户的流失.从这里就可以看出,启动优化的重要性了. 2.启动的分类 2.1 冷启动 先来看看冷启动的流程图 从图中可以看出,APP启动的过程是:ActivityManagerProxy 通过IPC来调用AMS(ActivityManagerService),AMS通过IPC启动一个APP进程,ApplicationThread通过反射来创建App

  • 浅谈Android中AsyncTask的工作原理

    概述 实际上,AsyncTask内部是封装了Thread和Handler.虽然AsyncTask很方便的执行后台任务,以及在主线程上更新UI,但是,AsyncTask并不合适进行特别耗时的后台操作,对于特别耗时的任务,个人还是建议使用线程池.好了,话不多说了,我们先看看AsyncTask的简单用法吧. AsyncTask使用方法 AsyncTask是一个抽象的泛型类.简单的介绍一下它的使用方式代码如下: package com.example.huangjialin.myapplication;

  • Android自定义view实现滑动解锁效果

    本文实例为大家分享了Android自定义view实现滑动解锁的具体代码,供大家参考,具体内容如下 1. 需求如下: 近期需要做一个类似屏幕滑动解锁的功能,右划开始,左划暂停. 2. 需求效果图如下 3. 实现效果展示 4. 自定义view如下 /** * Desc 自定义滑动解锁View * Author ZY * Mail sunnyfor98@gmail.com * Date 2021/5/17 11:52 */ @SuppressLint("ClickableViewAccessibili

  • 浅谈Android IPC机制之Binder的工作机制

    进程和线程的关系 按照操作系统中的描述,线程是CPU调度的最小单位,同时线程也是一种有限的系统资源.而进程一般是指一个执行单元,在pc端或者移动端上是指一个程序或者一个应用.一个进程中可以包含一个或者是多个线程.所以他们的关系应该是包含和被包含的关系. 跨进程的种类 在Android中跨进程通信的方式有很多种,Bundle,文件共享,AIDL,Messenger,ContentProvider,Socket,这些都能实现进程间之间的通信,当然,虽然都能够实现进程间通信,但是他们之间的实现原理或者

  • 浅谈Android Dialog窗口机制

    目录 问题引出 Dialog源码分析 构造方法 show()方法 问题引出 //创建dialog 方式一 AlertDialog.Builder builder=new AlertDialog.Builder(MainActivity.this); // 创建dialog 方式二 AlertDialog.Builderbuilder=new AlertDialog.Builder(getApplicationContex()); 区别在构造时候于一个传当前activity 一个Applicati

  • 浅谈Android Activity与Service的交互方式

    实现更新下载进度的功能 1. 通过广播交互 Server端将目前的下载进度,通过广播的方式发送出来,Client端注册此广播的监听器,当获取到该广播后,将广播中当前的下载进度解析出来并更新到界面上. 优缺点分析: 通过广播的方式实现Activity与Service的交互操作简单且容易实现,可以胜任简单级的应用.但缺点也十分明显,发送广播受到系统制约.系统会优先发送系统级广播,在某些特定的情况下,我们自定义的广播可能会延迟.同时在广播接收器中不能处理长耗时操作,否则系统会出现ANR即应用程序无响应

  • 浅谈Android中Service的注册方式及使用

    Service通常总是称之为"后台服务",其中"后台"一词是相对于前台而言的,具体是指其本身的运行并不依赖于用户可视的UI界面,因此,从实际业务需求上来理解,Service的适用场景应该具备以下条件: 1.并不依赖于用户可视的UI界面(当然,这一条其实也不是绝对的,如前台Service就是与Notification界面结合使用的): 2.具有较长时间的运行特性. 1.Service AndroidManifest.xml 声明 一般而言,从Service的启动方式上

  • 浅谈android性能优化之启动过程(冷启动和热启动)

    本文介绍了浅谈android性能优化之启动过程(冷启动和热启动) ,分享给大家,具体如下: 一.应用的启动方式 通常来说,启动方式分为两种:冷启动和热启动. 1.冷启动:当启动应用时,后台没有该应用的进程,这时系统会重新创建一个新的进程分配给该应用,这个启动方式就是冷启动. 2.热启动:当启动应用时,后台已有该应用的进程(例:按back键.home键,应用虽然会退出,但是该应用的进程是依然会保留在后台,可进入任务列表查看),所以在已有进程的情况下,这种启动会从已有的进程中来启动应用,这个方式叫热

  • 浅谈Android性能优化之内存优化

    1.Android内存管理机制 1.1 Java内存分配模型 先上一张JVM将内存划分区域的图 程序计数器:存储当前线程执行目标方法执行到第几行. 栈内存:Java栈中存放的是一个个栈帧,每个栈帧对应一个被调用的方法.栈帧包括局部标量表, 操作数栈. 本地方法栈:本地方法栈主要是为执行本地方法服务的.而Java栈是为执行Java方法服务的. 方法区:该区域被线程共享.主要存储每个类的信息(类名,方法信息,字段信息等).静态变量,常量,以及编译器编译后的代码等. 堆:Java中的堆是被线程共享的,

  • 浅谈Android插件化

    目录 一.认识插件化 1.1 插件化起源 1.2 插件化优点 1.3 与组件化的区别 二.插件化的技术难点 三.ClassLoader Injection 3.1 java 中的 ClassLoader 3.2 android 中的 ClassLoader 3.3 双亲委派机制 3.4 如何加载插件中的类 3.5 执行插件类的方法 四.Runtime Container 4.1 为什么没有注册的 Activity 不能和系统交互 4.2 运行时容器技术 4.3 字节码替换 五.Resource

  • 浅谈android中数据库的拷贝

    SQLiteDatabase不支持直接从assets读取文件,所以要提前拷贝数据库.在读取数据库时,先在项目中建立assets文件夹用于存放外部文件,将数据库文件拷到该目录下. 代码方法: /** * 拷贝数据库至file文件夹下 * @param dbName 数据库名称 */ private void initAddressDB(String dbName) { //1,在files文件夹下创建同名dbName数据库文件过程 File files=getFilesDir();//获取/dat

  • 浅谈android获取设备唯一标识完美解决方案

    本文介绍了浅谈android获取设备唯一标识完美解决方案,分享给大家,具体如下: /** * deviceID的组成为:渠道标志+识别符来源标志+hash后的终端识别符 * * 渠道标志为: * 1,andriod(a) * * 识别符来源标志: * 1, wifi mac地址(wifi): * 2, IMEI(imei): * 3, 序列号(sn): * 4, id:随机码.若前面的都取不到时,则随机生成一个随机码,需要缓存. * * @param context * @return */ p

随机推荐