androidbinder视频

㈠ 如何在android下使用Binder

实现一个binder通信实例，需要经过以下步骤：
（1）获得ServiceManager的对象引用

（2）向ServiceManager注册新的Service

（3）在Client中通过ServiceManager获得Service对象引用

（3）在Client中发送请求，由Service返回结果。

下面看具体的代码如何实现。

3.1 libmyservice代码实现

（1）新建目录frameworks/base/myservice/libservice，进入该目录

view plain
$ cd frameworks/base
$ mkdir myservice
$ cd myservice
$ mkdir libmyservice
$ cd libmyservice

（2）编写libmyservice/myservic.h文件

view plain
#include <utils/threads.h>

#include <utils/RefBase.h>

#include <binder/IInterface.h>

#include <binder/BpBinder.h>

#include <binder/Parcel.h>namespace android {

class MyService : public BBinder

{

mutable Mutex mLock;

int32_t mNextConnId;

public:

static int instantiate();

MyService();

virtual ~MyService();

virtual status_t onTransact(uint32_t, const Parcel&, Parcel*, uint32_t);

};

}; //namespace

(2)编写libservice/myservice.cpp文件

view plain
#include "myservice.h"

#include <binder/IServiceManager.h>

#include <binder/IPCThreadState.h>namespace android {static struct sigaction oldact;

static pthread_key_t sigbuskey;int MyService::instantiate()

{

LOGE("MyService instantiate");

// defaultServiceManager ()获得ServiceManager的对象引用，addService()可向ServiceManager注册新的服务

int r = defaultServiceManager()->addService(String16("android.myservice"), new MyService());

LOGE("MyService r = %d/n", r);

return r;

}MyService::MyService()

{

LOGV("MyService created");

mNextConnId = 1;

pthread_key_create(&sigbuskey, NULL);

}MyService::~MyService()

{

pthread_key_delete(sigbuskey);

LOGV("MyService destroyed");

}

// 每个系统服务都继承自BBinder类，都应重写BBinder的onTransact虚函数。当用户发送请求到达Service时，系统框架会调用Service的onTransact函数，该函数分析接收到的数据包，调用相应的接口函数处理请求

status_t MyService::onTransact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)

{

switch(code)

{

case 0: {

pid_t pid = data.readInt32();

int num = data.readInt32();

num = num + 100;

reply->writeInt32(num);

return NO_ERROR;

}

break;

default:

return BBinder::onTransact(code, data, reply, flags);

}

}

}; //namespace

（3）编写libservice/Android.mk文件

view plain
# File: Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES := myservice.cpp
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)
LOCAL_SHARED_LIBRARIES := libutils libbinder
LOCAL_MODULE_TAGS := optional
LOCAL_PRELINK_MODULE := false
LOCAL_MODULE := libmyservice

include $(BUILD_SHARED_LIBRARY)

（4）编译libmyservice.so动态库

在android源码主目录下

view plain
$ source build/envsetup.sh

including device/htc/passion/vendorsetup.sh

including device/samsung/crespo4g/vendorsetup.sh

including device/samsung/crespo/vendorsetup.sh


$ mmm frameworks/base/myservice/libmyservice/

编译成功后生成文件：out/target/proct/generic/system/lib/libmyservice.so

㈡ android binder 机制原理，能具体讲讲吗不要粘贴，要自己的理解o

binder在安卓中有个中间代理人的身份,就像是街头贴小广告的,他能提供一些特殊服务...,安卓开发中开启服务的方式有两种,一种是onStartCommand直接开启服务,这种服务开启之后如果不stopservice关闭服务的话,它会在后台一直运行,还有一种就是通过bindservice的方法开启服务,这种方法就是绑定服务,绑定之后会随着activity的关闭而销毁..在绑定服务的时候可以写一个内部类继承binder,然后再调用的时候可以写一个内部类实现serviceconnection接口,,在onServiceConnected的方法中会返回一个binder的代理人对象,这个代理人对象和绑定服务的binder对象是同一个对象,我已经测试过了,它们打印出来的地址是同一个地址..绑定成功之后就可以调用服务里面特殊的方法了.

㈢ android.media.AsyncPlayer这个类应该怎么用

代码结构：

