Android4.4深入浅出之SurfaceFlinger(一)

           同样还是surfaceflinger,最近有点进展,特地分享!

一 开门见山

     android 源代码中的类名真的是乱的一塌糊涂,经过一周多的研读The Fucking Source Code,终于有点眉头。首先surfaceflinger(以后简称SF),负责管理渲染UI的,他是个service,一直跟application交互,实时刷新surface。

     

知道这个,我从service这个点入手,之前尝试过直接看SF类等等,但是都搞不清楚头绪,所以改道service。

二 SF这个service的起源诞生

     在源码frameworks/native/service/surfaceflinger/main_surfaceflinger.cpp 中,让我们扒一扒是啥玩意。。

 

    

int main(int argc, char** argv) {
    // When SF is launched in its own process, limit the number of
    // binder threads to 4.
    ProcessState::self()->setThreadPoolMaxThreadCount(4); //忽略。。

    // start the thread pool
    sp ps(ProcessState::self());//忽略
    ps->startThreadPool(); // instantiate surfaceflinger 
    sp flinger = new SurfaceFlinger();//好戏从这里开始,得到一个SF对象
    #if defined(HAVE_PTHREADS) 
    setpriority(PRIO_PROCESS, 0, PRIORITY_URGENT_DISPLAY);
    #endif set_sched_policy(0, SP_FOREGROUND); // initialize before clients can connect 
    flinger->init();//SF的初始化 
    //publish surface flinger 
    sm(defaultServiceManager()); //得到一个ServiceManager对象 
    sm->addService(String16(SurfaceFlinger::getServiceName()), flinger, false); // // run in this thread 
    flinger->run();//服务开始运行了!!! }

 

    是不是无语了。。。对就是这么简单粗暴。但是丫的没这么简单吧。好了我们开始从

sp sm(defaultServiceManager()); 开始,这里有个sp,简单介绍
一下,这是c++中为了防止指针出现段错误而设计的一种智能指针,smart pointer!用法是怎样的呢,其实很简单。sp  等同于 XXXX* ,比如 sp == char* 很粗暴吧。。。
       回归正题,这里定义了一个IServiceManage的对象,sm(xx)就是把sm初始化为xx,所以现在看看sm被初始化成什么。我们跟踪下deafaultServieManager()。
     
sp defaultServiceManager()
{
    if (gDefaultServiceManager != NULL) return gDefaultServiceManager;//忽略
    
    {
        AutoMutex _l(gDefaultServiceManagerLock); //这个就是上锁的意思
        while (gDefaultServiceManager == NULL) {
            gDefaultServiceManager = interface_cast(    //重头戏在这                                                          ProcessState::self()->getContextObject(NULL));
            if (gDefaultServiceManager == NULL)
                sleep(1);
        }
    }
    
    return gDefaultServiceManager;
}
gDefaultServiceManager是怎么来的。
gDefaultServiceManager = interface_cast(    //重头戏在这                                                          ProcessState::self()->getContextObject(NULL));
我FTSC!!又调用了函数,我们乖乖跟踪下 interface_cast  ProcessState::self()->getContextObject(NULL)) 这个函数。。首先看一下它那吓死人的参数:
   首先是一个self():

sp ProcessState::self()
{
    Mutex::Autolock _l(gProcessMutex);
    if (gProcess != NULL) {
        return gProcess;
    }
    gProcess = new ProcessState;
    return gProcess;
}

他其实就是返回一个初始化好的 ProcessState类对象,然后接着看getContextObject(NULL),这个函数在ProcessState中,是成员函数,注意了,传进去的是null,我们看下实体:
 
sp ProcessState::getContextObject(const sp& caller)
{
    return getStrongProxyForHandle(0);
}

不多说了,继续跟踪 getStrongProxyForHandle(0);

sp ProcessState::getStrongProxyForHandle(int32_t handle)
{
    sp result; 

    AutoMutex _l(mLock);//上锁

    handle_entry* e = lookupHandleLocked(handle);//
    if (e != NULL) { 
        IBinder* b = e->binder;
        if (b == NULL || !e->refs->attemptIncWeak(this)) //刚开始b肯定为NULL                                                                if (handle == 0) {//刚刚传进来的handle是0!                                                                                            Parcel data;         //下面做了什么我也不知道估计不影响
                status_t status = IPCThreadState::self()->transact(
                        0, IBinder::PING_TRANSACTION, data, NULL, 0);
                if (status == DEAD_OBJECT)
                   return NULL;
            }                                                                                                                                //这是重头戏啊 又来了个BpBinder?是啥玩意待会再说  	                                                                             b = new BpBinder(handle); 
            e->binder = b;
            if (b) e->refs = b->getWeakRefs();
            result = b;
        } else {
            
            result.force_set(b);
            e->refs->decWeak(this);
        }
    }


    return result;//总之返回的是一个BpBinder类。}
BpBinder是个强大深奥的东西,下面会专门讲一下,先接着看吧。
参数是BpBinder类的,接下俩看函数是怎么定义的。。
这里我们不妨留意一下 它的参数?函数的形参是IBinder类的,查了下才知道BpBinder继承了IBinder,所以形参是IBinder也不会有什么大问题。。。这这。。难道有一场阴谋??
template
inline sp interface_cast(const sp& obj)
{
    return INTERFACE::asInterface(obj);
}	

好吧,这是模板的使用,再看看原函数的调用在函数名后面有个尖括号<>,这下知道他的作用了吧,对!尖括号内的东西是用来代替    sp 中的 INTERFACE,也就是 IServiceManager代替INTERFACE
再看看函数体。。。。shit!!又是一个函数。我们继续跟踪
asInterface(obj);       
     好吧,我找了好半天,发现没有找到定义。。。但是看到了一个奇怪的东西。。就是发现他在宏定义里面申明的然后又在宏定义里面实现的!!是在IInterface.h中的定义的。
      
#define DECLARE_META_INTERFACE(INTERFACE)                               \
    static const android::String16 descriptor;                          \
    static android::sp asInterface(                       \
            const android::sp& obj);                  \
    virtual const android::String16& getInterfaceDescriptor() const;    \
    I##INTERFACE();                                                     \
    virtual ~I##INTERFACE();                                            \
这是声明。。。。接下来是实现的宏定义:
#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME)                       \
    const android::String16 I##INTERFACE::descriptor(NAME);             \
    const android::String16&                                            \
            I##INTERFACE::getInterfaceDescriptor() const {              \
        return I##INTERFACE::descriptor;                                \
    }                                                                   \
    android::sp I##INTERFACE::asInterface(                \
            const android::sp& obj)                   \
    {                                                                   \
        android::sp intr;                                 \
        if (obj != NULL) {                                              \
            intr = static_cast(                          \
                obj->queryLocalInterface(                               \
                        I##INTERFACE::descriptor).get());               \
            if (intr == NULL) {                                         \
                intr = new Bp##INTERFACE(obj);                          \
            }                                                           \
        }                                                               \
        return intr;                                                    \
    }                                                                  \
    I##INTERFACE::I##INTERFACE() { }                                    \
    I##INTERFACE::~I##INTERFACE() { }                                   \
脑袋瓜表示不够用了,好一个乱七八糟,乱八九糟,乱九十糟。。。。。红色部分分别是asInterface的声明和定义。这个时候我在想这是两个宏而已,到底他在哪里被调用了。
    好!这里我们回到前一步 interface_cast 函数实体是 return IServiceManage::asInterface(obj);这个函数应该定义在
IServiceManage类中才是啊,于是我去跟踪了下IServiceManage这个类:
   
class IServiceManager : public IInterface

{
public:

    DECLARE_META_INTERFACE(ServiceManager);

     virtual status_t   addService( const String16& name,

                                            const sp& service) = 0;
      // 。。。。。。
};

好吧,看到这个类的第三行顿时感觉世界有救了,这不就是之前的宏定义吗,原来着这里调用了。。。好,我们在穿越时空到那个宏定义。。。。
  发现了什么?他的参数是个INTERFACE 跟刚刚的模板很像吧,不管了把所有的INTERFACE换成  ServiceManager, 宏定义中还有类似 I##INTERFACE ,其实即使翻译成 IINTERFACE,看看上面那个 ServiceManager类中的调用他的参数就是 ServiceManager,所以 在宏定义里面就变成 I ServiceManager,好吧!我把他翻译一下。声明翻译成以下:

static const android::String16 descriptor; 

static android::sp< IServiceManager > asInterface(const android::sp&

obj) 
virtual const android::String16& getInterfaceDescriptor() const; 

IServiceManager ();                                                     \
virtual ~IServiceManager();

实现翻译如下:
const android::String16 IServiceManager::descriptor(“android.os.IServiceManager”);

const android::String16& IServiceManager::getInterfaceDescriptor() const

 {  return IServiceManager::descriptor;//返回上面那个android.os.IServiceManager

   }                                                                      android::sp IServiceManager::asInterface(

            const android::sp& obj)

    {

        android::sp intr;

        if (obj != NULL) {                                             

            intr = static_cast(                         

                obj->queryLocalInterface(IServiceManager::descriptor).get());              

            if (intr == NULL) {                                         

                intr = new BpServiceManager(obj);                         

            }                                                          

        }                                                               

        return intr;                                                   

    }                                                                 

    IServiceManager::IServiceManager () { }                                   

    IServiceManager::~ IServiceManager() { }
  好我们重点看下  asInterface 这个函数体,妈的绕了这么久终于可以接下去走了。简单分析下,程序走到第一个if进去了,然后第一次intr还是null所以又走到第二个if,对intr被初始化成一个 BpServiceManager对象。。。。
     问题来了,BpServiceManager是什么东西,暂且不管,携带着这个坑爹的结果然我们一步步退出苦海,来到最开始的
sp sm(defaultServiceManager());
 发现,实质上也没做什么事啊,不行,我们再回去研究一下 BpServiceManager。。

三  关于BpServiceManager

   之前一篇文章说过Bp 中p是proxy的意思,也就是代理。B其实就是传说中的叱咤江湖的 ”Binder“。。。。有点阴谋了,记得之前提过的那个大阴谋?我们接下去看。先找到这个类的相关定义(在IServiceManager.h中):

class BpServiceManager : public BpInterface
{
public:
    BpServiceManager(const sp& impl)
        : BpInterface(impl)
    {
//构造函数的形参是IBinder参数,但是实际上传进来的是new BpBinder(0) (ps:为什么呢?之前最开始的时候传进来的参数就是BpBinder类的,只是形参一直写成IBinder又是BpBinder,而且参数名是impl,敏感吗,不就是implement的缩写,实现?难道有猫腻?接着看。    }

    virtual sp getService(const String16& name) const
    {
        //忽略
    }

    virtual sp checkService( const String16& name) const
    {
      。。。。。忽略
    }
//这是个重要的函数 不能忽略先把他记在心里,待会会解释                                                                                     virtual status_t addService(const String16& name, const sp& service,
            bool allowIsolated)
    {
        Parcel data, reply;
        data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
        data.writeString16(name);
        data.writeStrongBinder(service);
        data.writeInt32(allowIsolated ? 1 : 0);
        status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
        return err == NO_ERROR ? reply.readExceptionCode() : err;
    }

    virtual Vector listServices()
    {
       //忽略
    }
};
   好了,我们知道上一环节有提到 BpServiceManager的是这行代码  intr = new BpServiceManager(obj);传进去的obj参数是IBinder类的,构造函数是 BpServiceManager(const sp& impl) : BpInterface(impl)
传进去的参数 直接进入BpInterface()这个函数,内容如下:
template
inline BpInterface::BpInterface(const sp& remote)
    : BpRefBase(remote)
{
}
我了个cacaca,传进来的impl改名为 remote,又来个 BpRefBase(remote),android元老们,你爸妈造你这么吊吗。。。。继续跟踪这个函数:

BpRefBase::BpRefBase(const sp& o)
    : mRemote(o.get()), mRefs(NULL), mState(0)
{
    extendObjectLifetime(OBJECT_LIFETIME_WEAK);

    if (mRemote) {
        mRemote->incStrong(this);           // Removed on first IncStrong().
        mRefs = mRemote->createWeak(this);  // Held for our entire lifetime.
    }
}

好吧,他的名字又变了,是 o,对参数是o,记住是BpBinder类的。看他做了什么。o.get();返回的是一个sp 也就是返回一个XXX*的指针,也就是说 mRemote被初始化成 BpBinder类对象,看他做了什么?shit?看不懂啊 。。。。不管了忽略掉!

   好好现在我们重新回到 BpServiceManager,再回一步 spsm(defaultServiceManager());
//简单说返回的实际是BpServiceManager,它的remote对象是BpBinder,传入的那个handle参数是0。

四  添加service

 我们再回到之前最开始的main函数,继续往下走
int main(int argc, char** argv) {
    // When SF is launched in its own process, limit the number of
    // binder threads to 4.
    ProcessState::self()->setThreadPoolMaxThreadCount(4); //忽略。。

    // start the thread pool
    sp ps(ProcessState::self());
//忽略。。

    ps->startThreadPool();

    // instantiate surfaceflinger
    sp flinger = new SurfaceFlinger();//好戏从这里开始,得到一个SF对象

#if defined(HAVE_PTHREADS)
    setpriority(PRIO_PROCESS, 0, PRIORITY_URGENT_DISPLAY);
#endif
    set_sched_policy(0, SP_FOREGROUND);

    // initialize before clients can connect
    flinger->init();//SF的初始化

    // publish surface flinger
    sp sm(defaultServiceManager()); //得到一个ServiceManager对象
    sm->addService(String16(SurfaceFlinger::getServiceName()), flinger, false);  //
    // run in this thread
    flinger->run();//服务开始运行了!!!

 }
这个时候走到 sm->addService(String16(SurfaceFlinger::getServiceName()), flinger, false);
  看函数明就知道,刚刚创建的服务要开始添加了,这是个怎样的机制了,其实ServiceManage是一个服务管理员,所有的service都要在这边登记信息,然后申请创建,有条不紊,便于管理。
  看一下addService的函数实体:
   
 virtual status_t addService(const String16& name, const sp& service,
            bool allowIsolated)
    {
        Parcel data, reply;
        data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
        data.writeString16(name);
        data.writeStrongBinder(service);
        data.writeInt32(allowIsolated ? 1 : 0);
        status_t err = remote()->transact(ADD_SERVICE_TRANSACTION, data, &reply);
        return err == NO_ERROR ? reply.readExceptionCode() : err;
    }

先看它的三个参数,第一个是一个字符串服务的名字,第二个就是这个service ,是IBinder类的,虽然传进来的是flinger 是SF类的,但是SF继承了IBinder,所以这里是可以的。
       Parcel的对象data,顾名思义是个数据包吧or缓冲区,接下去的四行都是把相关的一些信息比如interface描述信息,服务名称,本身service的binder都写到data里,然后通过transact()进行处理,这里的remote()是不是很眼熟,对,他其实就是BpBinder::remote(),接着往下看看到他返回的不是什么好东西,算了忽略掉,我们研究的是SF,这些在深入就是Binder机制的问题了。总结说,这个函数就是向管理者注册了SF这个service的一些基本信息。
        到这里我们是不是忽略了一行程序,flinger->init(); 这行说是SF的一些初始化,但是也是有很多的内容的。好,从此刻开始 ,我们终于开始进军SF的敌军大营,看看它内部到底是怎么回事。

 



     
     
      













你可能感兴趣的:(Android,C/C++)