软件绘制源码流程分析

精选原创

北洋洋洋 2022-10-20 21:54:59 博主文章分类：Android ©著作权

©著作权归作者所有：来自51CTO博客作者北洋洋洋的原创作品，请联系作者获取转载授权，否则将追究法律责任

引言：之前的文章中提到过软件绘制是会调用drawSoftware方法进行绘制的。在这个方法里面调用了Surface.lockCanvas和unlockAndPost方法。这篇文章就分析这两个方法

Surface.lockCanvas

大致流程：

调用surface的lockcanvas方法获取到Canvas。native层拿到surface对象通过lock方法获取到ANativieWindowBuffer，然后创建C层的Skiacanvas对象与Java层的关联起来，最后创建新的surface对象给到java层。

// 得到c层的 surface 对象    
sp<Surface> surface(reinterpret_cast<Surface *>(nativeObject));
//声明 buffer
ANativeWindow_Buffer buffer;
// 获取GraphicBuffer 
status_t err = surface->lock(&buffer, dirtyRectPtr);

// 创建 c层的SkiaCanvas对象,并且与java层的绑定
graphics::Canvas canvas(env, canvasObj);
// 设置buffer绑定到ANativeWindow_Buffer的bits结构中
canvas.setBuffer(&buffer, static_cast<int32_t>(surface->getBuffersDataSpace()));

Surface.lock

lock方法中首先声明NativeWindowBuffer对象，然后调用dequeBuffe获取到ANativeWindwoBuffer对象接着请求SF真正创建GraphBuffer对象并返回NativeWindowBuffer

 // 声明 ANativeWindowBuffer 对象
    ANativeWindowBuffer* out;
    
    //1  调用dequeueBuffer获取 ANativeWindowBuffer 对象
    status_t err = dequeueBuffer(&out, &fenceFd);
    // 2 创建GraphicBuffer 对象
    sp<GraphicBuffer> backBuffer(GraphicBuffer::getSelf(out));
    //3.返回dequeueBuffer获取的ANativeWindowBuffer 对象
    return err;

请求SF进程获取GraphBuffer

c层的surface对象调用lock方法传入ANatieWindow_Buffer，这块Buffer记录着lock方法返回的GraphBuffer绘制内存地址，绘制区域大小坐标等信息, ANatieWindow_Buffer内部变量bits用于之后和SkiaCanvas绑定用于直接渲染。

dequeneBuffer

// 从共享的位置mSharedBufferSlot，拿出GraphicBuffer
sp<GraphicBuffer>& gbuf(mSlots[mSharedBufferSlot].buffer);
int buf = -1; //mSlots中对应的下标，需下一步 dequeneSF进程分配

// 跨进程 从SF进程的mSlots数组(BufferQueue)中分配一块 GraphicBuffer
    status_t result = mGraphicBufferProducer->dequeueBuffer(
    &buf, &fence, dqInput.width,
    dqInput.height, dqInput.format,
    dqInput.usage, &mBufferAge,
    dqInput.getTimestamps ?
     &frameTimestamps : nullptr);
// 得到GraphicBuffer
sp<GraphicBuffer>& gbuf(mSlots[buf].buffer);
//请求 buffer
result = mGraphicBufferProducer->requestBuffer(buf, &gbuf);

请求SF进程返回一个下标对应Slots中的位置，Slots才是SF中真正的GraphBuffer。然后把这个slot位置发送给SF返回真正可以用的Buffer空间，但是此时还并没有分配内存；当调用GraphBufferProducer对象的requestBuffer方法时将SF返回的那块SF中slots内存空间和对应的下标slot传入参数调用时就可以真正的请求分配对应mSlot位置的GraphBuffer内存空间。

dequeBuffer主要是跨进程到SF中获取真正存储缓存区的mSlots中可以用的下标（空闲），然后app利用这个下标像SF申请一块空间只不过还没有创建，接着APP使用producer的request真正申请一块内存

在Surface中有成员变量 mSlots来存储获取到的GraphicBuffer对象。GraphicBuffer就是表示内存缓冲区。而与之对应的在SF进程中的 BufferQueueProducer.cpp中也有对应mSlots数组。内部就存储着GraphicBuffer内存缓冲区。真正分配内存是在SF进程中完成的。App进程只是映射到了对应的内存。

由于APP进程与SF进程通过匿名共享内存来实现共享GraphicBuffer缓冲区。因此，app进程只要通过 mGraphicBufferProducer就能把数据写入到SF进程提供的GraphicBuffer内存空间中。

获取canvas

创建canvas对象，canvas的构造方法中表示native层没有bitamp不占内存，空画布，然后调用createCanvas方法返回来一个SkiaCanvas对象，内部通过SKiaBitmap承载绘制内容

Java层的Canvas对应native层的 SkiaCanvas 对象。内部通过 SKBitmap 来承载绘制内容。

  //获取SkiaBitmap绑定到上面ANativeWindowBuffer中的bits属性中
  if (surface.get() != nullptr) {
        if (outBitmap) {
            outBitmap->setInfo(imageInfo, rowBytes);
            
            // 关键： 将bits指针设置给SKBitmap
            outBitmap->setPixels(buffer->bits);
        }
        return true;

绑定SkiaBitmap到Buffer中的bits属性

Skiavas对象的mCanvas获取到SKBitmap对象然后和ANativeWindowBuffer的bits指针绑定，也就是SKBitmap指向了分配好的内存空间

然后Java层的canvas对应的是Native层的SkiaCanvas绑定。之后就可以对这块GraphBuffer进行绘制了，因为APP的GraphBufer映射的是SF进程中mSlots的位置所以是匿名共享内存没有交换时间（硬件绘制需要转换为OP树同步至RenderThread）

unLockAndPost

 // 设置一个空的bitmap，释放canvas的画布SKBitmap。也就是说此时SKBitmap不在引用到buffer了。
 nativeCanvas->setBitmap(SkBitmap());
status_t err = mLockedBuffer->unlockAsync(&fd); //解除buffer的绑定
 // 加入队列 
err = queueBuffer(mLockedBuffer.get(), fd);