Open Core 的代码在Android 代码的 External/Opencore 目录中 。这个目录是OpenCore
的根目录，其中包含的子目录如下所示 ：

android ：这里面是一个上层的库，它实现了一个为Android 使用的音视频采集，播放的接口，和DRM 数字版权管理的接口实现。

baselibs ：包含数据结构和线程安全等内容的底层库

codecs_v2 ：音视频的编解码器，基于 OpenMAX 实现

engines ：核心部分 ，多媒体 引擎的实现

extern_libs_v2 ：包含了 khronos 的 OpenMAX 的头文件

fileformats ：文件格式的解析( parser )工具

nodes ：提供一些PVMF 的NODE ，主要是编解码和文件解析方面的。

oscl ：操作系统兼容库

pvmi ： 输入输出控制的抽象接口

protocols ：主要是与网络相关的 RTSP 、 RTP 、 HTTP 等协议 的相关内容

pvcommon ： pvcommon 库文件的 Android.mk 文件，没有源文件。

pvplayer ： pvplayer 库文件的 Android.mk 文件，没有源文件。

pvauthor ： pvauthor 库文件的 Android.mk 文件，没有源文件。

tools_v2 ：编译工具以及一些可注册的模块。

本文主要介绍Android MediaPlayer的架构，主要由OpenCore 里的PV Player来实现的。

1.概述

Android的MediaPlayer包含了Audio和Video的播放功能，Music和Video两个应用程序都是调用MediaPlayer实现的。

代码主要分布在以下的目录中：

java程序的路径：

packages/apps/Music/src/com/android/music/

JAVA类的路径：

frameworks/base/media/java/android/media/MediaPlayer.java

JAVA本地调用部分(JNI)：

frameworks/base/media/jni/android_media_MediaPlayer.cpp

编译为 libmedia_jni.so

头文件：

frameworks/base/include/media/

多媒体库：

frameworks/base/media/libmedia/

编译为 libmedia.so

多媒体服务：

frameworks/base/media/libmediaplayerservice/

编译为 libmediaplayerservice.so

具体实现：

external/opencore/

编译为 libopencoreplayer.so

libopencoreplayer.so是主要的实现部分，其他的库基本上都是在其上建立的封装和为建立进程间通讯的机制。

2.框架

运行的时候，大致可以分成Client和Server两个部分，分别在两个进程中运行，使用Binder机制实现IPC通讯。从框架结构上来看，IMediaPlayerService.h、IMediaPlayerClient.h和MediaPlayer.h三个类定义了MeidaPlayer的接口和架构，MediaPlayerService.cpp和mediaplayer.cpp两个文件用于MeidaPlayer架构的实现，MeidaPlayer的具体功能在PVPlayer(库libopencoreplayer.so)中的实现。

2.1 IMediaPlayerClient.h

描述一个MediaPlayer客户端的接口

class IMediaPlayerClient: public IInterface

{

public:

DECLARE_META_INTERFACE(MediaPlayerClient);

virtual void notify(int msg, int ext1, int ext2) = 0;

};

class BnMediaPlayerClient: public BnInterface

{

public:

virtual status_t onTransact( uint32_t code,

const Parcel& data,

Parcel* reply,

uint32_t flags = 0);

};

在定义中，IMediaPlayerClient类继承IInterface，并定义了一个MediaPlayer客户端的接口，BnMediaPlayerClient继承了BnInterface，这是为基于Android的基础类Binder机制实现在进程通讯而构建的。事实上，根据BnInterface类模版的定义，BnInterface类相当于双继承了BnInterface和ImediaPlayerClient，这是Android一种常用的定义方式。

2.2 mediaplayer.h

对外的接口类，它最主要是定义了一个MediaPlayer类：

class MediaPlayer : public BnMediaPlayerClient

