Android模拟器绘制实现概述

时间 2019-12-01

原文原文链接

什么是QEMU

QEMU是一套模拟处理器的开源软件。它与Bochs，PearPC近似，但其具备某些后二者所不具有的特性，如高速度及跨平台的特性。QEMU能模拟整个电脑系统，包括中央处理器及其余周边设备。它使得为系统源代码进行测试及除错工做变得容易。其亦能用来在一部主机上虚拟数部不一样虚拟电脑。android

Google在开发Android系统的同时，使用qemu开发了针对每一个版本的一个模拟器，这大大下降了开发人员的开发成本，便于Android技术的推广。Google使用qemu模拟的是ARM926ej-S的Goldfish处理器，Goldfish是一种虚拟的ARM处理器，在Android的仿真环境中使用。Android模拟器经过运行它来运行arm926t指令集。bash

在Android源码的device文件下，咱们能够看到有各个厂商的名称，还有一个generic目录，上面提到Android中goldfish为咱们提供了对于底层硬件的虚拟化，因此对于指令的执行和硬件的操控，在程序执行的时候都会转交到这里来，在该目录下，能够看到有goldfish和goldfish-opengl，对于绘制相关的模拟在系统上层的调用中都会转移到这里。例如OpenGLES和gralloc的相关调用。在这里会对绘制指令进行编码，经过HostConnection来进行数据的传输，这里提供了一个HostConnetion类，这里提供了两种通讯方式，一个是QemuPipe，一个是TcpStream的方式进行传输。这里TcpStream实现存在问题，暂时不可以使用。到这里指令经过QemuPipe传输到模拟器。模拟器再将接收到的指令转化映射到相应的本地的绘制操做。服务器

模拟器和Android系统绘制

总体实现流程图socket

系统到模拟器

对于EGL，GLES1.1和GLES2.0的模拟这里会经过QEMU Pipe的方式传输到模拟器。在Android层中的实现，经过将上层的指令转化为一个通用的协议流，而后经过一个叫作QEMU PIPE的高速通道来进行传输，这个管道是经过内核驱动来实现，提供了高速的带宽，能够很是高效的进行读写。当数据经过流写入到设备文件中，而后驱动从中拿到数据以后。绘制指令协议流被模拟器读取以后。tcp

模拟器到RenderThread

模拟器接收到指令协议流以后并无作改变，直接将指令导到Render相关类。函数

Android模拟器的指令转化

Android模拟器实现多个转化的库，实现了上层的EGL，GLES。将相应的函数调用转化为正确的宿主机的桌面API调用。
GLX（Linux），AGL（OS X），WGL（Windows）。OpenGL 2.0来模拟GLES1.1，GLES2.0.工具

Android系统到模拟器

在Goldfish-openGL下提供了对于EGL，GLES1.1，GLES2.0的相应的编码类，对于其中实现的每个方法获取到当前gl_encoder_context持有的IOStream，来将数据写入到流之中来进行通讯。对于Android系统和模拟器之间的链接是经过HostConnection来实现的。其中的通讯实现采用的是QemuPipe。测试

Android模拟器实现了一种特殊的虚拟设备类来提供宿主系统和模拟器之间很是快速的通讯渠道。该种通道的打开链接方式。ui

首先打开/dev/qemu_pipe设备来进行读和写操做，从Linux3.10开始，设备被从新命名为/dev/goldfish_pipe，可是和以前的操做仍是同样的。this
提供一个零结尾的字符创描述咱们所要链接的服务。
而后经过简单的读写操做即可以和其进行通讯。

fd = open("/dev/qemu_pipe", O_RDWR);
const char* pipeName = "<pipename>";
 ret = write(fd, pipeName, strlen(pipeName)+1);
 if (ret < 0) {
   //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<RenderChannelImpl>();
   std::unique_ptr<RenderThread> 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> RenderThread::create(
        std::weak_ptr<RendererImpl> renderer,
        std::shared_ptr<RenderChannelImpl> channel) {
    return std::unique_ptr<RenderThread>(
            new RenderThread(renderer, channel));
}复制代码

RenderThread::RenderThread(std::weak_ptr<RendererImpl> renderer,
                           std::shared_ptr<RenderChannelImpl> 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<RenderChannelImpl> channel, size_t bufSize);复制代码

声明了如下变量

std::shared_ptr<RenderChannelImpl> 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来进行指令流的读写。

代码文档位置

设计文档

qemu/android/docs
android-emugl/DESIGN