Skia深入分析2——skia渲染架构

版权声明：本文为博主原创文章，转载请注明出处：http://blog.csdn.net/jxt1234and2010

一、渲染层级

从渲染流程上分，Skia可分为如下三个层级：

1、指令层：SkPicture、SkDeferredCanvas->SkCanvas

这一层决定需要执行哪些绘图操作，绘图操作的预变换矩阵，当前裁剪区域，绘图操作产生在哪些layer上，Layer的生成与合并。

2、解析层：SkBitmapDevice->SkDraw->SkScan、SkDraw1Glyph::Proc

这一层决定绘制方式，完成坐标变换，解析出需要绘制的形体（点/线/规整矩形）并做好抗锯齿处理，进行相关资源解析并设置好Shader。

3、渲染层：SkBlitter->SkBlitRow::Proc、SkShader::shadeSpan等

这一层进行采样（如果需要），产生实际的绘制效果，完成颜色格式适配，进行透明度混合和抖动处理（如果需要）。



二、主要类介绍
1、SkCanvas

这是复杂度超出想像的一个类。

（1）API设计

a、创建：

在Android中，主要的创建方法是由SkBitmap创建SkCanvas：

explicit SkCanvas(const SkBitmap& bitmap);

这个方法是由bitmap创建一个SkBitmapDevice，再将这个SkBitmapDevice设定为SkCanvas的渲染目标。

5.0之后提供了一个快捷方法创建SkCanvas：

static SkCanvas* NewRasterDirect(const SkImageInfo&, void*, size_t);

这样Android的GraphicBuffer就不需要建一个SkBitmap和它关联了，可以解除SkBitmap类和android runtime的关系（虽然如此，目前Android5.0上，还是按建SkBitmap的方法去关联GraphicBuffer）。

5.0之后引入的离屏渲染：

static SkCanvas* NewRaster(const SkImageInfo&);

创建一个SkCanvas，绘制的内容需要通过readPixels去读取，仍然是CPU绘图的方式。（个人觉得这个是转入GPU硬件加速的一个比较方便的接口，不知道出于什么考虑还是用CPU绘图。）

b、状态：

矩阵状态：

矩阵决定当前绘制的几何变换

rotate、skew、scale、translate、concat

裁剪状态：

裁剪决定当前绘制的生效范围

clipRect、clipRRect、clipPath、clipRegion

保存与恢复：

save、saveLayer、saveLayerAlpha、restore

c、渲染：

大部分渲染的API都可由这三个组合而成：

drawRect（矩形/图像绘制）、drawPath（不规则图形图像绘制）和drawText（文本绘制）

d、像素的读取与写入

readPixels、writePixels

这两个API主要由device实现，考虑到不同绘图设备的异质性。

（2）MCRec状态栈

fMCStack是存储的全部状态集，fMCRec则是当前的状态。

在 save saveLayer saveLayerAlpha 时，会新建一个MCRec，在restore时，销毁栈顶的MCRec。

（代码见：SkCanvas.cpp internalSave函数，通过这段代码可以了解一下new的各种用法～。）

每个状态包括如下信息：

class SkCanvas::MCRec {

public:

    int             fFlags;//保存的状态标识（是否保存矩阵/裁剪/图层）

    SkMatrix*       fMatrix;//矩阵指针，若这个状态有独立矩阵，则指向内存（fMatrixStorage），否则用上一个MCRec的fMatrix

    SkRasterClip*   fRasterClip;//裁剪区域，若这个状态有独立裁剪区域，则指向内存（fRasterClip），否则继承上一个的。

    SkDrawFilter*   fFilter;

    DeviceCM* fLayer;//这个状态所拥有的layer（需要在此MCRec销毁时回收）

    DeviceCM* fTopLayer;//这个状态下，所需要绘制的Layer链表。（这些Layer不一定属于此状态）

    ......

};

DeviceCM：图层链表，包装一个SkBaseDevice，附加一个位置偏移变化的矩阵（在saveLayer时指定的坐标）。

（3）两重循环绘制

研究Skia的人，一般来说都会被一开始的两重循环弄晕一会，比如drawRect的代码：

    LOOPER_BEGIN(paint, SkDrawFilter::kRect_Type, bounds)

    while (iter.next()) {

        iter.fDevice->drawRect(iter, r, looper.paint());

    }

    LOOPER_END

先完全展开上面的代码：

AutoDrawLooper  looper(this, paint, false, bounds);

while (looper.next(type)) {

    SkDrawIter          iter(this);

    while (iter.next()) {

        iter.fDevice->drawRect(iter, r, looper.paint());

    }

}

第一重循环即 AutoDrawLooper，这个next实际上是做一个后处理，在存在 SkImageFilter 的情况下，先渲染到临时Layer上，再将这个Layer做Filter处理后画到当前device上。

第二重循环是SkDrawIter，这个是绘制当前状态所依附的所有Layer。

一般情况下，这两重循环都可以忽略，单纯当它是走下流程就好了。

个人认为Skia在绘制入口SkCanvas的设计并不是很好，图层、矩阵与裁剪存在一起，导致渲染任务难以剥离，后面GPU渲染和延迟渲染的引入都让人感到有些生硬。

2、SkDraw、SkBlitter

这两个类在后续章节还会提到，这里只简单介绍：

SkDraw是CPU绘图的实现入口，主要任务是做渲染准备（形状确定、几何变换、字体解析、构建图像Shader等）。

SkBlitter 不是单独的一个类，指代了一系列根据图像格式、是否包含Shader等区分出来的一系列子类。

这一族类执行大块头的渲染任务，把像素绘制上去。

三、渲染框架设计思想分析

1、指令层与实现层分离

SkCanvas不直接执行渲染，由SkBaseDevice根据设备类型，选择渲染方法。这样虽然是同一套API，但可以用作GPU绘图、pdf绘制、存储显示列表等各种功能。在API集上做优化，避免冗余绘制，也因此成为可能（注：这个google虽然在尝试，但目前看来没有明显效果，实现起来确实也很困难）。

2、图=形+色的设计思想

由SkDraw和SkScan类中控制绘制的形，由SkBlitter和SkShader控制绘制的色，将绘图操作分解为形状与色彩两部分，这一点和OpenGL的顶点变换——光栅——片断着色管线相似，非常有利于扩展，各种2D图元的绘制基本上就完全支持了。

3、性能调优集中化

将耗时的函数抽象都抽象为proc，由一个工厂制造，便于集中对这一系列函数做优化。

下面三章分别讲bitmap、path和text的绘制方法

着重点分别如下：

bitmap：shader及采样原理，混合计算原理，多格式支持方法

path：不规则图形的绘制方式

text：文本解析方法，cache管理