Android模拟器图形绘原理(二十二)

//error

}

… ready to go

这里的pipeName是要使用的服务名程，这里支持的服务有

• tcp:

提供一个非内部模拟器的NAT router，我们只能使用这个socket进行读写，接受，不能够进行连接非本地socket。

• unix:

打开一个Unix域socket在主机上

• opengles

连接到OpenGL ES模拟进程，现在这个实现等于连接tcp：22468，但是未来可能会改变。

• qemud

连接到qemud服务在模拟器内，这个取代了老版本中通过/dev/ttys1的连接方式.

在内核中代码，向外提供了一个对于qemu_pipe，其中包含了我们如何与其进行交互。

由于QEMU Pipe发送数据的时候使用的是裸包，其速度要比TCP的方式快很多。

通信协议的实现

对于指令的传输，要对指令进行编解码。emugen，通过这个工具可以进行编码解码类的生成。在GLES1.1，GLES2.0，EGL之中定义了一些代码生成时，需要用到的文件。用来定义生成代码的文是.types，.in，.attrib。对于EGL的声明则是在renderControl。对于EGL的文件都是以‘renderControl’开头的，这个主要是历史原因，他们调用了gralloc系统的模块来管理图形缓冲区在比EGL更低的级别。

EGL/GLES函数调用被通过一些规范文件进行描述，这些文件描述了类型，函数签名
和它们的一些属性。系统的encoder静态库就是通过这些生成的文件来构建的，它们包含了可以将EGL/GLES命令转化为简单的byte信息的通过IOStream进行发送。

模拟器的绘制

模拟器接收渲染指令的位置，

在android/opengles.cpp控制了动态的装载渲染库，和正确的初始化，构建它。host 渲染的库在host/libs/libOpenglRender下，在模拟器opengles下的代码掌管动态装载一些渲染的库。

• RendererImpl

模拟器接收指令渲染的实现在RendererImpl中，对于每一个新来的渲染client，都会通过createRenderChannel来创建一个RenderChannel，然后创建一个RenderThread。

RenderChannelPtr RendererImpl::createRenderChannel() {

const auto channel = std::make_shared();

std::unique_ptr rt(RenderThread::create(

shared_from_this(), channel));

if (!rt->start()) {

fprintf(stderr, “Failed to start RenderThread\n”);

return nullptr;

}

return channel;

}

RenderThread相关创建代码

std::unique_ptr RenderThread::create(

std::weak_ptr renderer,

std::shared_ptr channel) {

return std::unique_ptr(

new RenderThread(renderer, channel));

}

RenderThread::RenderThread(std::weak_ptr renderer,

std::shared_ptr channel)

emugl::Thread(android::base::ThreadFlags::MaskSignals, 2 * 1024 * 1024),

mChannel(channel), mRenderer(renderer) {}

在RenderThread创建成功之后，调用了其start方法。进入死循环，从ChannelStream之中读取指令流，然后对指令流进行decode操作。

ChannelStream stream(mChannel, RenderChannel::Buffer::KSmallSize);

while(1) {

initialize decoders

//初始化解码部分

tInfo.m_glDec.initGL(gles1_dispatch_get_proc_func, NULL); tInfo.m_gl2Dec.initGL(gles2_dispatch_get_proc_func, NULL); initRenderControlContext(&tInfo.m_rcDec);

ReadBuffer readBuf(kStreamBufferSize);

const int stat = readBuf.getData(&stream, packetSize);

//尝试通过GLES1解码器来解码指令流

size_t last = tInfo.m_glDec.decode( readBuf.buf(), readBuf.validData(), &stream, &checksumCalc);

if (last > 0) {

progress = true;

readBuf.consume(last);

}

//尝试通过GLESV2的解码器来进行指令流

last = tInfo.m_gl2Dec.decode(readBuf.buf(), readBuf.validData(),

&stream, &checksumCalc);

FrameBuffer::getFB()->unlockContextStructureRead();

if (last > 0) {

progress = true;

readBuf.consume(last);

}

//尝试通过renderControl解码器来进行指令流的解码

last = tInfo.m_rcDec.decode(readBuf.buf(), readBuf.validData(),

&stream, &checksumCalc);

if (last > 0) {

readBuf.consume(last);

progress = true;

}

}

解码过程，省略部分代码。保留了核心处理代码。

指令流的来源

上面的指令流处理的数据从ChannelStream中来获取，这里从ChannelStream着手进行分析。

• ChannelStream

我们先来看一下我们的协议流数据从何处而来，从数据读取翻译过程可以看出是来自我们的 ChannelStream，而ChannelStream又是对于Channle的包装。接下来看一下ChannelStream的实现。

可以看到其是对于RenderChannel的一个包装，同时有两个Buffer。

• ChannelStream 实现自IOStream

class ChannelStream final : public IOStream