{

public:

MediaPlayer();

~MediaPlayer();

void onFirstRef();

void disconnect();

status_t setDataSource(const char *url);

status_t setDataSource(int fd, int64_t offset, int64_t length);

status_t setVideoSurface(const sp& surface);

status_t setListener(const sp& listener);

status_t prepare();

status_t prepareAsync();

status_t start();

status_t stop();

status_t pause();

bool isPlaying();

status_t getVideoWidth(int *w);

status_t getVideoHeight(int *h);

status_t seekTo(int msec);

status_t getCurrentPosition(int *msec);

status_t getDuration(int *msec);

status_t reset();

status_t setAudioStreamType(int type);

status_t setLooping(int loop);

status_t setVolume(float leftVolume, float rightVolume);

void notify(int msg, int ext1, int ext2);

static sp decode(const char* url, uint32_t *pSampleRate, int*
pNumChannels);

static sp decode(int fd, int64_t offset, int64_t length, uint32_t
*pSampleRate, int* pNumChannels);

//……

}

从接口中可以看出MediaPlayer类刚好实现了一个MediaPlayer的基本操作，例如播放(start)、停止(stop)、暂停(pause)等。

另外的一个类DeathNotifier在MediaPlayer类中定义，它继承了IBinder类中的DeathRecipient类：

class DeathNotifier: public IBinder:: DeathRecipient

{

public:

DeathNotifier() {}

virtual ~DeathNotifier();

virtual void binderDied(const wp& who);

};

事实上，MediaPlayer类正是间接地继承了IBinder，而MediaPlayer:: DeathNotifier类继承了IBinder::
DeathRecipient，这都是为了实现进程间通讯而构建的。

2.3 IMediaPlayer.h

主要的的内容是一个实现MediaPlayer功能的接口：

class IMediaPlayer: public IInterface

{

public:

DECLARE_META_INTERFACE(MediaPlayer);

virtual void disconnect() = 0;

virtual status_t setVideoSurface(const sp& surface) = 0;

virtual status_t prepareAsync() = 0;

virtual status_t start() = 0;

virtual status_t stop() = 0;

virtual status_t pause() = 0;

virtual status_t isPlaying(bool* state) = 0;

virtual status_t getVideoSize(int* w, int* h) = 0;

virtual status_t seekTo(int msec) = 0;

virtual status_t getCurrentPosition(int* msec) = 0;

virtual status_t getDuration(int* msec) = 0;

virtual status_t reset() = 0;

virtual status_t setAudioStreamType(int type) = 0;

virtual status_t setLooping(int loop) = 0;

virtual status_t setVolume(float leftVolume, float rightVolume) = 0;

};

class BnMediaPlayer: public BnInterface

{

public:

virtual status_t onTransact( uint32_t code,

const Parcel& data,

Parcel* reply,

uint32_t flags = 0);

};

在IMediaPlayer类中，主要定义MediaPlayer的功能接口，这个类必须被继承才能够使用。值得注意的是，这些接口和MediaPlayer类的接口有些类似，但是它们并没有直接的关系。事实上，在MediaPlayer类的各种实现中，一般都会通过调用IMediaPlayer类的实现类来完成。

2.4 头文件IMediaPlayerService.h

描述一个MediaPlayer的服务，定义方式如下所示：

class IMediaPlayerService: public IInterface

{

public:

DECLARE_META_INTERFACE(MediaPlayerService);

virtual sp create(pid_t pid, const
sp& client, const char* url) = 0;

virtual sp create(pid_t pid, const
sp& client, int fd, int64_t offset, int64_t length) =
0;

virtual sp decode(const char* url, uint32_t *pSampleRate, int*
pNumChannels) = 0;

virtual sp decode(int fd, int64_t offset, int64_t length, uint32_t
*pSampleRate, int* pNumChannels) = 0;

};

class BnMediaPlayerService: public BnInterface

{

public:

virtual status_t onTransact( uint32_t code,

const Parcel& data,

Parcel* reply,

uint32_t flags = 0);

};

由于有纯虚函数，IMediaPlayerService
以及BnMediaPlayerService必须被继承实现才能够使用，在IMediaPlayerService定义的create和decode等接口，事实上是必须被继承者实现的内容。注意，create的返回值的类型是sp，这个IMediaPlayer正是提供实现功能的接口。

3 实现

3.1 App

在packages/apps/Music/src/com/android/music/里的MediaPlaybackService.java文件中，包含了对MediaPlayer的调用。

在MediaPlaybackService.java中包含对包的引用：

import android.media.MediaPlayer;

在MediaPlaybackService类的内部，定义了MultiPlayer类：

private class MultiPlayer {

private MediaPlayer mMediaPlayer = new MediaPlayer();

}

