【转】 Service Manager

android2.3 ---  Service Manager分析

Android系统Binder机制的总管是Service Manager，所有的Server（System Server）都需要向他注册，应用程序需要向其查询相应的服务。可见其作用是多么的重要,那么我们这里就要重点介绍一下这个。

这里以java层加入ServiceManager及getService为数据流分析一下。

复习一下典型的Binder模式,有利于后面的理解：
1、客户端通过某种方式得到服务器端的代理对象。从客户端角度看来代理对象和他的本地对象没有什么差别。它可以像其他本地对象一样调用其方法，访问其变量。
2、客户端通过调用服务器代理对象的方法向服务器端发送请求。
3、代理对象把用户请求通过Android内核（Linux内核）的Binder驱动发送到服务器进程。 
4、服务器进程处理用户请求，并通过Android内核（Linux内核）的Binder驱动返回处理结果给客户端的服务器代理对象。 
5、客户端收到服务器端的返回结果。


JAVA层代码分析：
ServiceManager.java (frameworks\base\core\java\android\os)

对于xxxManager获取服务端service基本如此用法：
利用ContextImpl.java中的 
public Object getSystemService(String name) 
然后再调用：
ServiceManager.getService(ServiceName);
获取相应的服务端

ex:
@Override
public Object getSystemService(String name) {
if (WIFI_SERVICE.equals(name)) {
  return getWifiManager();
}
-->
private WifiManager getWifiManager()
{
    synchronized (sSync) {
        if (sWifiManager == null) {
            IBinder b = ServiceManager.getService(WIFI_SERVICE);
            IWifiManager service = IWifiManager.Stub.asInterface(b);
            sWifiManager = new WifiManager(service, mMainThread.getHandler());
        }
    }
    return sWifiManager;
}

ok,知道了客户端获取一个Service的方法之后，我们回到ServiceManager的服务端：
private static IServiceManager getIServiceManager() {
    if (sServiceManager != null) {
        return sServiceManager;
    }


    // Find the service manager
    sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
    return sServiceManager;
}


BinderInternal.getContextObject() @ BinderInternal.java  是一个native 函数：


android_os_BinderInternal_getContextObject @ android_util_Binder.cpp
返回一个 BinderProxy对象保存到类成员mRemote(ServiceManagerProxy类成员)


public abstract class ServiceManagerNative extends Binder implements IServiceManager
ServiceManagerNative 继承自 Binder 并实现了 IServiceManager 接口，利用 asInterface()则提供一个 ServiceManagerProxy 代理对象使用


class ServiceManagerProxy implements IServiceManager
定义了类ServiceManagerProxy（代理），ServiceManagerProxy继承自IServiceManager，并实现了其声明的操作函数，只会被ServiceManagerNative创建，它实现了IServiceManager的接口，IServiceManager提供了getService和addService两个成员函数来管理系统中的Service。

ok,我们沿着代码继续往前走:

class ServiceManagerProxy implements IServiceManager {
    public ServiceManagerProxy(IBinder remote) {
        mRemote = remote;
    }
    
    public IBinder asBinder() {
        return mRemote;  // 这是一个BinderProxy对象
    }


    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对象将数据进行序列化，然后利用transact将数据传给binder驱动,根据 mRemote 是一个 BpBinder 对象继续追踪：

JNI层代码分析：android_util_Binder.cpp 
java 层通过 Binder 对象调用jni函数：
Binder.java: Binder实现的IBinder的接口，他的大部分函数都是通过JNI调用底层实现的BinderProxy是JAVA层的关键类，在JNI通过 gBinderProxyOffsets 来使用

这里只关心它的 onTransact 函数即可

BpBinder 在 BpBinder.h 实现：
class BpBinder : public IBinder
{
    virtual status_t    transact(   uint32_t code,
                                    const Parcel& data,
                                    Parcel* reply,
                                    uint32_t flags = 0);
}


status_t BpBinder::transact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    // Once a binder has died, it will never come back to life.
    if (mAlive) {
        status_t status = IPCThreadState::self()->transact(
            mHandle, code, data, reply, flags);
        if (status == DEAD_OBJECT) mAlive = 0;
        return status;
    }

    return DEAD_OBJECT;
}

3、C++ native层实现 service操作实现，其实java层的直接利用jni写入到binder驱动层了：

IServiceManager.cpp (frameworks\base\libs\binder)
class BpServiceManager : public BpInterface<IServiceManager>
{
public:
    // 获取Service服务端
    virtual sp<IBinder> getService(const String16& name) const
    {
        unsigned n;
        for (n = 0; n < 5; n++){
            sp<IBinder> svc = checkService(name);
            if (svc != NULL) return svc;
            LOGI("Waiting for service %s...\n", String8(name).string());
            sleep(1);
        }
        return NULL;
    }


    // 添加Service到ServiceManager管理器
    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;
    }
}