ChannelStream(std::shared_ptr channel, size_t bufSize);

声明了以下变量

std::shared_ptr mChannel;

RenderChannel::Buffer mWriteBuffer;

RenderChannel::Buffer mReadBuffer;

ChannelStream是对于RenderChannel进行了一次包装，对于具体的操作还是交到RenderChannel进行执行，RenderChannel负责在Guest和Host之间的协议数据通信，然后ChannleStream提供了一些buffer在对其封装的基础上，更方便的获取其中的数据，同时由于继承自IOStream，也定义了其中的一些接口，更方便调用。对于数据的读写最终调用了RenderChannel的readFromGuest和writeToGuest，其提供了一个Buffer来方便进行数据的读写。

• RenderChannel

RenderChannel中的数据从哪里而来呢？跟进其几

资料获取→专栏
个读写方法，我们便会发现，其具体的执行是交给了mFromGuest和mToGuest，其类型分别为

BufferQueue mFromGuest;

BufferQueue mToGuest;

通过调用其push，pop方法，从中获取数据，到此，我们可以再继续跟进一下BufferQueue的创建和实现。

• BufferQueue

mFromGuest(kGuestToHostQueueCapacity, mLock),

mToGuest(kHostToGuestQueueCapacity, mLock)

BufferQueue模型是Renderchannel的一个先进先出的队列，Buffer实例可以被用在不同的线程之间，其同步原理是在创建的时候，传递了一个锁进去。其内部的buffer利用就是RenderChannel的buffer。对于队列的一些基本操作进行了相应的锁处理。

BufferQueue(size_t capacity, android::base::Lock& lock)

mCapacity(capacity), mBuffers(new Buffer[capacity]), mLock(lock) {}

这里只是简单地传递数据，确定buffer的大小，同时为其加锁。

对于Buffer的读写，这里提供了四个关键函数。

• tryWrite(Buffer&& buffer)

mFromGuest.tryPushLocked(std::move(buffer));

• tryRead(Buffer* buffer)

mToGuest.tryPopLocked(buffer);

• writeToGuest(Buffer&& buffer)

mToGuest.pushLocked(std::move(buffer));

• readFromGuest(Buffer* buffer, bool blocking)

mFromGuest.popLocked(buffer);

在服务器这一端，我们用的到的只有两个函数，这两个函数也是在ChannelStream中做了封装的，分别为

• commitBuffer(size_t size)

mChannel->writeToGuest(std::move(mWriteBuffer));

• readRaw(void* buf, size_t* inout_len)

mChannel->readFromGuest(&mReadBuffer, blocking);

通过write和read函数可以看出是对端在使用的，用来接收从我们的队列之中读数据。

由于Android模拟器端接受绘制渲染指令是通过Qemu Pipe来接收的，所以最开始接收到数据的位置则是管道服务，其实现在EmuglPipe中，在OpenglEsPipe文件中。

auto renderer = android_getOpenglesRenderer();

if (!renderer) {

D(“Trying to open the OpenGLES pipe without GPU emulation!”);

return nullptr;

}

EmuglPipe* pipe = new EmuglPipe(mHwPipe, this, renderer);

if (!pipe->mIsWorking) {

delete pipe;

pipe = nullptr;

}

return pipe;

获取一个Renderer也就是我们上面提到的用来进行指令转化在本地平台进行绘制的。然后创建一个EmuglPipe实例。

实例创建的构造函数

EmuglPipe(void* hwPipe, Service* service,

const emugl::RendererPtr& renderer)

AndroidPipe(hwPipe, service) {

mChannel = renderer->createRenderChannel();

if (!mChannel) {

D(“Failed to create an OpenGLES pipe channel!”);

return;

}

mIsWorking = true;

mChannel->setEventCallback([this](RenderChannel::State events) {this->onChannelHostEvent(events);});

}

到此回到了上面最初介绍的Render的createRenderChannel函数。

EmuglPipe提供了几个函数onGuestClose，onGuestPoll,onGuestRecv,onGuestSend等对于Guest读写的回调，当有数据到来或者要写回的时候调用，这个时候就会调用renderChannel来进行指令流的读写。

代码文档位置
const emugl::RendererPtr& renderer)

: AndroidPipe(hwPipe, service) {

mChannel = renderer->createRenderChannel();

if (!mChannel) {

D(“Failed to create an OpenGLES pipe channel!”);

return;

}

mIsWorking = true;

mChannel->setEventCallback([this](RenderChannel::State events) {this->onChannelHostEvent(events);});

}

到此回到了上面最初介绍的Render的createRenderChannel函数。

EmuglPipe提供了几个函数onGuestClose，onGuestPoll,onGuestRecv,onGuestSend等对于Guest读写的回调，当有数据到来或者要写回的时候调用，这个时候就会调用renderChannel来进行指令流的读写。

代码文档位置