MultiPlayer类中使用了MediaPlayer类，其中有一些对这个MediaPlayer的调用，调用的过程如下所示：

mMediaPlayer.reset();

mMediaPlayer.setDataSource(path);

mMediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC);

reset,setDataSource和setAudioStreamType等接口就是通过JAVA本地调用(JNI)来实现的。

3.2 Jni

在frameworks/base/media/jni/android_media_MediaPlayer.cpp中实现,其中android_media_MediaPlayer_reset函数的实现如下所示：

static void android_media_MediaPlayer_reset(JNIEnv *env, jobject thiz)

{

sp mp = getMediaPlayer(env, thiz);

if (mp == NULL ) {

jniThrowException(env, "java/lang/IllegalStateException", NULL);

return;

}

process_media_player_call( env, thiz, mp->reset(), NULL, NULL );

}

先获取一个MediaPlayer指针，通过对它的调用来实现实际的功能。

register_android_media_MediaPlayer用于将gMethods注册为的类"android/media/MediaPlayer"，其实现如下所示。

static int register_android_media_MediaPlayer(JNIEnv *env)

{

jclass clazz;

clazz = env->FindClass("android/media/MediaPlayer");

// ......

return AndroidRuntime::registerNativeMethods(env,
"android/media/MediaPlayer", gMethods, NELEM(gMethods));

}

"android/media/MediaPlayer"对应JAVA的类android.media.MediaPlayer。

3.3 libmedia.so

frameworks/base/media/libmedia/mediaplayer.cpp文件实现mediaplayer.h提供的接口，其中一个重要的片段如下所示：

const sp& MediaPlayer::getMediaPlayerService()

{

Mutex::Autolock _l(mServiceLock);

if (mMediaPlayerService.get() == 0) {

sp sm = defaultServiceManager();

sp binder;

do {

binder = sm->getService(String16("media.player"));

if (binder != 0)

break;

LOGW("MediaPlayerService not published, waiting...");

usleep(500000); // 0.5 s

} while(true);

if (mDeathNotifier == NULL) {

mDeathNotifier = new DeathNotifier();

}

binder->linkToDeath(mDeathNotifier);

mMediaPlayerService = interface_cast(binder);

}

LOGE_IF(mMediaPlayerService==0, "no MediaPlayerService!?");

return mMediaPlayerService;

}

其中最重要的一点是binder =
sm->getService(String16("media.player"));这个调用用来得到一个名称为"media.player"的服务，这个调用返回值的类型为IBinder，根据实现将其转换成类型IMediaPlayerService使用。

一个具体的函数setDataSource如下所示：

status_t MediaPlayer::setDataSource(const char *url)

{

LOGV("setDataSource(%s)", url);

status_t err = UNKNOWN_ERROR;

if (url != NULL) {

const sp& service(getMediaPlayerService());

if (service != 0) {

sp player(service->create(getpid(), this, url));

err = setDataSource(player);

}

}

return err;

}

㈣ 小弟我对android理解之Binder怎么解决

android使用binder作为进程间的通信工具。典型的应用是android的C/S机制，即client/service。使用这种
机制有以下优势:
1,可扩展性
2,有效性，一个service可以有多个client
3，安全性，client和service运行在不同的进程中，即使client出问题，不会影响到service的运行

