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

一、渲染层级
从渲染流程上分，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管理

版权声明：本文为博主原创文章，未经博主允许不得转载。