到了这里：
IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager");

// ----------------------------------------------------------------------

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

一般都以为服务端继承BnServiceManager类实现即可：
ServiceManager.h (frameworks\base\cmds\runtime)
class BServiceManager : public BnServiceManager
其实这里不是的，这是在模拟器上的实现方法，请看其下面的Android.mk文件:
ifeq ($(TARGET_SIMULATOR),true)
... 
include $(BUILD_EXECUTABLE)
endif

那么这里到底是怎么回事呢？JAVA层利用jni也是如此操作的。

这里是通过 IPCThreadState 类直接将binder请求写入到binder驱动(/dev/binder),这里简要说一下简单的流程，后续还会继续深入这个问题：

addService @ IServiceManager.cpp
status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
-->
transact @ IPCThreadState
transact() --> writeTransactionData() 写入到binder驱动，这就是核心所在。。。

现在就进入到最重要的 servicemanager 大总管角色中了
源码路径：frameworks\base\cmds\servicemanager\service_manager.c

servicemanager 是一个进程，在init.rc脚本中开机就启动：
service servicemanager /system/bin/servicemanager
    user system
    critical
    onrestart restart zygote
    onrestart restart media
    
从其main中开始分析：
main @ service_manager.c


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;
}

调用binder_open打开binder设备（/dev/binder），其次它调用了binder_become_context_manager函数，这个函数使他自己变为了"Server大总管"

int binder_become_context_manager(struct binder_state *bs)
{
    return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}
即成为一个0号句柄，所有的进程都可以通过id=0来访问它。

Service Manager作为一个Server大总管，本身也是一个server。既然是一个server就要时刻准备为客户端提供服务。最好Service Manager调用binder_loop进入到循环状态，并提供了一个回调函数，等待用户的请求。注意他的Service Manager的客户端既包括应用程序（查询和获取服务），也包括Server（注册服务）。

只要server向binder设备写入请求注册Service时，Service Manager的服务处理回调函数将会被调用
这里的回调函数就是 svcmgr_handler:
int svcmgr_handler(struct binder_state *bs,
                   struct binder_txn *txn,
                   struct binder_io *msg,
                   struct binder_io *reply)
{
    // 获取请求数据
    strict_policy = bio_get_uint32(msg);
    s = bio_get_string16(msg, &len);


    switch(txn->code) {
    case SVC_MGR_GET_SERVICE:  // 获取service服务
    case SVC_MGR_CHECK_SERVICE:
        s = bio_get_string16(msg, &len);
        ptr = do_find_service(bs, s, len);
        if (!ptr)
            break;
        bio_put_ref(reply, ptr);
        return 0;


    case SVC_MGR_ADD_SERVICE: // 注册service服务
        s = bio_get_string16(msg, &len);
        ptr = bio_get_ref(msg);
        if (do_add_service(bs, s, len, ptr, txn->sender_euid))
            return -1;
        break;


    case SVC_MGR_LIST_SERVICES: { // 列举service服务
        unsigned n = bio_get_uint32(msg);


        si = svclist;
        while ((n-- > 0) && si)
            si = si->next;
        if (si) {
            bio_put_string16(reply, si->name);
            return 0;
        }
        return -1;
    }
}

这里也是对请求的服务回写到binder驱动，别忘记了客户端同步处理：
transact @ IPCThreadState.cpp
    if ((flags & TF_ONE_WAY) == 0) {
        if (reply) {
            err = waitForResponse(reply);
        } else {
            Parcel fakeReply;
            err = waitForResponse(&fakeReply);
        }
    } else {
        err = waitForResponse(NULL, NULL);
    }
--> 这里利用talkWithDriver()利用：
ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) 请求与回应数据。

IPCThreadState 是一个非常关键的类，由其直接于binder驱动打交道，后文将会重点分析。

 

模块层次基本如下：

 

已有 0 人发表留言，猛击->> 这里<<-参与讨论


ITeye推荐

• —软件人才免语言低担保 赴美带薪读研！—