我们今天以media_server作为例子来分析binder通信机制。
首先要有这个概念，android中有个服务总管叫servicemanager，mediaserver是负责向里面添加一些多媒体
服务的。所以从这个角度说的话，mediaserver是servicemanager的client。
在main_mediaserver.cpp中：
int main(int argc, char** argv)
{
sp<rocessState> proc(ProcessState::self());//1生成ProcessState对象
sp<IServiceManager> sm = defaultServiceManager();//2得到BpServiceManager(BpBinder(0))
LOGI("ServiceManager: %p", sm.get());
AudioFlinger::instantiate();//3初始化AudioFlinger实例，使用sm->addService()方法
MediaPlayerService::instantiate();
CameraService::instantiate();
AudioPolicyService::instantiate();
ProcessState::self()->startThreadPool();//4转化为调用下面的joinThreadPool
IPCThreadState::self()->joinThreadPool();//5talkwithdriver,为该server中的service服务
/*这样相当于两个线程在和Binder驱动对话，为server中的所有service工作，随时获取各个service的client发来的数据，并进行处理*/
}
我们先看第一部分sp<rocessState> proc(ProcessState::self())：
上面可以写成proc=ProcessState::self()，下面看ProcessState::self()：
sp<rocessState> ProcessState::self()
{
if (gProcess != NULL) return gProcess;//在Static.cpp中定义，全局变量,同时可以看出是单例模式

AutoMutex _l(gProcessMutex);
if (gProcess == NULL) gProcess = new ProcessState;//ProcessState对象
return gProcess;
}
比较简单，返回ProcessState对象，我们看下它的构造函数：
ProcessState:rocessState()
: mDriverFD(open_driver())//打开的就是binder驱动
, mVMStart(MAP_FAILED)
, mManagesContexts(false)
, mBinderContextCheckFunc(NULL)
, mBinderContextUserData(NULL)
, mThreadPoolStarted(false)
, mThreadPoolSeq(1)
{
...
mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
...
}
我们看到构造函数中打开了binder驱动，然后映射内存。

2，sp<IServiceManager> sm = defaultServiceManager();
该部分是非常重要的部分，对它的分析直接决定了后面的分析成败。我们找到defaultServiceManager()定义：
sp<IServiceManager> defaultServiceManager()
{
if (gDefaultServiceManager != NULL) return gDefaultServiceManager;//同样也是单例模式

{
AutoMutex _l(gDefaultServiceManagerLock);
if (gDefaultServiceManager == NULL) {
gDefaultServiceManager = interface_cast<IServiceManager>(//interface_cast是个模板，返回IServiceManager::asInterface(obj)，asInterface使用的是宏定义DECLARE_META_INTERFACE,使用IMPLEMENT_META_INTERFACE宏实现
ProcessState::self()->getContextObject(NULL));//返回BpBinder(0)
}
}

return gDefaultServiceManager;//BpServiceManager(BpBinder(0))
}
我们先看ProcessState::self()->getContextObject(NULL)：
sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& caller)
{
if (supportsProcesses()) {//判断Binder打开是否正确
return getStrongProxyForHandle(0);//返回BpBinder(0)
} else {
return getContextObject(String16("default"), caller);
}
}
我们在看getStrongProxyForHandle(0)：
sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)//注意上面传下来的参数是0
{
sp<IBinder> result;

AutoMutex _l(mLock);

handle_entry* e = lookupHandleLocked(handle);//寻找0handle，如果没有则创建

if (e != NULL) {
// We need to create a new BpBinder if there isn't currently one, OR we
// are unable to acquire a weak reference on this current one. See comment
// in getWeakProxyForHandle() for more info about this.
IBinder* b = e->binder;
if (b == NULL || !e->refs->attemptIncWeak(this)) {
b = new BpBinder(handle);//!!!根据上面传下来的handle，这里生成BpBinder(0)
e->binder = b;
if (b) e->refs = b->getWeakRefs();
result = b;
} else {
// This little bit of nastyness is to allow us to add a primary
// reference to the remote proxy when this team doesn't have one
// but another team is sending the handle to us.
result.force_set(b);
e->refs->decWeak(this);
}
}

return result;
}
到这里，我们知道了ProcessState::self()->getContextObject(NULL)返回了BpBinder(0),那回到原先的defaultServiceManager()中，也就是：
gDefaultServiceManager = interface_cast<IServiceManager>(BpBinder(0))。
我们看下interface_cast定义：
template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
return INTERFACE::asInterface(obj);
}
将上面带入即：
gDefaultServiceManager = IServiceManager::asInterface(BpBinder(0));
我们到IServiceManager.h中并没有找到asInterface定义，但是我们发现由这个宏：
class IServiceManager : public IInterface
{
public:
DECLARE_META_INTERFACE(ServiceManager);
...
}

㈤ 安卓中的Binder架构是什么为什么要提供BinderService与Binder又有怎样的联系

