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下 開源與商業化共存的一個成功典範。