注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

民主与科学

独立之人格,自由之思想

 
 
 

日志

 
 

Android系统Binder机制之三(服务代理对象 下篇)  

2012-03-01 17:28:50|  分类: 深入研究 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
转载整理自: http://my.unix-center.net/~Simon_fu/?p=942 

上文《Android系统的Binder机制之二——服务代理对象(1)》我们学习了进程的C/C++层面的服务代理对象BpBinder,和Binder底层处理方式。本文我们将深入分析一下在进程的Java层面服务代理对象的创建和使用。

一、Android进程的C/C++层面和Java层

    Android中程序大部分都是java开发,底层通过JNI调用C/C++的代码。这样一个程序就分为了两个层面C/C++层面和Java层面。运行状态下,我们说它们都在一个进程之中,拥有相同的进程属性(UID,GID等等)。

    Binder客户程序的C/C++层面的对象和原理我们在上文Android系统的Binder机制之二——服务代理对象(1)》已经学习。下面我们将介绍客户程序怎样在Java层面通过JNI调用底层C/C++代码的创建服务代理。

ServiceManager类型和对象

    我在《Android系统的Binder机制之一——Service Manager》中介绍过,客户端要想获得服务代理,首先要向ServiceManager查询Service。在Java层面也是这样,所以我们首先分析Java层面ServiceManager类。

    我们通过查看android.os.ServiceManager的源码我们发现,ServiceManager类型也是一个Singleton类型。所有的方法都是静态方法,所有静态方法都是访问它的IServiceManager类型的静态变量sServiceManager,定义如下:

   1: private static IServiceManager sServiceManager;

所以可以理解ServiceManager就是IServiceManager对象的一个代理。为创建和访问这个变量都是通过ServiceManager的getIServiceManager方法,定义如下:

    private static IServiceManager getIServiceManager() {
        if (sServiceManager != null) {
            return sServiceManager;
        }
        // Find the service manager
        sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
        return sServiceManager;
    }

   通过上面的代码,非常清晰的告诉我们ServiceManager类型是一个Singleton类型。现在我们主要研究sServiceManager对象怎样创建的。如下代码创建IServiceManager对象:

   1: sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());

我们首先查看BinderInternal类的getContextObject方法的代码,发现是Native代码(哈哈!有终于到达C/C++层面了,我们已经熟悉了),对应的代码为android_util_binder.cpp中的android_os_BinderInternal_getContextObject函数,代码如下:

static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
{
    sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
    return javaObjectForIBinder(env, b);
}

    终于看到我们上文《Android系统的Binder机制之二——服务代理对象(1)》介绍过的ProcessState对象了,我们再去查看ProcessState对象的getContextObject方法,代码如下:

C语言的sprintf函数跟printf在用法上几乎一样,只是两者打印的目的地不同而已,前者打印到字符串中,后者则直接在命令行上输出
sprintf是个变参函数,定义如下:
sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& caller)
{
    return getStrongProxyForHandle(0);
}

    我们看到在当前进程的ProcessState对象其实是调用getStrongProxyForHandle方法来创建binder句柄为0的服务代理对象——BpBinder对象,我们在《Android系统的Binder机制之一——Service Manager》提到过ServiceManager的binder句柄是一个闻名句柄0。上文《Android系统的Binder机制之二——服务代理对象(1)》已经介绍过ProcessState对象的getStrongProxyForHandle方法,这里就不多说了。

    我们可以看出Java调用C/C++,创建一个服务代理对象BpBinder,在查看BpBinder的定义我们发现继承自IBinder接口,然后在android_util_binder.cpp中的方法android_os_BinderInternal_getContextObject中,把C/C++层面的IBinder对象封装成Java层面的IBinder对象。具体实现可以查看上文的android_os_BinderInternal_getContextObject方法。

    至此我们已经清楚BinderInternal.getContextObject(),返回的是ServiceManager的服务代理对象——BpBinder对象。那么ServiceManagerNative类的静态方法asInterface做什么用呢?我们还是通过代码来分析,在ServiceManagerNative.java中,asInterface的代码如下:

    static public IServiceManager asInterface(IBinder obj)
    {
        if (obj == null) {
            return null;
        }
        IServiceManager in =
            (IServiceManager)obj.queryLocalInterface(descriptor);
        if (in != null) {
            return in;
        }
        
        return new ServiceManagerProxy(obj);
    }
 将会用IBinder对象创建一个ServiceManagerProxy对象,ServiceManagerProxy类型实现了IServiceManager接口,所以asInterface方法最终目的是用一个IBinder对象创建一个IServiceManager对象。
    为什么要用IBinder对象创建一个IServiceManager对象呢?通过ServiceManager的代理对象——IBinder对象(BpBinder对象)应该可以直接请求ServiceManager中的服务了啊?我们在前文《Android系统的Binder机制之二(服务代理对象 上篇)》简单介绍了一下IBinder类型,客户端通过transact方法向Service发送请求,且请求通过请求代码来区分。具体请参考Android手册,也可以参照后面将介绍的ServiceManagerProxy的getService()方法。如果客户端直接用调用ServiceManager的代理对象的IBinder接口,那么客户端必须要记住所有请求的请求代码,对客户端来说不太友好。所以在ServiceManagerNative类中就把ServiceManager的代理对象——IBinder对象(BpBinder对象)封装成ServiceManagerProxy对象,暴露给客户程序一个IServiceManager接口,这样IServiceManager对象(其实是ServiceManagerProxy对象)将会代理客户程通过IBinder把请求发往服务器。客服程序只是简单的调用IServiceManager接口的方法来给ServiceManager发送请求,这样对客户程序来讲和本地的函数调用是一致的,接口非常友好。比如我们客户程序需要调用IServiceManager的getService方法来查询一个Service,ServiceManagerProxy实现代码如下:
class ServiceManagerProxy implements IServiceManager {
    public ServiceManagerProxy(IBinder remote) {
        mRemote = remote;
    }
    public IBinder asBinder() {
        return mRemote;
    }
    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;
    }
...........................................
}

    我们可以非常清晰的看到ServiceManagerProxy对象将客户程序的请求转换成对ServiceManager代理对象——IBinder对象(BpBinder对象)的调用。后文我们将会详细介绍怎样通过IServiceManager查询和获得一个系统Service代理对象。

    到这里我们已经分析完了,ServiceManager的Singleton对象——sServiceManager的创建。如果有不清楚的地方请查看代码。

二、查询和获得Service代理对象
    客户程序通过调用ServiceManagerNative的静态方法asInterface获得了IServiceManager对象,但是最终目的一般都是要查询和获得其他的Service,一般都是要调用IServiceManager的getService方法,向ServiceManager获得其他的Service。比如:
 IBinder b = ServiceManager.getService(Context.NETWORKMANAGEMENT_SERVICE);
    上面的代码中就是调用ServiceManager的静态方法获得网络管理服务代理对象。我们顺藤摸瓜,看看系统是怎样生成这个Service代理对象的。这里只是简单说明一下调用顺序,详细过程请查看源码。
1、调用ServiceManager.java中的ServiceManager静态方法getService。
2、调用ServiceManagerNative.java中的ServiceManagerProxy方法getService。代码如下:
    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;
    }
    请注意IBinder的transact方法是同步方法(本例中ServiceManager处理完成请求之后才会返回),我们可以看出调用transact之后,调用reply.readStrongBinder()来读取IBinder对象。
3、查看Parcel.java中的readStrongBinder方法,发现是Native方法,将会调用到C/C++的代码。
4、查看android_util_binder.cpp中的android_os_Parcel_readStrongBinder函数。代码如下:
static jobject android_os_Parcel_readStrongBinder(JNIEnv* env, jobject clazz)
{
    Parcel* parcel = parcelForJavaObject(env, clazz);
    if (parcel != NULL) {
        return javaObjectForIBinder(env, parcel->readStrongBinder());
    }
    return NULL;
}
parcel->readStrongBinder()将会产生一个IBinder对象。
5、查看Parcel.cpp中,Parcel的方法readStrongBinder。代码如下:
sp<IBinder> Parcel::readStrongBinder() const
{
    sp<IBinder> val;
    unflatten_binder(ProcessState::self(), *this, &val);
    return val;
}
6、查看Parcel.cpp中,Parcel的方法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;
}
终于看到调用我们的老朋友ProcessState对象的getStrongProxyForHandle方法了,这样将会创建一个BpBinder对象,然后该BpBinder对象将会被转换成IBinder对象返回给Java层。
7、Java层为了用使用Service方便,可以把Service代理对象——BpBinder对象(IBinder对象)封装成一个对客户程序友好的代理对象,就如前面ServiceManagerProxy所示那样。
8、用户程序就可以通过该代理对象访问相应Service了。
    通过所述,我们了解了Service代理对象在Java层的创建和使用。Android系统的Binder机制博大精深,我在本文中很多方面都是蜻蜓点水,如果想深入学习请参阅Android的源码。

参考资料:

IPC框架分析 Binder,Service,Service manager

  评论这张
 
阅读(1214)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017