建议您查找工具书，这么专业的只是怕是解决不了，抱歉，只能粗略的给您解释一下。Android 整体架构，不识庐山真面目，只缘身在此山中，所以我们先来大概看下 Android 这座大山的整体轮廓。我们先从 Android 的整体架构来看看 Binder 是处于什么地位，其实很简单，就是完成一个手机该有的核心功能如短信的收发管理、电话的接听、挂断以及应用程序的包管理、Activity 的管理等等。
Android 中“应用程序框架层”以 SDK 的形式开放给开发者使用，“系统服务层”中的核心服务随系统启动而运行，通过应用层序框架层提供的 Manager 实时为应用程序提供服务调用。系统服务层中每一个服务运行在自己独立的进程空间中，应用程序框架层中的 Manager 通过 Binder IPC 的方式调用系统服务层中的服务。Binder是Android系统进程间通信（IPC）方式之一 linux已经拥有的进程间通信IPC手段包括(Internet Process Connection)。
管道（Pipe）、信号（Signal）和跟踪（Trace）、插口（Socket）、报文队列（Message）、共享内存（Share Memory）和信号量（Semaphore）。本文详细介绍Binder作为Android主要IPC方式的优势。

㈥ 学习android binder 有哪些系列

一.Linux系统进程间通信有哪些方式？
1.socket；
2.name pipe命名管道；
3.message queue消息队列；
4.singal信号量；
5.share memory共享内存；

二.Java系统的通信方式是什么？
1.socket;
2.name pipe;

三.Android系统通信方式是什么？
Binder 通信；

四.Binder通信是如何实现的？
1.Binder通信是通过linux的binder driver来实现的，
2.Binder通信操作类似线程迁移(thread
migration)，两个进程间IPC看起来就象是一个进程进入另一个进程执行代码然后带着执行的结果返回；
3.Binder的用户空间为每一个进程维护着一个可用的线程池，线程池用于处理到来的IPC以及执行进程本地消息，Binder通信是同步而不是异步。

五.Binder通信的特点是什么？
是同步，而不是异步；

六. Android中的 Binder通信实现要点：
1.
Android中的Binder通信是基于Service与Client的工作模型的；
2. 所有需要IBinder通信的进程都必须创建一个IBinder接口；
3. 系统中有一个进程管理所有的system service：
4. Android不允许用户添加非授权的System service；
5. 对用户程序来说，可以创建自己的server,或者Service用于进程间通信；
6.
ActivityManagerService管理JAVA应用层所有的service创建与连接(connect),disconnect；
7. 所有的Activity也是通过这个service来启动，加载的；
8. ActivityManagerService也是加载在Systems Servcie中的；

七.Android的
Service工作流程
1.Android虚拟机启动之前系统会先启动service
Manager进程；
2.service Manager打开binder驱动，并通知binder kernel驱动程序这个进程将作为System
Service Manager；
3.然后该进程将进入一个循环，等待处理来自其他进程的数据。
4.用户创建一个System
service后，通过defaultServiceManager得到一个远程ServiceManager的接口，通过这个接口我们可以调用addService函数将System
service添加到Service Manager进程中；
5.然后client可以通过getService获取到需要连接的目的Service的IBinder对象，这个IBinder是Service的BBinder在binder
kernel的一个参考，
6.所以service IBinder 在binder
kernel中不会存在相同的两个IBinder对象，每一个Client进程同样需要打开Binder驱动程序。对用户程序而言，我们获得这个对象就可以通过binder
kernel访问service对象中的方法。
7.Client与Service在不同的进程中，通过这种方式实现了类似线程间的迁移的通信方式，对用户程序而言当调用Service返回的IBinder接口后，访问Service中的方法就如同调用自己的函数

㈦ android Binder具体是干什么用的

Binder主要能提供以下一些功能：
用驱动程序来推进进程间的通信。
通过共享内存来提高性能。
为进程请求分配每个进程的线程池。
针对系统中的对象引入了引用计数和跨进程的对象引用映射。
进程间同步调用。

Android Binder设计与实现 – 设计篇：
目前linux支持的IPC包括传统的管道、System V IPC、即消息队列/共享内存/信号量，以及socket中只有socket支持Client-Server的通信方式。
当然也可以在这些底层机制上架设一套协议来实现Client-Server通信，但这样增加了系统的复杂性，在手机这种条件复杂，资源稀缺的环境下可靠性也难以保证。
另一方面是传输性能:
socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信。
消息队列和管道采用存储-转发方式，即数据先从发送方缓存区拷贝到内核开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，
至少有两次拷贝过程。共享内存虽然无需拷贝，但控制复杂，难以使用。
还有一点是出于安全性考虑:

