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<ProcessState> ps(ProcessState::self());//忽略
ps->startThreadPool(); // instantiate surfaceflinger
sp<SurfaceFlinger> 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<IServiceManager> sm(defaultServiceManager()); 开始，这里有个sp，简单介绍</span>
一下，这是c++中为了防止指针出现段错误而设计的一种智能指针，smart pointer！用法是怎样的呢，其实很简单。sp<XXXX> 等同于 XXXX* ,比如 sp<char> == char* 很粗暴吧。。。
回归正题，这里定义了一个IServiceManage的对象，sm（xx）就是把sm初始化为xx，所以现在看看sm被初始化成什么。我们跟踪下deafaultServieManager（）。
sp<IServiceManager> defaultServiceManager()
{
if (gDefaultServiceManager != NULL) return gDefaultServiceManager;//忽略</span>
{
AutoMutex _l(gDefaultServiceManagerLock); //这个就是上锁的意思</span>
while (gDefaultServiceManager == NULL) {
gDefaultServiceManager = interface_cast<IServiceManager>( //重头戏在这 ProcessState::self()->getContextObject(NULL));
if (gDefaultServiceManager == NULL)
sleep(1);
}
}
return gDefaultServiceManager;
}
gDefaultServiceManager是怎么来的。
gDefaultServiceManager = interface_cast<IServiceManager>( //重头戏在这 ProcessState::self()->getContextObject(NULL));我FTSC！！又调用了函数，我们乖乖跟踪下 interface_cast<IServiceManager>( ProcessState::self()->getContextObject(NULL)) 这个函数。。首先看一下它那吓死人的参数：
首先是一个self（）：
sp<ProcessState> ProcessState::self()
{
Mutex::Autolock _l(gProcessMutex);
if (gProcess != NULL) {
return gProcess;
}
gProcess = new ProcessState;
return gProcess;
}
他其实就是返回一个初始化好的 ProcessState类对象，然后接着看getContextObject(NULL)，这个函数在ProcessState中，是成员函数，注意了，传进去的是null，我们看下实体：
sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& caller)
{
return getStrongProxyForHandle(0);
}
不多说了，继续跟踪 getStrongProxyForHandle(0);
sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
{
sp<IBinder> 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<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
return INTERFACE::asInterface(obj);
}
再看看函数体。。。。shit！！又是一个函数。我们继续跟踪 asInterface(obj);
好吧，我找了好半天，发现没有找到定义。。。但是看到了一个奇怪的东西。。就是发现他在宏定义里面申明的然后又在宏定义里面实现的！！是在IInterface.h中的定义的。
#define DECLARE_META_INTERFACE(INTERFACE) \
static const android::String16 descriptor; \
static android::sp<I##INTERFACE> asInterface( \
const android::sp<android::IBinder>& 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> I##INTERFACE::asInterface( \
const android::sp<android::IBinder>& obj) \
{ \
android::sp<I##INTERFACE> intr; \
if (obj != NULL) { \
intr = static_cast<I##INTERFACE*>( \
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<IBinder>& 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<android::IBinder>& 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> IServiceManager::asInterface(
const android::sp<android::IBinder>& obj)
{
android::sp<IServiceManager> intr;
if (obj != NULL) {
intr = static_cast<IServiceManager *>(
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<IServiceManager> sm(defaultServiceManager());
发现，实质上也没做什么事啊，不行，我们再回去研究一下 BpServiceManager。。
三 关于BpServiceManager
之前一篇文章说过Bp 中p是proxy的意思，也就是代理。B其实就是传说中的叱咤江湖的 ”Binder“。。。。有点阴谋了，记得之前提过的那个大阴谋？我们接下去看。先找到这个类的相关定义（在IServiceManager.h中）：
class BpServiceManager : public BpInterface<IServiceManager>
{
public:
BpServiceManager(const sp<IBinder>& impl)
: BpInterface<IServiceManager>(impl)
{
//构造函数的形参是IBinder参数，但是实际上传进来的是new BpBinder(0) （ps：为什么呢？之前最开始的时候传进来的参数就是BpBinder类的，只是形参一直写成IBinder又是BpBinder，而且参数名是impl，敏感吗，不就是implement的缩写，实现？难道有猫腻？接着看。 }
virtual sp<IBinder> getService(const String16& name) const
{
//忽略
}
virtual sp<IBinder> checkService( const String16& name) const
{
。。。。。忽略
}
//这是个重要的函数 不能忽略先把他记在心里，待会会解释 virtual status_t addService(const String16& name, const sp<IBinder>& 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<String16> listServices()
{
//忽略
}
}; 好了，我们知道上一环节有提到
BpServiceManager的是这行代码
intr = new BpServiceManager(obj);传进去的obj参数是IBinder类的，构造函数是
BpServiceManager(const sp<IBinder>& impl)
: BpInterface<IServiceManager>(impl)
传进去的参数 直接进入BpInterface（）这个函数，内容如下：
template<typename INTERFACE>
inline BpInterface<INTERFACE>::BpInterface(const sp<IBinder>& remote)
: BpRefBase(remote)
{
}我了个cacaca，传进来的impl改名为 remote，又来个
BpRefBase(remote)，android元老们，你爸妈造你这么吊吗。。。。继续跟踪这个函数：
BpRefBase::BpRefBase(const sp<IBinder>& 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> 也就是返回一个XXX*的指针，也就是说 mRemote被初始化成 BpBinder类对象，看他做了什么？shit？看不懂啊 。。。。不管了忽略掉！
好好现在我们重新回到
BpServiceManager，再回一步
sp<IServiceManager>sm(defaultServiceManager());
//简单说返回的实际是BpServiceManager，它的remote对象是BpBinder，传入的那个handle参数是0。
//简单说返回的实际是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<ProcessState> ps(ProcessState::self());
//忽略。。
ps->startThreadPool();
// instantiate surfaceflinger
sp<SurfaceFlinger> 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<IServiceManager> 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<IBinder>& 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的敌军大营，看看它内部到底是怎么回事。