android基础部分再学习---Binder
2016-04-05 10:24
393 查看
参考文章：http://blog.csdn.net/coding_glacier/article/details/7520199
1．binder通信概述
binder通信是一种client-server的通信结构，
1.从表面上来看，是client通过获得一个server的代理接口，对server进行直接调用；
2.实际上，代理接口中定义的方法与server中定义的方法是一一对应的；
3.client调用某个代理接口中的方法时，代理接口的方法会将client传递的参数打包成为Parcel对象；
4.代理接口将该Parcel发送给内核中的binder driver.
5.server会读取binder driver中的请求数据，如果是发送给自己的，解包Parcel对象，处理并将结果返回；
6.整个的调用过程是一个同步过程，在server处理的时候，client会block住。
任何service在被使用之前，均要向SM(Service Manager)注册，同时客户端需要访问某个service时，应该首先向SM查询是否存在该服务。如果SM存在这个service，那么会将该service的handle返回给client，handle是每个service的唯一标识符。
SM的入口函数在service_manager.c中，下面是SM的代码部分
int main(int argc, char **argv)
{
struct binder_state *bs;
void *svcmgr = BINDER_SERVICE_MANAGER;
bs = binder_open(128*1024);
if (binder_become_context_manager(bs)) {
LOGE("cannot become context manager (%s)/n", strerror(errno));
return -1;
}
svcmgr_handle = svcmgr;
binder_loop(bs, svcmgr_handler);
return 0;
}
这个进程的主要工作如下：
1.初始化binder，打开/dev/binder设备；在内存中为binder映射128K字节空间；
2.指定SM对应的代理binder的handle为0，当client尝试与SM通信时，需要创建一个handle为0的代理binder，这里的代理binder其实就是第一节中描述的那个代理接口；
3.通知binder driver(BD)使SM成为BD的context manager；
4.维护一个死循环，在这个死循环中，不停地去读内核中binder driver，查看是否有可读的内容；即是否有对service的操作要求, 如果有，则调用svcmgr_handler回调来处理请求的操作。
5.SM维护了一个svclist列表来存储service的信息。
这里需要声明一下，当service在向SM注册时，该service就是一个client，而SM则作为了server。而某个进程需要与service通信时，此时这个进程为client，service才作为server。因此service不一定为server，有时它也是作为client存在的。
由于下面几节会介绍一些与binder通信相关的几个概念，所以将SM的功能介绍放在了后面的部分来讲。
应用和service之间的通信会涉及到2次binder通信。
1.应用向SM查询service是否存在，如果存在获得该service的代理binder，此为一次binder通信；
2.应用通过代理binder调用service的方法，此为第二次binder通信。
ProcessState有如下2个主要功能：
1.创建一个thread,该线程负责与内核中的binder模块进行通信，称该线程为Pool thread；
2.为指定的handle创建一个BpBinder对象，并管理该进程中所有的BpBinder对象。
下面是 Pool thread的启动方式：
ProcessState::self()->startThreadPool();
BpBinder(int32_t handle);
通过BpBinder的构造函数发现，BpBinder会将当前通信中server的handle记录下来，当有数据发送时，会通知BD数据的发送目标。
ProcessState通过如下方式来获取BpBinder对象：
ProcessState::self()->getContextObject(handle);
在这个过程中，ProcessState会维护一个BpBinder的vector mHandleToObject，每当ProcessState创建一个BpBinder的实例时，回去查询mHandleToObject，如果对应的handle已经有binder指针，那么不再创建，否则创建binder并插入到mHandleToObject中。
ProcessState创建的BpBinder实例，一般情况下会作为参数构建一个client端的代理接口，这个代理接口的形式为BpINTERFACE,例如在与SM通信时，client会创建一个代理接口BpServiceManager.
Pool thread的实际内容则为：
IPCThreadState::self()->joinThreadPool();
ProcessState中有2个Parcel成员，mIn和mOut，Pool thread会不停的查询BD中是否有数据可读，如果有将其读出并保存到mIn，同时不停的检查mOut是否有数据需要向BD发送，如果有，则将其内容写入到BD中，总而言之，从BD中读出的数据保存到mIn，待写入到BD中的数据保存在了mOut中。
ProcessState中生成的BpBinder实例通过调用IPCThreadState的transact函数来向mOut中写入数据，这样的话这个binder IPC过程的client端的调用请求的发送过程就明了了。
IPCThreadState有两个重要的函数，talkWithDriver函数负责从BD读写数据，executeCommand函数负责解析并执行mIn中的数据。
为server端提供接口，它的子类声明了service能够实现的所有的方法；
5.2基类IBinder
BBinder与BpBinder均为IBinder的子类，因此可以看出IBinder定义了binder IPC的通信协议，BBinder与BpBinder在这个协议框架内进行的收和发操作，构建了基本的binder IPC机制。
5.3基类BpRefBase
client端在查询SM获得所需的的BpBinder后，BpRefBase负责管理当前获得的BpBinder实例。
下面看一下BpINTERFACE的原型：
class BpINTERFACE : public BpInterface<IINTERFACE>
顺着继承关系再往上看
template<typename INTERFACE>
class BpInterface : public INTERFACE, public BpRefBase
BpINTERFACE分别继承自INTERFACE，和BpRefBase；
● BpINTERFACE既实现了service中各方法的本地操作，将每个方法的参数以Parcel的形式发送给BD。
例如BpServiceManager的
virtual status_t addService(const String16& name, const sp<IBinder>& service)
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
}
● 同时又将BpBinder作为了自己的成员来管理，将BpBinder存储在mRemote中，BpServiceManager通过调用BpRefBase的remote()来获得BpBinder指针。
顺着BnINTERFACE的继承关系再往上看，
class BnINTERFACE: public BnInterface<IINTERFACE>
IINTERFACE为client端的代理接口BpINTERFACE和server端的BnINTERFACE的共同接口类，这个共同接口类的目的就是保证service方法在C-S两端的一致性。
再往上看
class BnInterface : public INTERFACE, public BBinder
同时我们发现了BBinder类型，这个类型又是干什么用的呢？既然每个service均可视为一个binder，那么真正的server端的binder的操作及状态的维护就是通过继承自BBinder来实现的。可见BBinder是service作为binder的本质所在。
那么BBinder与BpBinder的区别又是什么呢？
其实它们的区别很简单，BpBinder是client端创建的用于消息发送的代理，而BBinder是server端用于接收消息的通道。查看各自的代码就会发现，虽然两个类型均有transact的方法，但是两者的作用不同，BpBinder的transact方法是向IPCThreadState实例发送消息，通知其有消息要发送给BD；而BBinder则是当IPCThreadState实例收到BD消息时，通过BBinder的transact的方法将其传递给它的子类BnSERVICE的onTransact函数执行server端的操作。
简单的Parcel读写不再介绍，下面着重介绍一下2个函数
virtual status_t addService(const String16& name, const sp<IBinder>& service)
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
}
看一下writeStrongBinder的实体
status_t Parcel::writeStrongBinder(const sp<IBinder>& val)
{
return flatten_binder(ProcessState::self(), val, this);
}
接着往里看flatten_binder
status_t flatten_binder(const sp<ProcessState>& proc,
const sp<IBinder>& binder, Parcel* out)
{
flat_binder_object obj;
obj.flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;
if (binder != NULL) {
IBinder *local = binder->localBinder();
if (!local) {
BpBinder *proxy = binder->remoteBinder();
if (proxy == NULL) {
LOGE("null proxy");
}
const int32_t handle = proxy ? proxy->handle() : 0;
obj.type = BINDER_TYPE_HANDLE;
obj.handle = handle;
obj.cookie = NULL;
} else {
obj.type = BINDER_TYPE_BINDER;
obj.binder = local->getWeakRefs();
obj.cookie = local;
}
} else {
obj.type = BINDER_TYPE_BINDER;
obj.binder = NULL;
obj.cookie = NULL;
}
return finish_flatten_binder(binder, obj, out);
}
还是拿addService为例，它的参数为一个BnINTERFACE类型指针，BnINTERFACE又继承自BBinder，
BBinder* BBinder::localBinder()
{
return this;
}
所以写入到Parcel的binder类型为BINDER_TYPE_BINDER，同时你在阅读SM的代码时会发现如果SM收到的service的binder类型不为BINDER_TYPE_HANDLE时，SM将不会将此service添加到svclist，但是很显然每个service的添加都是成功的，addService在开始传递的binder类型为BINDER_TYPE_BINDER，SM收到的binder类型为BINDER_TYPE_HANDLE，那么这个过程当中究竟发生了什么？
为了搞明白这个问题，花费我很多的事件，最终发现了问题的所在，原来在BD中做了如下操作(drivers/staging/android/Binder.c)：
static void binder_transaction(struct binder_proc *proc,
struct binder_thread *thread,
struct binder_transaction_data *tr, int reply)
{
..........................................
if (fp->type == BINDER_TYPE_BINDER)
fp->type = BINDER_TYPE_HANDLE;
else
fp->type = BINDER_TYPE_WEAK_HANDLE;
fp->handle = ref->desc;
..........................................
}
阅读完addService的代码，你会发现SM只是保存了service binder的handle和service的name，那么当client需要和某个service通信了，如何获得service的binder呢？看下一个函数
sp<IBinder> Parcel::readStrongBinder() const
{
sp<IBinder> val;
unflatten_binder(ProcessState::self(), *this, &val);
return val;
}
往里查看unflatten_binder
status_t unflatten_binder(const sp<ProcessState>& proc,
const Parcel& in, sp<IBinder>* out)
{
const flat_binder_object* flat = in.readObject(false);
if (flat) {
switch (flat->type) {
case BINDER_TYPE_BINDER:
*out = static_cast<IBinder*>(flat->cookie);
return finish_unflatten_binder(NULL, *flat, in);
case BINDER_TYPE_HANDLE:
*out = proc->getStrongProxyForHandle(flat->handle);
return finish_unflatten_binder(
static_cast<BpBinder*>(out->get()), *flat, in);
}
}
return BAD_TYPE;
}
发现如果server返回的binder类型为BINDER_TYPE_BINDER的话，也就是返回一个binder引用的话，直接获取这个binder；如果server返回的binder类型为BINDER_TYPE_HANDLE时，也就是server返回的仅仅是binder的handle，那么需要重新创建一个BpBinder返回给client。
有上面的代码可以看出，SM保存的service的binder仅仅是一个handle，而client则是通过向SM获得这个handle，从而重新构建代理binder与server通信。
这里顺带提一下一种特殊的情况，binder通信的双方即可作为client，也可以作为server.也就是说此时的binder通信是一个半双工的通信。那么在这种情况下，操作的过程会比单工的情况复杂，但是基本的原理是一样的，有兴趣可以分析一下MediaPlayer和MediaPlayerService的例子。
int main(int argc, char** argv)
{
//创建进程mediaserver的ProcessState实例
sp<ProcessState> proc(ProcessState::self());
//获得SM的BpServiceManager
sp<IServiceManager> sm = defaultServiceManager();
LOGI("ServiceManager: %p", sm.get());
//添加mediaserver中支持的service。
AudioFlinger::instantiate();
MediaPlayerService::instantiate();
CameraService::instantiate();
AudioPolicyService::instantiate();
//启动ProcessState的pool thread
ProcessState::self()->startThreadPool();
//这一步有重复之嫌，加不加无关紧要。
IPCThreadState::self()->joinThreadPool();
}
Binder的Java框架层部分方法的实现在本地代码里，源码位于frameworks/base/core/jni。
与Binder本地框架类似，声明的binder service接口必须继承自IInterface，这里ICloudManager继承自IInterface。与Binder 本地框架层不相同的是，Java层的IBinder接口直接继承自IInterface，而本地的IBinder类继承自RefBase。本地的IBinder有两个子类，BBinder和BpBinder，Java层的IBinder接口也有两个子类，Binder和BinderProxy。Java层服务端的CloudManager (binder service实体类)
直接继承自Binder类，并实现了binder service接口ICloudManager，而客户端的CloudManagerProxy类只需实现binder service接口ICloudManager即可。
binder 的使用例子：
参考地址：http://blog.csdn.net/lilian0118/article/details/24397953
在Java Service当中，会经常使用到AIDL工具，AIDL在google官方文档的解释是："AIDL (Android Interface Definition Language) is similar to other IDLs you might have worked
with. It allows you to define the programming interface that both the client and service agree upon in order to communicate with each other using interprocess communication (IPC)"。即AIDL是一种接口描述语言，用于定义client和service共同认可的接口。听起来比较绕口，直接来看IWifiManger.aidl的大致内容：
[cpp] view
plain copy
interface IWifiManager
{
List<WifiConfiguration> getConfiguredNetworks();
int addOrUpdateNetwork(in WifiConfiguration config);
boolean removeNetwork(int netId);
boolean enableNetwork(int netId, boolean disableOthers);
boolean disableNetwork(int netId);
boolean pingSupplicant();
void startScan(in WorkSource ws);
List<ScanResult> getScanResults(String callingPackage);
void disconnect();
void reconnect();
void reassociate();
这里定义了一系列的函数接口，在AIDL中除了支持Java原始类型数据（int、long、char、boolean等），还支持String、CharSequence、list和map。进过AIDL工具的转换，就可以将上面的aidl文件生成一个Java文件，其内容大致如下：
[java] view
plain copy
public interface IWifiManager extends android.os.IInterface {
public static abstract class Stub extends android.os.Binder implements
android.net.wifi.IWifiManager {
private static final java.lang.String DESCRIPTOR = "android.net.wifi.IWifiManager";
public Stub() {
this.attachInterface(this, DESCRIPTOR);
}
public static android.net.wifi.IWifiManager asInterface(
android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = (android.os.IInterface) obj
.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof android.net.wifi.IWifiManager))) {
return ((android.net.wifi.IWifiManager) iin);
}
return new android.net.wifi.IWifiManager.Stub.Proxy(obj);
}
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) {
}
}
return super.onTransact(code, data, reply, flags);
}
private static class Proxy implements android.net.wifi.IWifiManager {
private android.os.IBinder mRemote;
Proxy(android.os.IBinder remote) {
mRemote = remote;
}
public android.os.IBinder asBinder() {
return mRemote;
}
public java.lang.String getInterfaceDescriptor() {
return DESCRIPTOR;
}
}
IWifiManager.java中主要包含三个类：IWifiManager类、IWifiManager.Stub类、IWifiManager.Stub.Proxy类，WifiSerive就是继承于IWifiManager.Stub类。前面我们已经看过它的关系了，下面来看一般获取WifiService的方法：
[java] view
plain copy
IBinder b = ServiceManager.getService(WIFI_SERVICE);
IWifiManager service = IWifiManager.Stub.asInterface(b);
return new WifiManager(ctx.getOuterContext(), service);
这里调用ServiceManager的getService方法，WIFI_SERVICE就是"wifi"字串：
[cpp] view
plain copy
public static IBinder getService(String name) {
try {
IBinder service = sCache.get(name);
if (service != null) {
return service;
} else {
return getIServiceManager().getService(name);
}
} catch (RemoteException e) {
Log.e(TAG, "error in getService", e);
}
return null;
}
sCache用于缓存所有使用过的Java Service，它有ActivityManagerService在fork进程的时候拷贝进来，我们以后分析到AMS的时候再来看sCache，这里先假设sCache并没有我们想要的"wifi" service。然后调用getIServiceManager()的getService方法。前面分析过getIServiceManager()其实最后就是返回ServiceManagerProxy(BinderProxy)，所以这里调用ServiceManagerProxy的getService方法：
[java] view
plain copy
public IBinder getService(String name) throws RemoteException {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IServiceManager.descriptor);
data.writeString(name);
mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
IBinder binder = reply.readStrongBinder();
reply.recycle();
data.recycle();
return binder;
}
首先获取两个Parcel对象，然后向data中写入Strict mode和"android.os.IServiceManager"，然后再写入想要获取的service名字，即“wifi”。再调用mRemote.transact方法，这里的实现在android_util_Binder.cpp中，我们前面一章分析过，这里直接调用BpBinder(0)的transact方法，将GET_SERVICE_TRANSACTION命令发往binder驱动。我们来看Java层如何从Parcel中读取想要的Servcie：
[cpp] view
plain copy
public final IBinder readStrongBinder() {
return nativeReadStrongBinder(mNativePtr);
}
static jobject android_os_Parcel_readStrongBinder(JNIEnv* env, jclass clazz, jint nativePtr)
{
Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
if (parcel != NULL) {
return javaObjectForIBinder(env, parcel->readStrongBinder());
}
return NULL;
}
我们前面在分析Native Service的获取时曾经说过binder驱动首先判断ref->node->proc == target_proc，即注册的进程和现在获取MediaPlayerService的进程是否是同一个，如果是，则改写fp->type为BINDER_TYPE_BINDER，并设置fp->binder为binder->getWeakRefs()，fp->cookie等于binder->local本身。如果不是在同一个进程（这也是大多数case的状况），则首先调用binder_get_ref_for_node为获取MediaPlayerService的进程分配一个新的binder_ref结构，这里的binder
id值可能不是之前注册的binder id值了（因为不在同一个进程，desc是往上增长的），然后设置fp->handle为新的desc值。首先来看Native层的Parcel的readStrongBinder方法：
[cpp] view
plain copy
sp<IBinder> Parcel::readStrongBinder() const
{
sp<IBinder> val;
unflatten_binder(ProcessState::self(), *this, &val);
return val;
}
status_t unflatten_binder(const sp<ProcessState>& proc,
const Parcel& in, sp<IBinder>* out)
{
const flat_binder_object* flat = in.readObject(false);
if (flat) {
switch (flat->type) {
case BINDER_TYPE_BINDER:
*out = static_cast<IBinder*>(flat->cookie);
return finish_unflatten_binder(NULL, *flat, in);
case BINDER_TYPE_HANDLE:
*out = proc->getStrongProxyForHandle(flat->handle);
return finish_unflatten_binder(
static_cast<BpBinder*>(out->get()), *flat, in);
}
}
return BAD_TYPE;
}
这里分两种情况，一是注册WifiService的进程和获取WifiService的进程是同一个时（这个比较经常，因为注册WifiService是在systemserver当中，systemserver会注册很多其它的Service，这些Service会互相调用）。这时type就是BINDER_TYPE_BINDER，然后通过static_cast将cookie处保存的指针直接转换为前面注册的JavaBBinder；二是注册WifiSerivce的进程和获取WifiService的进程不是同一个时，这里调用getStrongProxyForHandle重新返回一个BpBinder(handle
id)。回到上面的android_os_Parcel_readStrongBinder方法，这里再调用javaObjectForIBinder对IBinder对象做一层封装：
[cpp] view
plain copy
jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)
{
if (val == NULL) return NULL;
if (val->checkSubclass(&gBinderOffsets)) {
}
AutoMutex _l(mProxyLock);
jobject object = (jobject)val->findObject(&gBinderProxyOffsets);
if (object != NULL) {
jobject res = jniGetReferent(env, object);
if (res != NULL) {
ALOGV("objectForBinder %p: found existing %p!\n", val.get(), res);
return res;
}
LOGDEATH("Proxy object %p of IBinder %p no longer in working set!!!", object, val.get());
android_atomic_dec(&gNumProxyRefs);
val->detachObject(&gBinderProxyOffsets);
env->DeleteGlobalRef(object);
}
object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor);
if (object != NULL) {
env->SetIntField(object, gBinderProxyOffsets.mObject, (int)val.get());
val->incStrong((void*)javaObjectForIBinder);
jobject refObject = env->NewGlobalRef(
env->GetObjectField(object, gBinderProxyOffsets.mSelf));
val->attachObject(&gBinderProxyOffsets, refObject,
jnienv_to_javavm(env), proxy_cleanup);
sp<DeathRecipientList> drl = new DeathRecipientList;
drl->incStrong((void*)javaObjectForIBinder);
env->SetIntField(object, gBinderProxyOffsets.mOrgue, reinterpret_cast<jint>(drl.get()));
android_atomic_inc(&gNumProxyRefs);
incRefsCreated(env);
}
return object;
}
前一章里面分析过这个函数，这里会构造一个BinderProxy对象，并将当前的IBinder(可能是JavaBBinder，也可能是BpBinder)与BinderProxy绑定起来。然后将BinderProxy对象返回给获取Service的进程。接着调用IWifiManager service = IWifiManager.Stub.asInterface(b)，它的实现如下：
[java] view
plain copy
public static android.net.wifi.IWifiManager asInterface(
android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = (android.os.IInterface) obj
.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof android.net.wifi.IWifiManager))) {
return ((android.net.wifi.IWifiManager) iin);
}
return new android.net.wifi.IWifiManager.Stub.Proxy(obj);
}
这里的obj是BinderProxy对象，它的queryLocalInterface默认返回NULL，所以这里会先构造一个IWifiManager.Stub.Proxy并返回。最后通过IWifiManager.Stub.Proxy构造一个WifiManager对象给应用层使用。
我们来看一下WifiManager中一个简单的API使用：
[java] view
plain copy
public boolean setWifiApEnabled(WifiConfiguration wifiConfig, boolean enabled) {
try {
mService.setWifiApEnabled(wifiConfig, enabled);
return true;
} catch (RemoteException e) {
return false;
}
}
这里的mService就是上面构造的IWifiManager.Stub.Proxy对象，来看它的setWifiApEnabled方法：
[java] view
plain copy
public boolean setWifiApEnabled(
android.net.wifi.WifiConfiguration wifiConfig,
boolean enable) throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
boolean _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
if ((wifiConfig != null)) {
_data.writeInt(1);
wifiConfig.writeToParcel(_data, 0);
} else {
_data.writeInt(0);
}
_data.writeInt(((enable) ? (1) : (0)));
mRemote.transact(Stub.TRANSACTION_setWifiApEnabled, _data,
_reply, 0);
_reply.readException();
_result = (0 != _reply.readInt());
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
首先还是获取两个Parcel对象，一个用于存储发送到WifiService的数据；一个用于获取WifiService的回复。并向data中写入strict mode和"android.net.wifi.IWifiManager"，再写入两个参数。最后调用mRemote.transact方法。我们知道这里的mRemote就是前面构造的BinderProxy对象，所以来看它的transact方法，它的实现在android_util_Binder.cpp
[java] view
plain copy
static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj,
jint code, jobject dataObj, jobject replyObj, jint flags) // throws RemoteException
{
if (dataObj == NULL) {
}
Parcel* data = parcelForJavaObject(env, dataObj);
if (data == NULL) {
return JNI_FALSE;
}
Parcel* reply = parcelForJavaObject(env, replyObj);
if (reply == NULL && replyObj != NULL) {
return JNI_FALSE;
}
IBinder* target = (IBinder*)
env->GetIntField(obj, gBinderProxyOffsets.mObject);
if (target == NULL) {
jniThrowException(env, "java/lang/IllegalStateException", "Binder has been finalized!");
return JNI_FALSE;
}
status_t err = target->transact(code, *data, reply, flags);
if (err == NO_ERROR) {
return JNI_TRUE;
} else if (err == UNKNOWN_TRANSACTION) {
return JNI_FALSE;
}
signalExceptionForError(env, obj, err, true /*canThrowRemoteException*/);
return JNI_FALSE;
}
这里也要分两种情况讨论，一种是在同一个进程中，这里的target就是JavaBBinder；如果在不同进程中，这里的target就是BpBinder。首先来看在同一个进程的情况，调用JavaBBinder的transact方法，因为JavaBBinder是继承于BBinder，所以直接到BBinder的transact方法中：
[cpp] view
plain copy
status_t BBinder::transact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
data.setDataPosition(0);
status_t err = NO_ERROR;
switch (code) {
case PING_TRANSACTION:
reply->writeInt32(pingBinder());
break;
default:
err = onTransact(code, data, reply, flags);
break;
}
if (reply != NULL) {
reply->setDataPosition(0);
}
return err;
}
直接调用onTransact方法，当然这里的onTransact方法是JavaBBinder重写后的。当不同同一个进程中调用时，target就是BpBinder，所以调用BpBinder的transact方法，最后通过ioctrl发送命令给注册binder驱动中的JavaBBinder(WifiService的包装)，同样还是会调用到JavaBBinder的onTransact方法，只是多了一个跨进程的数据传递过程。
[cpp] view
plain copy
virtual status_t onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags = 0)
{
JNIEnv* env = javavm_to_jnienv(mVM);
IPCThreadState* thread_state = IPCThreadState::self();
const int strict_policy_before = thread_state->getStrictModePolicy();
thread_state->setLastTransactionBinderFlags(flags);
jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact,
code, (int32_t)&data, (int32_t)reply, flags);
jthrowable excep = env->ExceptionOccurred();
const int strict_policy_after = thread_state->getStrictModePolicy();
if (strict_policy_after != strict_policy_before) {
thread_state->setStrictModePolicy(strict_policy_before);
set_dalvik_blockguard_policy(env, strict_policy_before);
}
jthrowable excep2 = env->ExceptionOccurred();
if (excep2) {
report_exception(env, excep2,
"*** Uncaught exception in onBinderStrictModePolicyChange");
/* clean up JNI local ref -- we don't return to Java code */
env->DeleteLocalRef(excep2);
}
if (code == SYSPROPS_TRANSACTION) {
BBinder::onTransact(code, data, reply, flags);
}
return res != JNI_FALSE ? NO_ERROR : UNKNOWN_TRANSACTION;
}
这里主要就是调用Binder.java的execTransact来处理请求：
[java] view
plain copy
private boolean execTransact(int code, int dataObj, int replyObj,
int flags) {
Parcel data = Parcel.obtain(dataObj);
Parcel reply = Parcel.obtain(replyObj);
boolean res;
try {
res = onTransact(code, data, reply, flags);
} catch (RemoteException e) {
if ((flags & FLAG_ONEWAY) != 0) {
Log.w(TAG, "Binder call failed.", e);
}
reply.setDataPosition(0);
reply.writeException(e);
res = true;
} catch (RuntimeException e) {
if ((flags & FLAG_ONEWAY) != 0) {
Log.w(TAG, "Caught a RuntimeException from the binder stub implementation.", e);
}
reply.setDataPosition(0);
reply.writeException(e);
res = true;
} catch (OutOfMemoryError e) {
Log.e(TAG, "Caught an OutOfMemoryError from the binder stub implementation.", e);
RuntimeException re = new RuntimeException("Out of memory", e);
reply.setDataPosition(0);
reply.writeException(re);
res = true;
}
reply.recycle();
data.recycle();
return res;
}
}
这里直接调用WIfiService的onTransact方法，它的实现在IWifiManager.Stub中：
[java] view
plain copy
public boolean onTransact(int code, android.os.Parcel data,
android.os.Parcel reply, int flags)
throws android.os.RemoteException {
switch (code) {
case TRANSACTION_setWifiApEnabled: {
data.enforceInterface(DESCRIPTOR);
android.net.wifi.WifiConfiguration _arg0;
if ((0 != data.readInt())) {
_arg0 = android.net.wifi.WifiConfiguration.CREATOR
.createFromParcel(data);
} else {
_arg0 = null;
}
boolean _arg1;
_arg1 = (0 != data.readInt());
boolean _result = this.setWifiApEnabled(_arg0, _arg1);
reply.writeNoException();
reply.writeInt(((_result) ? (1) : (0)));
return true;
}
首先从Parcel中读出WifiConfiguration和enable两个参数，然后调用WifiServcie的setWifiApEnabled方法，并把执行结果写入到reply中。如果不在同一个进程中调用，最后通过IPCThreadState的sendReply方法将结果返回给调用者。到这里，一次Java Servcie的调用就完成了。
1．binder通信概述
binder通信是一种client-server的通信结构，
1.从表面上来看，是client通过获得一个server的代理接口，对server进行直接调用；
2.实际上，代理接口中定义的方法与server中定义的方法是一一对应的；
3.client调用某个代理接口中的方法时，代理接口的方法会将client传递的参数打包成为Parcel对象；
4.代理接口将该Parcel发送给内核中的binder driver.
5.server会读取binder driver中的请求数据，如果是发送给自己的，解包Parcel对象，处理并将结果返回；
6.整个的调用过程是一个同步过程，在server处理的时候，client会block住。
2．service manager
Service Manager是一个linux级的进程,顾名思义，就是service的管理器。这里的service是什么概念呢？这里的service的概念和init过程中init.rc中的service是不同，init.rc中的service是都是linux进程，但是这里的service它并不一定是一个进程，也就是说可能一个或多个service属于同一个linux进程。在这篇文章中不加特殊说明均指android native端的service。任何service在被使用之前，均要向SM(Service Manager)注册，同时客户端需要访问某个service时，应该首先向SM查询是否存在该服务。如果SM存在这个service，那么会将该service的handle返回给client，handle是每个service的唯一标识符。
SM的入口函数在service_manager.c中，下面是SM的代码部分
int main(int argc, char **argv)
{
struct binder_state *bs;
void *svcmgr = BINDER_SERVICE_MANAGER;
bs = binder_open(128*1024);
if (binder_become_context_manager(bs)) {
LOGE("cannot become context manager (%s)/n", strerror(errno));
return -1;
}
svcmgr_handle = svcmgr;
binder_loop(bs, svcmgr_handler);
return 0;
}
这个进程的主要工作如下：
1.初始化binder，打开/dev/binder设备；在内存中为binder映射128K字节空间；
2.指定SM对应的代理binder的handle为0，当client尝试与SM通信时，需要创建一个handle为0的代理binder，这里的代理binder其实就是第一节中描述的那个代理接口；
3.通知binder driver(BD)使SM成为BD的context manager；
4.维护一个死循环，在这个死循环中，不停地去读内核中binder driver，查看是否有可读的内容；即是否有对service的操作要求, 如果有，则调用svcmgr_handler回调来处理请求的操作。
5.SM维护了一个svclist列表来存储service的信息。
这里需要声明一下，当service在向SM注册时，该service就是一个client，而SM则作为了server。而某个进程需要与service通信时，此时这个进程为client，service才作为server。因此service不一定为server，有时它也是作为client存在的。
由于下面几节会介绍一些与binder通信相关的几个概念，所以将SM的功能介绍放在了后面的部分来讲。
应用和service之间的通信会涉及到2次binder通信。
1.应用向SM查询service是否存在，如果存在获得该service的代理binder，此为一次binder通信；
2.应用通过代理binder调用service的方法，此为第二次binder通信。
3．ProcessState
ProcessState是以单例模式设计的。每个进程在使用binder机制通信时，均需要维护一个ProcessState实例来描述当前进程在binder通信时的binder状态。ProcessState有如下2个主要功能：
1.创建一个thread,该线程负责与内核中的binder模块进行通信，称该线程为Pool thread；
2.为指定的handle创建一个BpBinder对象，并管理该进程中所有的BpBinder对象。
3.1 Pool thread
在Binder IPC中，所有进程均会启动一个thread来负责与BD来直接通信，也就是不停的读写BD，这个线程的实现主体是一个IPCThreadState对象，下面会介绍这个类型。下面是 Pool thread的启动方式：
ProcessState::self()->startThreadPool();
3.2 BpBinder获取
BpBinder主要功能是负责client向BD发送调用请求的数据。它是client端binder通信的核心对象，通过调用transact函数向BD发送调用请求的数据，它的构造函数如下：BpBinder(int32_t handle);
通过BpBinder的构造函数发现，BpBinder会将当前通信中server的handle记录下来，当有数据发送时，会通知BD数据的发送目标。
ProcessState通过如下方式来获取BpBinder对象：
ProcessState::self()->getContextObject(handle);
在这个过程中，ProcessState会维护一个BpBinder的vector mHandleToObject，每当ProcessState创建一个BpBinder的实例时，回去查询mHandleToObject，如果对应的handle已经有binder指针，那么不再创建，否则创建binder并插入到mHandleToObject中。
ProcessState创建的BpBinder实例，一般情况下会作为参数构建一个client端的代理接口，这个代理接口的形式为BpINTERFACE,例如在与SM通信时，client会创建一个代理接口BpServiceManager.
4．IPCThreadState
IPCThreadState也是以单例模式设计的。由于每个进程只维护了一个ProcessState实例，同时ProcessState只启动一个Pool thread，也就是说每一个进程只会启动一个Pool thread，因此每个进程则只需要一个IPCThreadState即可。Pool thread的实际内容则为：
IPCThreadState::self()->joinThreadPool();
ProcessState中有2个Parcel成员，mIn和mOut，Pool thread会不停的查询BD中是否有数据可读，如果有将其读出并保存到mIn，同时不停的检查mOut是否有数据需要向BD发送，如果有，则将其内容写入到BD中，总而言之，从BD中读出的数据保存到mIn，待写入到BD中的数据保存在了mOut中。
ProcessState中生成的BpBinder实例通过调用IPCThreadState的transact函数来向mOut中写入数据，这样的话这个binder IPC过程的client端的调用请求的发送过程就明了了。
IPCThreadState有两个重要的函数，talkWithDriver函数负责从BD读写数据，executeCommand函数负责解析并执行mIn中的数据。
5.主要基类
5.1基类IInterface为server端提供接口，它的子类声明了service能够实现的所有的方法；
5.2基类IBinder
BBinder与BpBinder均为IBinder的子类，因此可以看出IBinder定义了binder IPC的通信协议，BBinder与BpBinder在这个协议框架内进行的收和发操作，构建了基本的binder IPC机制。
5.3基类BpRefBase
client端在查询SM获得所需的的BpBinder后，BpRefBase负责管理当前获得的BpBinder实例。
6.两个接口类
6.1 BpINTERFACE
如果client想要使用binder IPC来通信，那么首先会从SM出查询并获得server端service的BpBinder，在client端，这个对象被认为是server端的远程代理。为了能够使client能够想本地调用一样调用一个远程server，server端需要向client提供一个接口，client在在这个接口的基础上创建一个BpINTERFACE，使用这个对象，client的应用能够想本地调用一样直接调用server端的方法。而不用去关心具体的binder IPC实现。下面看一下BpINTERFACE的原型：
class BpINTERFACE : public BpInterface<IINTERFACE>
顺着继承关系再往上看
template<typename INTERFACE>
class BpInterface : public INTERFACE, public BpRefBase
BpINTERFACE分别继承自INTERFACE，和BpRefBase；
● BpINTERFACE既实现了service中各方法的本地操作，将每个方法的参数以Parcel的形式发送给BD。
例如BpServiceManager的
virtual status_t addService(const String16& name, const sp<IBinder>& service)
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
}
● 同时又将BpBinder作为了自己的成员来管理，将BpBinder存储在mRemote中，BpServiceManager通过调用BpRefBase的remote()来获得BpBinder指针。
6.2 BnINTERFACE
在定义android native端的service时，每个service均继承自BnINTERFACE(INTERFACE为service name)。BnINTERFACE类型定义了一个onTransact函数，这个函数负责解包收到的Parcel并执行client端的请求的方法。顺着BnINTERFACE的继承关系再往上看，
class BnINTERFACE: public BnInterface<IINTERFACE>
IINTERFACE为client端的代理接口BpINTERFACE和server端的BnINTERFACE的共同接口类，这个共同接口类的目的就是保证service方法在C-S两端的一致性。
再往上看
class BnInterface : public INTERFACE, public BBinder
同时我们发现了BBinder类型，这个类型又是干什么用的呢？既然每个service均可视为一个binder，那么真正的server端的binder的操作及状态的维护就是通过继承自BBinder来实现的。可见BBinder是service作为binder的本质所在。
那么BBinder与BpBinder的区别又是什么呢？
其实它们的区别很简单，BpBinder是client端创建的用于消息发送的代理，而BBinder是server端用于接收消息的通道。查看各自的代码就会发现，虽然两个类型均有transact的方法，但是两者的作用不同，BpBinder的transact方法是向IPCThreadState实例发送消息，通知其有消息要发送给BD；而BBinder则是当IPCThreadState实例收到BD消息时，通过BBinder的transact的方法将其传递给它的子类BnSERVICE的onTransact函数执行server端的操作。
7. Parcel
Parcel是binder IPC中的最基本的通信单元，它存储C-S间函数调用的参数.但是Parcel只能存储基本的数据类型，如果是复杂的数据类型的话，在存储时，需要将其拆分为基本的数据类型来存储。简单的Parcel读写不再介绍，下面着重介绍一下2个函数
7.1 writeStrongBinder
当client需要将一个binder向server发送时，可以调用此函数。例如virtual status_t addService(const String16& name, const sp<IBinder>& service)
{
Parcel data, reply;
data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
data.writeString16(name);
data.writeStrongBinder(service);
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
return err == NO_ERROR ? reply.readExceptionCode() : err;
}
看一下writeStrongBinder的实体
status_t Parcel::writeStrongBinder(const sp<IBinder>& val)
{
return flatten_binder(ProcessState::self(), val, this);
}
接着往里看flatten_binder
status_t flatten_binder(const sp<ProcessState>& proc,
const sp<IBinder>& binder, Parcel* out)
{
flat_binder_object obj;
obj.flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;
if (binder != NULL) {
IBinder *local = binder->localBinder();
if (!local) {
BpBinder *proxy = binder->remoteBinder();
if (proxy == NULL) {
LOGE("null proxy");
}
const int32_t handle = proxy ? proxy->handle() : 0;
obj.type = BINDER_TYPE_HANDLE;
obj.handle = handle;
obj.cookie = NULL;
} else {
obj.type = BINDER_TYPE_BINDER;
obj.binder = local->getWeakRefs();
obj.cookie = local;
}
} else {
obj.type = BINDER_TYPE_BINDER;
obj.binder = NULL;
obj.cookie = NULL;
}
return finish_flatten_binder(binder, obj, out);
}
还是拿addService为例，它的参数为一个BnINTERFACE类型指针，BnINTERFACE又继承自BBinder，
BBinder* BBinder::localBinder()
{
return this;
}
所以写入到Parcel的binder类型为BINDER_TYPE_BINDER，同时你在阅读SM的代码时会发现如果SM收到的service的binder类型不为BINDER_TYPE_HANDLE时，SM将不会将此service添加到svclist，但是很显然每个service的添加都是成功的，addService在开始传递的binder类型为BINDER_TYPE_BINDER，SM收到的binder类型为BINDER_TYPE_HANDLE，那么这个过程当中究竟发生了什么？
为了搞明白这个问题，花费我很多的事件，最终发现了问题的所在，原来在BD中做了如下操作(drivers/staging/android/Binder.c)：
static void binder_transaction(struct binder_proc *proc,
struct binder_thread *thread,
struct binder_transaction_data *tr, int reply)
{
..........................................
if (fp->type == BINDER_TYPE_BINDER)
fp->type = BINDER_TYPE_HANDLE;
else
fp->type = BINDER_TYPE_WEAK_HANDLE;
fp->handle = ref->desc;
..........................................
}
阅读完addService的代码，你会发现SM只是保存了service binder的handle和service的name，那么当client需要和某个service通信了，如何获得service的binder呢？看下一个函数
7.2 readStrongBinder
当server端收到client的调用请求之后，如果需要返回一个binder时，可以向BD发送这个binder，当IPCThreadState实例收到这个返回的Parcel时，client可以通过这个函数将这个被server返回的binder读出。sp<IBinder> Parcel::readStrongBinder() const
{
sp<IBinder> val;
unflatten_binder(ProcessState::self(), *this, &val);
return val;
}
往里查看unflatten_binder
status_t unflatten_binder(const sp<ProcessState>& proc,
const Parcel& in, sp<IBinder>* out)
{
const flat_binder_object* flat = in.readObject(false);
if (flat) {
switch (flat->type) {
case BINDER_TYPE_BINDER:
*out = static_cast<IBinder*>(flat->cookie);
return finish_unflatten_binder(NULL, *flat, in);
case BINDER_TYPE_HANDLE:
*out = proc->getStrongProxyForHandle(flat->handle);
return finish_unflatten_binder(
static_cast<BpBinder*>(out->get()), *flat, in);
}
}
return BAD_TYPE;
}
发现如果server返回的binder类型为BINDER_TYPE_BINDER的话，也就是返回一个binder引用的话，直接获取这个binder；如果server返回的binder类型为BINDER_TYPE_HANDLE时，也就是server返回的仅仅是binder的handle，那么需要重新创建一个BpBinder返回给client。
有上面的代码可以看出，SM保存的service的binder仅仅是一个handle，而client则是通过向SM获得这个handle，从而重新构建代理binder与server通信。
这里顺带提一下一种特殊的情况，binder通信的双方即可作为client，也可以作为server.也就是说此时的binder通信是一个半双工的通信。那么在这种情况下，操作的过程会比单工的情况复杂，但是基本的原理是一样的，有兴趣可以分析一下MediaPlayer和MediaPlayerService的例子。
8. 经典桥段分析
main_ mediaserver.cppint main(int argc, char** argv)
{
//创建进程mediaserver的ProcessState实例
sp<ProcessState> proc(ProcessState::self());
//获得SM的BpServiceManager
sp<IServiceManager> sm = defaultServiceManager();
LOGI("ServiceManager: %p", sm.get());
//添加mediaserver中支持的service。
AudioFlinger::instantiate();
MediaPlayerService::instantiate();
CameraService::instantiate();
AudioPolicyService::instantiate();
//启动ProcessState的pool thread
ProcessState::self()->startThreadPool();
//这一步有重复之嫌，加不加无关紧要。
IPCThreadState::self()->joinThreadPool();
}
9. Java 层的binder机制
了解了native通信机制后，再去分析JAVA层的binder机制，它只是对native的binder做了一个封装。Binder的java层框架
Binder的Java框架层包含以下类(frameworks/base/core/java/android/os):IBinder，Binder，IInterface，ServiceManagerNative，ServiceManager，BinderInternal，IServiceManager，ServiceManagerProxy。Binder的Java框架层部分方法的实现在本地代码里，源码位于frameworks/base/core/jni。
与Binder本地框架类似，声明的binder service接口必须继承自IInterface，这里ICloudManager继承自IInterface。与Binder 本地框架层不相同的是，Java层的IBinder接口直接继承自IInterface，而本地的IBinder类继承自RefBase。本地的IBinder有两个子类，BBinder和BpBinder，Java层的IBinder接口也有两个子类，Binder和BinderProxy。Java层服务端的CloudManager (binder service实体类)
直接继承自Binder类，并实现了binder service接口ICloudManager，而客户端的CloudManagerProxy类只需实现binder service接口ICloudManager即可。
Binder java层框架相关 Jni源码
Binder Java层框架类有不少方法是native的，意味着这些native方法是jni方法。Java层框架中的类Binder，BinderProxy，BinderInternal的native方法的实现是在源码frameworks/base/core/jni/android_util_Binder.cpp里，Java层框架中Parcel类native方法的实现是在frameworks/base/core/jni/android_os_Parcel.cpp里。接下来我们将详细分析android_util_Binder.cpp。重要数据结构
1) gBinderOffsets，代表android.os.Binder 类
1 2 3 4 5 6 7 8 9 10 11 12 | static struct bindernative_offsets_t
{
// 指向class对象android.os.Binder
jclass mClass;
//指向 android.os.Binder的execTransact方法
jmethodID mExecTransact;
//指向android.os.Binder的mObject字段，
//将用于保存指向JavaBBinderHolder对象的指针
jfieldID mObject;
} gBinderOffsets; |
2) gBinderInternalOffsets，代表com.android.internal.os.BinderInternal类
1 2 3 4 5 6 7 8 | static struct binderinternal_offsets_t
{
//指向 class对象com.android.internal.os.BinderInternal
jclass mClass;
//指向BinderInternal的forceGc方法
jmethodID mForceGc;
} gBinderInternalOffsets; |
3) binderproxy_offsets_t，代表android.os.BinderProxy类
1 2 3 4 5 6 7 8 9 10 11 1213 | static struct binderproxy_offsets_t
{
//指向 class对象android.os.BinderProxy
jclass mClass;
//指向 BinderProxy的构造方法
jmethodID mConstructor;
//指向 BinderProxy的sendDeathNotice方法
jmethodID mSendDeathNotice;
//指向 BinderProxy的mObject字段
jfieldID mObject;
//指向 BinderProxy的mSelf字段
jfieldID mSelf;
//指向 BinderProxy的mOrgue字段
jfieldID mOrgue;
} gBinderProxyOffsets; |
4) JavaBBinder和JavaBBinderHolder
JavaBBinder和JavaBBinderHolder相关类类图如下所示(若看不清，请点击看大图)，JavaBBinder继承自本地框架的BBinder，代表binder service服务端实体，而JavaBBinderHolder保存JavaBBinder指针，Java层Binder的mObject保存的是JavaBBinderHolder指针的值，故此这里用聚合关系表示。BinderProxy的mObject保存的是BpBinder对象指针的值，故此这里用聚合关系表示。
重要函数
1) javaObjectForIBinder 将本地IBinder对象转为Java层的IBinder对象，实际类型是BinderProxy
1 2 3 4 5 6 7 8 9 10 11 1213 | jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)
{
if (val == NULL) return NULL;
//如果是 binder 服务端进程调用javaObjectForIBinder
//将调用JavaBBinder的object方法返回jobject，
//这里jobject的实际Java类型是Binder
if (val->checkSubclass(&gBinderOffsets)) {
// One of our own!
jobject object = static_cast<JavaBBinder*>(val.get())->object();
LOGDEATH("objectForBinder %p: it's our own %p!\n", val.get(),
object);
return object;
}
//如果是binder客户端进程，则需要返回Java层的BinderProxy对象
// For the rest of the function we will hold this lock, to serialize
// looking/creation of Java proxies for native Binder proxies.
AutoMutex _l(mProxyLock);
// 如果已有用Java层WeakReference保存的BinderProxy对象，则返回该对象
jobject object = (jobject)val->findObject(&gBinderProxyOffsets);
if (object != NULL) {
jobject res = env->CallObjectMethod(object,
gWeakReferenceOffsets.mGet);
if (res != NULL) {
ALOGV("objectForBinder %p: found existing %p!\n", val.get(),
res);
return res;
}
LOGDEATH("Proxy object %p of IBinder %p no longer
in working set!!!", object, val.get());
android_atomic_dec(&gNumProxyRefs);
val->detachObject(&gBinderProxyOffsets);
env->DeleteGlobalRef(object);
}
//创建BinderProxy对象
object = env->NewObject(gBinderProxyOffsets.mClass,
gBinderProxyOffsets.mConstructor);
if (object != NULL) {
LOGDEATH("objectForBinder %p: created new proxy %p !\n",
val.get(), object);
// The proxy holds a reference to the native object.
//设置BinderProxy对象的mObject字段为本地IBinder对象指针，
//本地IBinder对象的实际类型是BpBinder
env->SetIntField(object, gBinderProxyOffsets.mObject,
(int)val.get());
val->incStrong(object);
// The native object needs to hold a weak reference back to the
// proxy, so we can retrieve
//the same proxy if it is still active.
jobject refObject = env->NewGlobalRef(
env->GetObjectField(object, gBinderProxyOffsets.mSelf));
//关联gBinderProxyOffsets，故此第20行代码用findObject才能找到
val->attachObject(&gBinderProxyOffsets, refObject,
jnienv_to_javavm(env), proxy_cleanup);
// Also remember the death recipients registered on this proxy
sp<DeathRecipientList> drl = new DeathRecipientList;
drl->incStrong((void*)javaObjectForIBinder);
env->SetIntField(object, gBinderProxyOffsets.mOrgue,
reinterpret_cast<jint>(drl.get()));
// Note that a new object reference has been created.
android_atomic_inc(&gNumProxyRefs);
incRefsCreated(env);
}
return object;
} |
2) ibinderForJavaObject 将Java层的IBinder对象转为本地IBinder对象
1 2 3 4 5 6 7 8 9 10 11 1213 | sp<IBinder> ibinderForJavaObject(JNIEnv* env, jobject obj)
{
if (obj == NULL) return NULL;
//如果是Java层Binder对象
//则将Binder对象的mObject字段转为JavaBBinderHolder指针
//然后调用它的get方法即可转为本地IBinder对象，实际类型是JavaBBinder
if (env->IsInstanceOf(obj, gBinderOffsets.mClass)) {
JavaBBinderHolder* jbh = (JavaBBinderHolder*)
env->GetIntField(obj, gBinderOffsets.mObject);
return jbh != NULL ? jbh->get(env, obj) : NULL;
}
//如果是Java层的BinderProxy对象，
//则将BinderProxy对象的mObject字段直接转为本地的IBinder对象指针
//实际类型是本地框架里的BpBinder
if (env->IsInstanceOf(obj, gBinderProxyOffsets.mClass)) {
return (IBinder*)
env->GetIntField(obj, gBinderProxyOffsets.mObject);
}
ALOGW("ibinderForJavaObject: %p is not a Binder object", obj);
return NULL;
} |
初始化流程
Java虚拟机启动时会调用jni方法来注册Java层binder框架的本地方法，流程如下图所示(若看不清请点击看大图)：
binder 的使用例子：
参考地址：http://blog.csdn.net/lilian0118/article/details/24397953
在Java Service当中，会经常使用到AIDL工具，AIDL在google官方文档的解释是："AIDL (Android Interface Definition Language) is similar to other IDLs you might have worked
with. It allows you to define the programming interface that both the client and service agree upon in order to communicate with each other using interprocess communication (IPC)"。即AIDL是一种接口描述语言，用于定义client和service共同认可的接口。听起来比较绕口，直接来看IWifiManger.aidl的大致内容：
[cpp] view
plain copy
interface IWifiManager
{
List<WifiConfiguration> getConfiguredNetworks();
int addOrUpdateNetwork(in WifiConfiguration config);
boolean removeNetwork(int netId);
boolean enableNetwork(int netId, boolean disableOthers);
boolean disableNetwork(int netId);
boolean pingSupplicant();
void startScan(in WorkSource ws);
List<ScanResult> getScanResults(String callingPackage);
void disconnect();
void reconnect();
void reassociate();
这里定义了一系列的函数接口，在AIDL中除了支持Java原始类型数据（int、long、char、boolean等），还支持String、CharSequence、list和map。进过AIDL工具的转换，就可以将上面的aidl文件生成一个Java文件，其内容大致如下：
[java] view
plain copy
public interface IWifiManager extends android.os.IInterface {
public static abstract class Stub extends android.os.Binder implements
android.net.wifi.IWifiManager {
private static final java.lang.String DESCRIPTOR = "android.net.wifi.IWifiManager";
public Stub() {
this.attachInterface(this, DESCRIPTOR);
}
public static android.net.wifi.IWifiManager asInterface(
android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = (android.os.IInterface) obj
.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof android.net.wifi.IWifiManager))) {
return ((android.net.wifi.IWifiManager) iin);
}
return new android.net.wifi.IWifiManager.Stub.Proxy(obj);
}
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) {
}
}
return super.onTransact(code, data, reply, flags);
}
private static class Proxy implements android.net.wifi.IWifiManager {
private android.os.IBinder mRemote;
Proxy(android.os.IBinder remote) {
mRemote = remote;
}
public android.os.IBinder asBinder() {
return mRemote;
}
public java.lang.String getInterfaceDescriptor() {
return DESCRIPTOR;
}
}
IWifiManager.java中主要包含三个类：IWifiManager类、IWifiManager.Stub类、IWifiManager.Stub.Proxy类，WifiSerive就是继承于IWifiManager.Stub类。前面我们已经看过它的关系了，下面来看一般获取WifiService的方法：
[java] view
plain copy
IBinder b = ServiceManager.getService(WIFI_SERVICE);
IWifiManager service = IWifiManager.Stub.asInterface(b);
return new WifiManager(ctx.getOuterContext(), service);
这里调用ServiceManager的getService方法，WIFI_SERVICE就是"wifi"字串：
[cpp] view
plain copy
public static IBinder getService(String name) {
try {
IBinder service = sCache.get(name);
if (service != null) {
return service;
} else {
return getIServiceManager().getService(name);
}
} catch (RemoteException e) {
Log.e(TAG, "error in getService", e);
}
return null;
}
sCache用于缓存所有使用过的Java Service，它有ActivityManagerService在fork进程的时候拷贝进来，我们以后分析到AMS的时候再来看sCache，这里先假设sCache并没有我们想要的"wifi" service。然后调用getIServiceManager()的getService方法。前面分析过getIServiceManager()其实最后就是返回ServiceManagerProxy(BinderProxy)，所以这里调用ServiceManagerProxy的getService方法：
[java] view
plain copy
public IBinder getService(String name) throws RemoteException {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
data.writeInterfaceToken(IServiceManager.descriptor);
data.writeString(name);
mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
IBinder binder = reply.readStrongBinder();
reply.recycle();
data.recycle();
return binder;
}
首先获取两个Parcel对象，然后向data中写入Strict mode和"android.os.IServiceManager"，然后再写入想要获取的service名字，即“wifi”。再调用mRemote.transact方法，这里的实现在android_util_Binder.cpp中，我们前面一章分析过，这里直接调用BpBinder(0)的transact方法，将GET_SERVICE_TRANSACTION命令发往binder驱动。我们来看Java层如何从Parcel中读取想要的Servcie：
[cpp] view
plain copy
public final IBinder readStrongBinder() {
return nativeReadStrongBinder(mNativePtr);
}
static jobject android_os_Parcel_readStrongBinder(JNIEnv* env, jclass clazz, jint nativePtr)
{
Parcel* parcel = reinterpret_cast<Parcel*>(nativePtr);
if (parcel != NULL) {
return javaObjectForIBinder(env, parcel->readStrongBinder());
}
return NULL;
}
我们前面在分析Native Service的获取时曾经说过binder驱动首先判断ref->node->proc == target_proc，即注册的进程和现在获取MediaPlayerService的进程是否是同一个，如果是，则改写fp->type为BINDER_TYPE_BINDER，并设置fp->binder为binder->getWeakRefs()，fp->cookie等于binder->local本身。如果不是在同一个进程（这也是大多数case的状况），则首先调用binder_get_ref_for_node为获取MediaPlayerService的进程分配一个新的binder_ref结构，这里的binder
id值可能不是之前注册的binder id值了（因为不在同一个进程，desc是往上增长的），然后设置fp->handle为新的desc值。首先来看Native层的Parcel的readStrongBinder方法：
[cpp] view
plain copy
sp<IBinder> Parcel::readStrongBinder() const
{
sp<IBinder> val;
unflatten_binder(ProcessState::self(), *this, &val);
return val;
}
status_t unflatten_binder(const sp<ProcessState>& proc,
const Parcel& in, sp<IBinder>* out)
{
const flat_binder_object* flat = in.readObject(false);
if (flat) {
switch (flat->type) {
case BINDER_TYPE_BINDER:
*out = static_cast<IBinder*>(flat->cookie);
return finish_unflatten_binder(NULL, *flat, in);
case BINDER_TYPE_HANDLE:
*out = proc->getStrongProxyForHandle(flat->handle);
return finish_unflatten_binder(
static_cast<BpBinder*>(out->get()), *flat, in);
}
}
return BAD_TYPE;
}
这里分两种情况，一是注册WifiService的进程和获取WifiService的进程是同一个时（这个比较经常，因为注册WifiService是在systemserver当中，systemserver会注册很多其它的Service，这些Service会互相调用）。这时type就是BINDER_TYPE_BINDER，然后通过static_cast将cookie处保存的指针直接转换为前面注册的JavaBBinder；二是注册WifiSerivce的进程和获取WifiService的进程不是同一个时，这里调用getStrongProxyForHandle重新返回一个BpBinder(handle
id)。回到上面的android_os_Parcel_readStrongBinder方法，这里再调用javaObjectForIBinder对IBinder对象做一层封装：
[cpp] view
plain copy
jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)
{
if (val == NULL) return NULL;
if (val->checkSubclass(&gBinderOffsets)) {
}
AutoMutex _l(mProxyLock);
jobject object = (jobject)val->findObject(&gBinderProxyOffsets);
if (object != NULL) {
jobject res = jniGetReferent(env, object);
if (res != NULL) {
ALOGV("objectForBinder %p: found existing %p!\n", val.get(), res);
return res;
}
LOGDEATH("Proxy object %p of IBinder %p no longer in working set!!!", object, val.get());
android_atomic_dec(&gNumProxyRefs);
val->detachObject(&gBinderProxyOffsets);
env->DeleteGlobalRef(object);
}
object = env->NewObject(gBinderProxyOffsets.mClass, gBinderProxyOffsets.mConstructor);
if (object != NULL) {
env->SetIntField(object, gBinderProxyOffsets.mObject, (int)val.get());
val->incStrong((void*)javaObjectForIBinder);
jobject refObject = env->NewGlobalRef(
env->GetObjectField(object, gBinderProxyOffsets.mSelf));
val->attachObject(&gBinderProxyOffsets, refObject,
jnienv_to_javavm(env), proxy_cleanup);
sp<DeathRecipientList> drl = new DeathRecipientList;
drl->incStrong((void*)javaObjectForIBinder);
env->SetIntField(object, gBinderProxyOffsets.mOrgue, reinterpret_cast<jint>(drl.get()));
android_atomic_inc(&gNumProxyRefs);
incRefsCreated(env);
}
return object;
}
前一章里面分析过这个函数，这里会构造一个BinderProxy对象，并将当前的IBinder(可能是JavaBBinder，也可能是BpBinder)与BinderProxy绑定起来。然后将BinderProxy对象返回给获取Service的进程。接着调用IWifiManager service = IWifiManager.Stub.asInterface(b)，它的实现如下：
[java] view
plain copy
public static android.net.wifi.IWifiManager asInterface(
android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = (android.os.IInterface) obj
.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof android.net.wifi.IWifiManager))) {
return ((android.net.wifi.IWifiManager) iin);
}
return new android.net.wifi.IWifiManager.Stub.Proxy(obj);
}
这里的obj是BinderProxy对象，它的queryLocalInterface默认返回NULL，所以这里会先构造一个IWifiManager.Stub.Proxy并返回。最后通过IWifiManager.Stub.Proxy构造一个WifiManager对象给应用层使用。
Java Service的调用
我们来看一下WifiManager中一个简单的API使用：[java] view
plain copy
public boolean setWifiApEnabled(WifiConfiguration wifiConfig, boolean enabled) {
try {
mService.setWifiApEnabled(wifiConfig, enabled);
return true;
} catch (RemoteException e) {
return false;
}
}
这里的mService就是上面构造的IWifiManager.Stub.Proxy对象，来看它的setWifiApEnabled方法：
[java] view
plain copy
public boolean setWifiApEnabled(
android.net.wifi.WifiConfiguration wifiConfig,
boolean enable) throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
boolean _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
if ((wifiConfig != null)) {
_data.writeInt(1);
wifiConfig.writeToParcel(_data, 0);
} else {
_data.writeInt(0);
}
_data.writeInt(((enable) ? (1) : (0)));
mRemote.transact(Stub.TRANSACTION_setWifiApEnabled, _data,
_reply, 0);
_reply.readException();
_result = (0 != _reply.readInt());
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
首先还是获取两个Parcel对象，一个用于存储发送到WifiService的数据；一个用于获取WifiService的回复。并向data中写入strict mode和"android.net.wifi.IWifiManager"，再写入两个参数。最后调用mRemote.transact方法。我们知道这里的mRemote就是前面构造的BinderProxy对象，所以来看它的transact方法，它的实现在android_util_Binder.cpp
[java] view
plain copy
static jboolean android_os_BinderProxy_transact(JNIEnv* env, jobject obj,
jint code, jobject dataObj, jobject replyObj, jint flags) // throws RemoteException
{
if (dataObj == NULL) {
}
Parcel* data = parcelForJavaObject(env, dataObj);
if (data == NULL) {
return JNI_FALSE;
}
Parcel* reply = parcelForJavaObject(env, replyObj);
if (reply == NULL && replyObj != NULL) {
return JNI_FALSE;
}
IBinder* target = (IBinder*)
env->GetIntField(obj, gBinderProxyOffsets.mObject);
if (target == NULL) {
jniThrowException(env, "java/lang/IllegalStateException", "Binder has been finalized!");
return JNI_FALSE;
}
status_t err = target->transact(code, *data, reply, flags);
if (err == NO_ERROR) {
return JNI_TRUE;
} else if (err == UNKNOWN_TRANSACTION) {
return JNI_FALSE;
}
signalExceptionForError(env, obj, err, true /*canThrowRemoteException*/);
return JNI_FALSE;
}
这里也要分两种情况讨论，一种是在同一个进程中，这里的target就是JavaBBinder；如果在不同进程中，这里的target就是BpBinder。首先来看在同一个进程的情况，调用JavaBBinder的transact方法，因为JavaBBinder是继承于BBinder，所以直接到BBinder的transact方法中：
[cpp] view
plain copy
status_t BBinder::transact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
data.setDataPosition(0);
status_t err = NO_ERROR;
switch (code) {
case PING_TRANSACTION:
reply->writeInt32(pingBinder());
break;
default:
err = onTransact(code, data, reply, flags);
break;
}
if (reply != NULL) {
reply->setDataPosition(0);
}
return err;
}
直接调用onTransact方法，当然这里的onTransact方法是JavaBBinder重写后的。当不同同一个进程中调用时，target就是BpBinder，所以调用BpBinder的transact方法，最后通过ioctrl发送命令给注册binder驱动中的JavaBBinder(WifiService的包装)，同样还是会调用到JavaBBinder的onTransact方法，只是多了一个跨进程的数据传递过程。
[cpp] view
plain copy
virtual status_t onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags = 0)
{
JNIEnv* env = javavm_to_jnienv(mVM);
IPCThreadState* thread_state = IPCThreadState::self();
const int strict_policy_before = thread_state->getStrictModePolicy();
thread_state->setLastTransactionBinderFlags(flags);
jboolean res = env->CallBooleanMethod(mObject, gBinderOffsets.mExecTransact,
code, (int32_t)&data, (int32_t)reply, flags);
jthrowable excep = env->ExceptionOccurred();
const int strict_policy_after = thread_state->getStrictModePolicy();
if (strict_policy_after != strict_policy_before) {
thread_state->setStrictModePolicy(strict_policy_before);
set_dalvik_blockguard_policy(env, strict_policy_before);
}
jthrowable excep2 = env->ExceptionOccurred();
if (excep2) {
report_exception(env, excep2,
"*** Uncaught exception in onBinderStrictModePolicyChange");
/* clean up JNI local ref -- we don't return to Java code */
env->DeleteLocalRef(excep2);
}
if (code == SYSPROPS_TRANSACTION) {
BBinder::onTransact(code, data, reply, flags);
}
return res != JNI_FALSE ? NO_ERROR : UNKNOWN_TRANSACTION;
}
这里主要就是调用Binder.java的execTransact来处理请求：
[java] view
plain copy
private boolean execTransact(int code, int dataObj, int replyObj,
int flags) {
Parcel data = Parcel.obtain(dataObj);
Parcel reply = Parcel.obtain(replyObj);
boolean res;
try {
res = onTransact(code, data, reply, flags);
} catch (RemoteException e) {
if ((flags & FLAG_ONEWAY) != 0) {
Log.w(TAG, "Binder call failed.", e);
}
reply.setDataPosition(0);
reply.writeException(e);
res = true;
} catch (RuntimeException e) {
if ((flags & FLAG_ONEWAY) != 0) {
Log.w(TAG, "Caught a RuntimeException from the binder stub implementation.", e);
}
reply.setDataPosition(0);
reply.writeException(e);
res = true;
} catch (OutOfMemoryError e) {
Log.e(TAG, "Caught an OutOfMemoryError from the binder stub implementation.", e);
RuntimeException re = new RuntimeException("Out of memory", e);
reply.setDataPosition(0);
reply.writeException(re);
res = true;
}
reply.recycle();
data.recycle();
return res;
}
}
这里直接调用WIfiService的onTransact方法，它的实现在IWifiManager.Stub中：
[java] view
plain copy
public boolean onTransact(int code, android.os.Parcel data,
android.os.Parcel reply, int flags)
throws android.os.RemoteException {
switch (code) {
case TRANSACTION_setWifiApEnabled: {
data.enforceInterface(DESCRIPTOR);
android.net.wifi.WifiConfiguration _arg0;
if ((0 != data.readInt())) {
_arg0 = android.net.wifi.WifiConfiguration.CREATOR
.createFromParcel(data);
} else {
_arg0 = null;
}
boolean _arg1;
_arg1 = (0 != data.readInt());
boolean _result = this.setWifiApEnabled(_arg0, _arg1);
reply.writeNoException();
reply.writeInt(((_result) ? (1) : (0)));
return true;
}
首先从Parcel中读出WifiConfiguration和enable两个参数，然后调用WifiServcie的setWifiApEnabled方法，并把执行结果写入到reply中。如果不在同一个进程中调用，最后通过IPCThreadState的sendReply方法将结果返回给调用者。到这里，一次Java Servcie的调用就完成了。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- android 导入第三方库出现java.lang.NoClassDefFoundError
- 80、Android Support v4、v7、v13的区别以及应用场景
- Android 图片占用进程的内存算法
- android+html5上传图片 只显示图片头部部分
- 获取Android设备唯一标识码
- android自动化测试之MonkeyRunner使用实例（三）
- Android开发过程中的一些文件存储路径
- android基础部分再学习--AIDL
- Android缓存技术
- Android 常见的内存使用不当的情况
- Android实现自适应正方形GridView
- Android事件分发机制
- Android xml资源文件animal动画解析
- Android——仿QQ聊天撒花特效
- Android Studio第一次启动的Fetching android sdk component information加载问题
- android中的color使用总结
- Android 避免内存溢出的方案总结
- Android中资源文件的Shape使用总结
- android系统方法裁剪图片 华为手机显示为圆
- Android 内存监测工具 DDMS --> Heap