Android作为一个开放式，拥有众多开发者的平台，应用程序的来源广泛，确保智能终端的安全是非常重要的。

终端用户不希望从网上下载的程序在不知情的情况下偷窥隐私数据，连接无线网络，长期操作底层设备导致电池很快耗尽等等。传统IPC没有任何

安全措施，完全依赖上层协议来确保。首先传统IPC的接收方无法获得对方进程可靠的UID/PID（用户ID/进程ID），从而无法鉴别对方身份。

Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志。使用传统IPC只能由用户在数据包里填入UID/PID，

但这样不可靠，容易被恶意程序利用。可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。

比如命名管道的名称、system V的键值、socket的ip地址或文件名都是开放的，只要知道这些接入点的程序都可以和对端建立连接，不管怎样都无法

阻止恶意程序通过猜测接收方地址获得连接。

基于以上原因，Android需要建立一套新的IPC机制来满足系统对通信方式，传输性能和安全性的要求，这就是Binder。

Binder基于 Client-Server通信模式，传输过程只需一次拷贝，为发送发添加UID/PID身份，既支持实名Binder也支持匿名Binder，安全性高。

面向对象的 Binder IPC：

面向对象思想的引入将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法，而其独特之处在于Binder对象是一个

可以跨进程引用的对象，它的实体位于一个进程中，而它的引用却遍布于系统的各个进程之中。最诱人的是，这个引用和java里引用

一样既可以是强类型，也可以是弱类型，而且可以从一个进程传给其它进程，让大家都能访问同一Server，就像将一个对象或引用赋

值给另一个引用一样。Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中。

面向对象只是针对应用程序而言，对于Binder驱动和内核其它模块一样使用C语言实现，没有类和对象的概念。

Binder驱动为面向对象的进程间通信提供底层支持。

㈧ Android Binder是什么binder属于一个驱动

Android中使用Binder进行进程间通讯。ViewBinder应该是一个Binder类，上次应用调用到这个类，这个类再调用底层相应的库。

㈨ 安卓中的Binder架构是什么为什么要提供Binder

