本文均属自己阅读源码的点滴总结,转账请注明出处谢谢。
欢迎和大家交流。qq:1037701636 email:gzzaigcn2012@gmail.com
Android源码版本Version:4.2.2; 硬件平台 全志A31
step1.前面的几张博文都在记录SurfaceFLinger侧,也就是所谓的Server端,接下去就和大家来看看客户端是如何将要处理的图形信息请求SF来传递出去的呢。大家学习的一个方式都是通过android启动的第一个开机画面来入手的,先来看看启动的函数,再来看这个类BootAnimation。
int main(int argc, char** argv)//由surfaceflinger来触发init进程来启动它
{
#if defined(HAVE_PTHREADS)
setpriority(PRIO_PROCESS, 0, ANDROID_PRIORITY_DISPLAY);
#endif
char value[PROPERTY_VALUE_MAX];
property_get("debug.sf.nobootanimation", value, "0");
int noBootAnimation = atoi(value);
ALOGI_IF(noBootAnimation, "boot animation disabled");
if (!noBootAnimation) {
sp<ProcessState> proc(ProcessState::self());
ProcessState::self()->startThreadPool();//这里会进行binder的驱动初始化
// create the boot animation object
sp<BootAnimation> boot = new BootAnimation();//初始化并会调用BootAnimation的onFirstRef,启动一个线程
boot->playBootMusic("/system/media/boot.wav");
IPCThreadState::self()->joinThreadPool();
}
return 0;
}
我们会问Bootanimation是在哪里启动的呢,可以看我之前写的文章android从init到开机动画启动关闭流程一简易图(surfaceflinger启动的位置)里面讲到了SF启动之后init主进程才有可能启动它,因为bootanimation在init.rc是配置为disable,在SF里面会出现的readyToRun函数内的startBootAnim();//开启动画属性,通过设置内存属性值来触发Init进程来启动:
void SurfaceFlinger::startBootAnim() {
// start boot animation
property_set("service.bootanim.exit", "0");
property_set("ctl.start", "bootanim");
}
其中property_set会将一个ctl.statrt属性发送到init中建立的property Service之中后调用handle_property_set_fd->handle_control_message,此时发送的属性值为bootanim即表示一个服务名,因为init.rc中是disable的所以没去启动,这里设置属性过程ctl.就表明需要start一个服务bootanim,也就是启动开机动画进程:
在BootAnimation的main函数中,开始新建类的对象。
BootAnimation::BootAnimation() : Thread(false)
{
mSession = new SurfaceComposerClient();//SurfaceComposerClient,msession:sp<SurfaceComposerClient>
}
可以想象的到,作为线程类Thread的派生类,明显的很多事情是在thread的readyToRun和ThreadLoop里面发生的,而新线程也一般就是在OnFirstRef中启动run函数的。
在BootAnimation的构造函数中看到了一个SurfaceComposerClient类,理解为界面合成客户端,的确BootAnimation将会作为一个客户端请求SF去完成图层的渲染。那么SCC是如何和SF交互的呢,我们来看SCC的构造过程。
SurfaceComposerClient::SurfaceComposerClient()
: mStatus(NO_INIT), mComposer(Composer::getInstance())
{
}
void SurfaceComposerClient::onFirstRef() {
sp<ISurfaceComposer> sm(ComposerService::getComposerService());//获得SurfaceFlinger的proxy BpSurfaceComposer
if (sm != 0) {
sp<ISurfaceComposerClient> conn = sm->createConnection();//建立一个连接,获得SurfaceFlinger远程的客户端BpSurfaceComposerClient,对应于服务端的Client
if (conn != 0) {
mClient = conn;//BpISurfaceComposerClient保存在mclient
mStatus = NO_ERROR;
}
}
}
在调用构造函数时初始化一个Composer类成员变量,且为单列模式。再来看onFirstRef中的操作,ComposerService::getComposerService:
sp<ISurfaceComposer> ComposerService::getComposerService() {
ComposerService& instance = ComposerService::getInstance();//ComposerService对象创建,单列模式BpSurfaceComposer,保存在其成员mComposerService
Mutex::Autolock _l(instance.mLock);
if (instance.mComposerService == NULL) {
ComposerService::getInstance().connectLocked();
assert(instance.mComposerService != NULL);
ALOGD("ComposerService reconnected");
}
return instance.mComposerService;//成员代码BpSurfaceComposer
}
内部又出现一个ComposerService这个单列模式,看看他的构造函数:
ComposerService::ComposerService()
: Singleton<ComposerService>() {
Mutex::Autolock _l(mLock);
connectLocked();
}
果然会调用一个connectLocked函数:
void ComposerService::connectLocked() {
const String16 name("SurfaceFlinger");
while (getService(name, &mComposerService) != NO_ERROR) {//返回surfaceflinger的代理到mComposerService
usleep(250000);
}
很清楚的是getService,可以想象的是应该是和ServiceManger在交互了,如下:
status_t getService(const String16& name, sp<INTERFACE>* outService)
{
const sp<IServiceManager> sm = defaultServiceManager();
if (sm != NULL) {
*outService = interface_cast<INTERFACE>(sm->getService(name));
if ((*outService) != NULL) return NO_ERROR;
}
return NAME_NOT_FOUND;
}
果然在这里就是看到了通用的客户端和SM的交互过程了,这里就是实现了客户端请求SM返回SurfaceFlinger的服务端在本地的代理proxy。最终保存到mCompserService变量中且该对象的类型为BpSurfaceComposer和SF(实际上SF继承了BnSurfaceComposer这个本地对象)处建立起基于Binder的C/S通信架构。
好了上面的代码执行了这么多就是为了调用sm->createConnection()函数,这个就是典型的Binder通信方式了,可以看到:
virtual sp<ISurfaceComposerClient> createConnection()
{
uint32_t n;
Parcel data, reply;
data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());
remote()->transact(BnSurfaceComposer::CREATE_CONNECTION, data, &reply);
return interface_cast<ISurfaceComposerClient>(reply.readStrongBinder());//返回的Bpbinder转为SurfaceComposerClient
}
最终返回的是一个BpSurfaceComposerClient,当然核心的处理都是SF在建立的。那么回到SurfaceFlinger里面看看这个BpSurfaceComposerClient对象在SF里的实际角色吧。
SF最终会调用createConnection()函数(这个过程分别经过了BnSurfaceComposer的onTransact处理,SF继承了BnSurfaceComposer).
sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()
{
sp<ISurfaceComposerClient> bclient;
sp<Client> client(new Client(this));//客户端远程调用时new一个BnSurfaceComposerClient
status_t err = client->initCheck();
if (err == NO_ERROR) {
bclient = client;
}
return bclient;
}
可以看到这里是调用了这个Client,而基于Binder通信架构的话这个Client肯定是继承了BnSurfaceComposerClient,故BnSurfaceComposerClient在SF中其实是一个Client类,
status_t BnSurfaceComposer::onTransact(//内部函数由继承类SF来完成
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
switch(code) {
case CREATE_CONNECTION: {
CHECK_INTERFACE(ISurfaceComposer, data, reply);
sp<IBinder> b = createConnection()->asBinder();//创建一个Bpbinder
reply->writeStrongBinder(b);//返回给客户端一个BpBinder的handle
} break;
最终转为Binder类型,写入到Binder分配一个唯一的handle,最终写回给BpSurfaceComposer客户端供进一步的BpSurfaceComposerClient和Client之间的通信,而这个Client的代理最终保存在SurfaceComposerClient类对象的成员函数mClient中去。
step2.接着看Bootanimation里的readyToRun(),内部有如下的一个函数即创建本地的Surface。
// create the native surface
sp<SurfaceControl> control = session()->createSurface(String8("BootAnimation"),
dinfo.w, dinfo.h, PIXEL_FORMAT_RGB_565);//请求surfaceflinger来创建一个surface
session()函数返回之前创建的SurfaceComposerClient,上述函数实际实现如下:
sp<SurfaceControl> SurfaceComposerClient::createSurface(
const String8& name,
uint32_t w,
uint32_t h,
PixelFormat format,
uint32_t flags)
{
sp<SurfaceControl> result;
if (mStatus == NO_ERROR) {
ISurfaceComposerClient::surface_data_t data;
sp<ISurface> surface = mClient->createSurface(&data, name,
w, h, format, flags);//对应的由SF侧的錍lient来完成, BpSurface
if (surface != 0) {
result = new SurfaceControl(this, surface, data);//将得到的surface关联到一个SurfaceControl
}
}
return result;
}
很显然可以看到是有mClient来实现的,故在SF侧就是由之前的new Client处创建的一个Client来完成这个交互的。故回到Client的onTransact函数中去
status_t Client::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
....return BnSurfaceComposerClient::onTransact(code, data, reply, flags);//内部就是调用继承类Client的createSurface
}
接着往下看:
status_t BnSurfaceComposerClient::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
switch(code) {
case CREATE_SURFACE: {
CHECK_INTERFACE(ISurfaceComposerClient, data, reply);
surface_data_t params;
String8 name = data.readString8();
uint32_t w = data.readInt32();
uint32_t h = data.readInt32();
PixelFormat format = data.readInt32();
uint32_t flags = data.readInt32();
sp<ISurface> s = createSurface(¶ms, name, w, h,
format, flags);//创建一个surface
params.writeToParcel(reply);
reply->writeStrongBinder(s->asBinder());//本地的BBinder写入给客户端
return NO_ERROR;
} break;......
因为BnSurfaceComposerClient被Client继承,故实际调用的还是Client的createrSurface()函数,相关的实现见下一博文SurfaceFlinger中Surface和Layer的建立。