1）从性能的角度数据拷贝次数：Binder数据拷贝只需要一次，而管道、消息队列、Socket都需要2次，但共享内存方式一次内存拷贝都不需要；从性能角度看，Binder性能仅次于共享内存。（2）从稳定性的角度Binder是基于C/S架构的，简单解释下C/S架构，是指客户端(Client)和服务端(Server)组成的架构，Client端有什么需求，直接发送给Server端去完成，架构清晰明朗，Server端与Client端相对独立，稳定性较好；而共享内存实现方式复杂，没有客户与服务端之别， 需要充分考虑到访问临界资源的并发同步问题，否则可能会出现死锁等问题；从这稳定性角度看，Binder架构优越于共享内存。仅仅从以上两点，各有优劣，还不足以支撑google去采用binder的IPC机制，那么更重要的原因是：（3）从安全的角度传统Linux IPC的接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份；而Android作为一个开放的开源体系，拥有非常多的开发平台，App来源甚广，因此手机的安全显得额外重要；对于普通用户，绝不希望从App商店下载偷窥隐射数据、后台造成手机耗电等等问题，传统Linux IPC无任何保护措施，完全由上层协议来确保。 Android为每个安装好的应用程序分配了自己的UID，故进程的UID是鉴别进程身份的重要标志，前面提到C/S架构，Android系统中对外只暴露Client端，Client端将任务发送给Server端，Server端会根据权限控制策略，判断UID/PID是否满足访问权限，目前权限控制很多时候是通过弹出权限询问对话框，让用户选择是否运行。Android 6.0，也称为Android M，在6.0之前的系统是在App第一次安装时，会将整个App所涉及的所有权限一次询问，只要留意看会发现很多App根本用不上通信录和短信，但在这一次性权限权限时会包含进去，让用户拒绝不得，因为拒绝后App无法正常使用，而一旦授权后，应用便可以胡作非为。针对这个问题，google在Android M做了调整，不再是安装时一并询问所有权限，而是在App运行过程中，需要哪个权限再弹框询问用户是否给相应的权限，对权限做了更细地控制，让用户有了更多的可控性，但同时也带来了另一个用户诟病的地方，那也就是权限询问的弹框的次数大幅度增多。对于Android M平台上，有些App开发者可能会写出让手机异常频繁弹框的App，企图直到用户授权为止，这对用户来说是不能忍的，用户最后吐槽的可不光是App，还有Android系统以及手机厂商，有些用户可能就跳果粉了，这还需要广大Android开发者以及手机厂商共同努力，共同打造安全与体验俱佳的Android手机。Android中权限控制策略有SELinux等多方面手段，下面列举从Binder的一个角度的权限控制：Android源码的Binder权限是如何控制？ -Gityuan的回答传统IPC只能由用户在数据包里填入UID/PID；另外，可靠的身份标记只有由IPC机制本身在内核中添加。其次传统IPC访问接入点是开放的，无法建立私有通道。从安全角度，Binder的安全性更高。说到这，可能有人要反驳，Android就算用了Binder架构，而现如今Android手机的各种流氓软件，不就是干着这种偷窥隐射，后台偷偷跑流量的事吗？没错，确实存在，但这不能说Binder的安全性不好，因为Android系统仍然是掌握主控权，可以控制这类App的流氓行为，只是对于该采用何种策略来控制，在这方面android的确存在很多有待进步的空间，这也是google以及各大手机厂商一直努力改善的地方之一。在Android 6.0，google对于app的权限问题作为较多的努力，大大收紧的应用权限；另外，在Google举办的Android Bootcamp 2016大会中，google也表示在Android 7.0 （也叫Android N）的权限隐私方面会进一步加强加固，比如SELinux，Memory safe language(还在research中)等等，在今年的5月18日至5月20日，google将推出Android N。 （4）从语言层面的角度大家多知道Linux是基于C语言(面向过程的语言)，而Android是基于Java语言(面向对象的语句)，而对于Binder恰恰也符合面向对象的思想，将进程间通信转化为通过对某个Binder对象的引用调用该对象的方法，而其独特之处在于Binder对象是一个可以跨进程引用的对象，它的实体位于一个进程中，而它的引用却遍布于系统的各个进程之中。可以从一个进程传给其它进程，让大家都能访问同一Server，就像将一个对象或引用赋值给另一个引用一样。Binder模糊了进程边界，淡化了进程间通信过程，整个系统仿佛运行于同一个面向对象的程序之中。从语言层面，Binder更适合基于面向对象语言的Android系统，对于Linux系统可能会有点“水土不服”。另外，Binder是为Android这类系统而生，而并非Linux社区没有想到Binder IPC机制的存在，对于Linux社区的广大开发人员，我还是表示深深佩服，让世界有了如此精湛而美妙的开源系统。也并非Linux现有的IPC机制不够好，相反地，经过这么多优秀工程师的不断打磨，依然非常优秀，每种Linux的IPC机制都有存在的价值，同时在Android系统中也依然采用了大量Linux现有的IPC机制，根据每类IPC的原理特性，因时制宜，不同场景特性往往会采用其下最适宜的。比如在Android OS中的Zygote进程的IPC采用的是Socket（套接字）机制，Android中的Kill Process采用的signal（信号）机制等等。而Binder更多则用在system_server进程与上层App层的IPC交互。(5) 从公司战略的角度总所周知，Linux内核是开源的系统，所开放源代码许可协议GPL保护，该协议具有“病毒式感染”的能力，怎么理解这句话呢？受GPL保护的Linux Kernel是运行在内核空间，对于上层的任何类库、服务、应用等运行在用户空间，一旦进行SysCall（系统调用），调用到底层Kernel，那么也必须遵循GPL协议。 而Android 之父 Andy Rubin对于GPL显然是不能接受的，为此，Google巧妙地将GPL协议控制在内核空间，将用户空间的协议采用Apache-2.0协议（允许基于Android的开发商不向社区反馈源码），同时在GPL协议与Apache-2.0之间的Lib库中采用BSD证授权方法，有效隔断了GPL的传染性，仍有较大争议，但至少目前缓解Android，让GPL止步于内核空间，这是Google在GPL Linux下 开源与商业化共存的一个成功典范。