Android Q Skia的繪製系統

和你一起終身學習，這裏是程序員 Android

經典好文推薦，通過閱讀本文，您將收穫以下知識點:

一、View的繪製機制
二、HWUI繪製架構
三、渲染設備Device
四、ImageView繪製
五、繪製時的幾何處理SkMatrix

Android Q渲染系統，最大的改動就是增加了skia的戲份，之前Android P繪製時，直接是在hwui中封裝一下，繪製封裝到op中，直接去調GPU實現了；現在在Android Q中，除了hwui中的封裝，在hwui中有個DisplayList外，在skia中再次封裝，在skia中還有一個GrOpList。

具體的細節，就讓我們一起來看看吧

一、View的繪製機制

首先我們來看看View的繪製機制吧！View的一個統稱。相信不少同學都自定義過View～我們自定義一個View，是不是都要去重寫onDraw方法，但是onDraw方法是什麼時候去調的呢！讓我們來看看吧！

我們來看看關鍵點：

編舞者Choreographer
主要處理DisplayEventReceiver接受到的Vsync信號，控制繪製的節拍，和底層的顯示進行同步！
ViewRootImpl
一個窗口中所有View的根，所有View都是按照數據結構Tree進行組織
ThreadedRenderer
線程化的渲染器，裏面會封裝渲染線程，硬件加速主要走這裏，早期沒有硬件加速走的drawSoftware，現在還保留只爲兼容！
一個View對應一個渲染節點RenderNode，充分體現了Tree結構的概念！
Canvas
俗稱畫布，提供什麼樣的畫布就具有什麼樣的能力，渲染的途徑就不一樣！

我們以ImageView的渲染爲例，看看其調用棧！

12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.graphics.BaseRecordingCanvas.drawBitmap(BaseRecordingCanvas.java:88)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.graphics.drawable.BitmapDrawable.draw(BitmapDrawable.java:548)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.widget.ImageView.onDraw(ImageView.java:1434)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at com.android.example.cropper.CropImageView.onDraw(CropImageView.java:167)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.View.draw(View.java:21594)
... ...
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4231)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.View.draw(View.java:21601)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at com.android.internal.policy.DecorView.draw(DecorView.java:831)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.View.updateDisplayListIfDirty(View.java:20437)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:575)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:581)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:654)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.ViewRootImpl.draw(ViewRootImpl.java:3828)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:3619)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2939)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1849)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8013)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.Choreographer$CallbackRecord.run(Choreographer.java:969)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.Choreographer.doCallbacks(Choreographer.java:793)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.Choreographer.doFrame(Choreographer.java:728)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:954)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.os.Handler.handleCallback(Handler.java:883)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.os.Handler.dispatchMessage(Handler.java:100)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.os.Looper.loop(Looper.java:224)
12-30 13:45:51.476 10246 26422 26422 E AndroidRuntime:  at android.app.ActivityThread.main(ActivityThread.java:7509)

這個棧裏我們隱藏掉了一部分View的Tree的調用！展示了從收到Vsync到開始繪製之間的調用流程！

二、HWUI繪製架構

之前，hwui中對繪製操作進行封裝後，直接送GPU進行渲染，通過OpenGL或Vulkan進行封裝！Q版本後，不一樣，都是通過skia進行封裝再通過OpenGL或Vulkan進行封裝，最後纔給到GPU渲染。

skia的作用用處，明顯加強了！
通過代碼分析，skia是通過靜態庫的形式被hwui引用的！

hwui的流程和之前的差別主要就體現在skia的二次封裝～我們來看看hwui的繪製流程！

SkiaOpenGLPipeline和SkiaVulkanPipeline兩個分別是對OpenGL和Vulkan的封裝！
skia的代碼分兩個部分，這個圖裏面的主要是hwui中的，還有一部分是skia獨立的靜態庫中！
skia有對應的結構和hwui匹配！

我們就簡單看一下SkiaCanvas的一個調用流程：

01-02 17:19:52.510 31741 32145 D xm-gfx-skia: SkCanvas: #00 pc 00000000002d9750  /system/lib64/libhwui.so (SkCanvas::init(sk_sp<SkBaseDevice>)+416)
01-02 17:19:52.510 31741 32145 D xm-gfx-skia: SkCanvas: #01 pc 00000000002d94d8  /system/lib64/libhwui.so (SkCanvas::SkCanvas(sk_sp<SkBaseDevice>)+192)
01-02 17:19:52.510 31741 32145 D xm-gfx-skia: SkCanvas: #02 pc 00000000002d9370  /system/lib64/libhwui.so (SkSurface_Gpu::onNewCanvas()+88)
01-02 17:19:52.510 31741 32145 D xm-gfx-skia: SkCanvas: #03 pc 00000000002770fc  /system/lib64/libhwui.so (SkSurface::getCanvas()+36)
01-02 17:19:52.510 31741 32145 D xm-gfx-skia: SkCanvas: #04 pc 0000000000276ee4  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaPipeline::tryCapture(SkSurface*)+48)
01-02 17:19:52.510 31741 32145 D xm-gfx-skia: SkCanvas: #05 pc 0000000000276be8  /system/lib64/libhwui.so (android::uirenderer::skiapipeline::SkiaPipeline::renderFrame(android::uirenderer::LayerUpdateQueue const&, SkRect const&, ... ...

繪製的操作，主要是在SkiaPipeline中進行的：

void SkiaPipeline::renderFrame(const LayerUpdateQueue& layers, const SkRect& clip,
                               const std::vector<sp<RenderNode>>& nodes, bool opaque,
                               const Rect& contentDrawBounds, sk_sp<SkSurface> surface,
                               const SkMatrix& preTransform) {
    bool previousSkpEnabled = Properties::skpCaptureEnabled;
    if (mPictureCapturedCallback) {
        Properties::skpCaptureEnabled = true;
    }

    // Initialize the canvas for the current frame, that might be a recording canvas if SKP
    // capture is enabled.
    SkCanvas* canvas = tryCapture(surface.get(), nodes[0].get(), layers);

    // draw all layers up front
    renderLayersImpl(layers, opaque);

    renderFrameImpl(clip, nodes, opaque, contentDrawBounds, canvas, preTransform);

    endCapture(surface.get());

    if (CC_UNLIKELY(Properties::debugOverdraw)) {
        renderOverdraw(clip, nodes, contentDrawBounds, surface, preTransform);
    }

    ATRACE_NAME("flush commands");
    surface->getCanvas()->flush();

    Properties::skpCaptureEnabled = previousSkpEnabled;
}

tryCapture截圖一樣的，一般不打開的，debug用
renderLayersImpl 把需要渲染的Layer先渲染掉前端
renderFrameImpl 後端，繪製到OpList。
flush這纔是真正的繪製到Buffer

三、渲染設備Device

skia定義了各種你繪製的設備Device，實現各自的繪製功能！我們來看看Device相關的類！

比較常用的SkBitmapDevice和SkGpuDevice～其他的是應用場景不太一樣！現在用SkGpuDevice比較多。

GPU相關的代碼位置：

external/skia/src/gpu

四、ImageView繪製

我們繼續來看ImageView的繪製！前面的棧調到了BaseRecordingCanvas.drawBitmap。Canvas本尊是SkiaRecordingCanvas。

Canvas* Canvas::create_recording_canvas(int width, int height, uirenderer::RenderNode* renderNode) {
    return new uirenderer::skiapipeline::SkiaRecordingCanvas(renderNode, width, height);
}

4.1 錄製操作

所以Java層的drawbitmap會調到SkiaRecordingCanvas中，我們就來看這個函數吧，從某個位置開始繪製一張Bitmap。

void SkiaRecordingCanvas::drawBitmap(Bitmap& bitmap, float left, float top, const Paint* paint) {
    sk_sp<SkImage> image = bitmap.makeImage();

    applyLooper(get_looper(paint), *filterBitmap(paint), [&](SkScalar x, SkScalar y, const SkPaint& p) {
        mRecorder.drawImage(image, left + x, top + y, &p, bitmap.palette());
    });

    // if image->unique() is true, then mRecorder.drawImage failed for some reason. It also means
    // it is not safe to store a raw SkImage pointer, because the image object will be destroyed
    // when this function ends.
    if (!bitmap.isImmutable() && image.get() && !image->unique()) {
        mDisplayList->mMutableImages.push_back(image.get());
    }
}

mRecorder是RecordingCanvas，fDL是DisplayListData的對象。

void RecordingCanvas::drawImage(const sk_sp<SkImage>& image, SkScalar x, SkScalar y,
                                const SkPaint* paint, BitmapPalette palette) {
    fDL->drawImage(image, x, y, paint, palette);
}

最終，ImageView的繪製將被轉換爲DrawImage！

void DisplayListData::drawImage(sk_sp<const SkImage> image, SkScalar x, SkScalar y,
                                const SkPaint* paint, BitmapPalette palette) {
    this->push<DrawImage>(0, std::move(image), x, y, paint, palette);
}

這個push函數中，實現了我們對應的繪製操作Op是怎麼存儲的～看看吧～

template <typename T, typename... Args>
void* DisplayListData::push(size_t pod, Args&&... args) {
    size_t skip = SkAlignPtr(sizeof(T) + pod);
    SkASSERT(skip < (1 << 24));
    if (fUsed + skip > fReserved) {
        static_assert(SkIsPow2(SKLITEDL_PAGE), "This math needs updating for non-pow2.");
        // Next greater multiple of SKLITEDL_PAGE.
        fReserved = (fUsed + skip + SKLITEDL_PAGE) & ~(SKLITEDL_PAGE - 1);
        fBytes.realloc(fReserved);
    }
    SkASSERT(fUsed + skip <= fReserved);
    auto op = (T*)(fBytes.get() + fUsed);
    fUsed += skip;
    new (op) T{std::forward<Args>(args)...};
    op->type = (uint32_t)T::kType;
    op->skip = skip;
    return op + 1;
}

基地址fBytes，是該DisplayListData開始存儲Op的地址，採用預分配，後續不斷擴展。
fUsed，分配的內存使用了多少。
skip新增加的Op佔用的內存大小。
注意這裏的auto op = (T*)(fBytes.get() + fUsed);在從該地址，強轉一個T對象。
注意這種法new (op) T{std::forward<Args>(args)...};構建對應的op，op的地址是前面強轉的。

Op的定義：

struct Op {
    uint32_t type : 8;
    uint32_t skip : 24;
};

type表示改Op是什麼類型，skip表示大小！
DrawImage的類型是Type::DrawImage
從Op派生的具體的Op，實現draw方法，完成改Op的真正繪製。

到目前爲止，繪製ImageView的操作被轉換成了DrawImage繪製操作，保存到了DisplayListData中！沒有繼續動作！

4.1 渲染繪製操作Op

2020年一切都要從一隻蝙蝠說起，但是我們這裏Op的渲染一切都要從HardwareRenderer的syncAndDrawFrame說起，之前P上的HUWI穩定已經說過了，是在DrawFrameTask中實現的。

這裏纔會調到CanvasContext中的prepareTree和draw。

prepareTree 將前面已經錄製好的DisplayListData的數據，根據damage，傳到了mLayerUpdateQueue中
draw去繪製mLayerUpdateQueue中拿到的數據，這就到了前面說的SkiaPipeline::renderFrame函數中。

最後到DisplayListData中，

void DisplayListData::draw(SkCanvas* canvas) const {
    SkAutoCanvasRestore acr(canvas, false);
    this->map(draw_fns, canvas, canvas->getTotalMatrix());
}

map函數：

template <typename Fn, typename... Args>
inline void DisplayListData::map(const Fn fns[], Args... args) const {
    auto end = fBytes.get() + fUsed;
    for (const uint8_t* ptr = fBytes.get(); ptr < end;) {
        auto op = (const Op*)ptr;
        auto type = op->type;
        auto skip = op->skip;
        if (auto fn = fns[type]) {  // We replace no-op functions with nullptrs
            fn(op, args...);        // to avoid the overhead of a pointless call.
        }
        ptr += skip;
    }
}

根據type，去找對對應的Fn，並執行！

#define X(T)                                                    \
    [](const void* op, SkCanvas* c, const SkMatrix& original) { \
        ((const T*)op)->draw(c, original);                      \
    },
static const draw_fn draw_fns[] = {
#include "DisplayListOps.in"
};
#undef X

執行對應的T的draw函數！我們ImageView之前轉換爲了DrawImage.

struct DrawImage final : Op {
    static const auto kType = Type::DrawImage;
    DrawImage(sk_sp<const SkImage>&& image, SkScalar x, SkScalar y, const SkPaint* paint,
              BitmapPalette palette)
            : image(std::move(image)), x(x), y(y), palette(palette) {
        if (paint) {
            this->paint = *paint;
        }
    }
    sk_sp<const SkImage> image;
    SkScalar x, y;
    SkPaint paint;
    BitmapPalette palette;
    void draw(SkCanvas* c, const SkMatrix&) const { c->drawImage(image.get(), x, y, &paint); }
};

裏面的drawImage是Canvas的！

void SkCanvas::drawImage(const SkImage* image, SkScalar x, SkScalar y, const SkPaint* paint) {
    TRACE_EVENT0("skia", TRACE_FUNC);
    RETURN_ON_NULL(image);
    this->onDrawImage(image, x, y, paint);
}

Ok！到這裏onDrawImage方法中，就要區分到具體的Device了。

4.3 skia處理

這裏我們用一個棧來開始，drawImage將會被以紋理的形式提供給GPU進行處理，這裏是中間的流程。

01-03 17:37:41.895 20612 20680 D GrGLGpu: #00 pc 00257b89  /system/lib/libhwui.so (GrGLGpu::onCreateTexture(GrSurfaceDesc const&, SkBudgeted, GrMipLevel const*, int)+88)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #01 pc 0024532f  /system/lib/libhwui.so (GrGpu::createTexture(GrSurfaceDesc const&, SkBudgeted, GrMipLevel const*, int)+126)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #02 pc 0023abbb  /system/lib/libhwui.so (GrResourceProvider::createTexture(GrSurfaceDesc const&, SkBudgeted, GrResourceProvider::Flags)+86)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #03 pc 0023a8fb  /system/lib/libhwui.so (GrResourceProvider::createTexture(GrSurfaceDesc const&, SkBudgeted, SkBackingFit, GrMipLevel const&, GrResourceProvider::Flags)+110)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #04 pc 0023a795  /system/lib/libhwui.so (_ZNSt3__110__function6__funcIZN15GrProxyProvider18createTextureProxyE5sk_spI7SkImageE14GrSurfaceFlagsi10SkBudgeted12SkBackingFit22GrInternalSurfaceFlagsE3$_0NS_9allocatorISA_EEFS3_I9GrSurfaceEP18GrResourceProviderEEclEOSG_$955cb6000423a36286866a405c65dcb6+84)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #05 pc 001b907f  /system/lib/libhwui.so (GrSurfaceProxyPriv::doLazyInstantiation(GrResourceProvider*)+70)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #06 pc 0026ebe7  /system/lib/libhwui.so (GrProxyProvider::createTextureProxy(sk_sp<SkImage>, GrSurfaceFlags, int, SkBudgeted, SkBackingFit, GrInternalSurfaceFlags)+762)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #07 pc 0026e84d  /system/lib/libhwui.so (GrUploadBitmapToTextureProxy(GrProxyProvider*, SkBitmap const&)+132)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #08 pc 0012ba95  /system/lib/libhwui.so (GrBitmapTextureMaker::refOriginalTextureProxy(bool, GrTextureMaker::AllowedTexGenType)+184)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #09 pc 001e6c19  /system/lib/libhwui.so (GrTextureMaker::onRefTextureProxyForParams(GrSamplerState const&, bool, float*)+104)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #10 pc 001c586f  /system/lib/libhwui.so (GrTextureProducer::refTextureProxyForParams(GrSamplerState const&, float*)+34)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #11 pc 00393011  /system/lib/libhwui.so (_ZN12_GLOBAL__N_121draw_texture_producerEP9GrContextP21GrRenderTargetContextRK6GrClipRK8SkMatrixRK7SkPaintP17GrTextureProducerRK6SkRectSH_PK7SkPointS9_4GrAA13GrQuadAAFlagsN8SkCanvas17SrcRectConstraintEb.llvm.12141512145445924752+112)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #12 pc 00391e5d  /system/lib/libhwui.so (SkGpuDevice::drawImageQuad(SkImage const*, SkRect const*, SkRect const*, SkPoint const*, GrAA, GrQuadAAFlags, SkMatrix const*, SkPaint const&, SkCanvas::SrcRectConstraint)+3404)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #13 pc 00132a29  /system/lib/libhwui.so (SkGpuDevice::drawImageRect(SkImage const*, SkRect const*, SkRect const&, SkPaint const&, SkCanvas::SrcRectConstraint)+108)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #14 pc 001e254d  /system/lib/libhwui.so (SkCanvas::onDrawImage(SkImage const*, float, float, SkPaint const*)+540)
01-03 17:37:41.895 20612 20680 D GrGLGpu: #15 pc 0027a18b  /system/lib/libhwui.so (SkCanvas::drawImage(SkImage const*, float, float, SkPaint const*)+138)

drawImage在skia中，以紋理方式處理，還會被二次封裝，封裝爲GPU的Op TextureOp。

void GrRenderTargetContext::drawTexturedQuad(const GrClip& clip,
                                             GrSurfaceProxyView proxyView,
                                             SkAlphaType srcAlphaType,
                                             sk_sp<GrColorSpaceXform> textureXform,
                                             GrSamplerState::Filter filter,
                                             const SkPMColor4f& color,
                                             SkBlendMode blendMode,
                                             GrAA aa,
                                             DrawQuad* quad,
                                             const SkRect* domain) {
    ... ...
    if (opt != QuadOptimization::kDiscarded) {
        ... ...
        this->addDrawOp(finalClip,
                        GrTextureOp::Make(fContext, std::move(proxyView), srcAlphaType,
                                          std::move(textureXform), filter, color, saturate,
                                          blendMode, aaType, quad, domain));
    }
}

最後被添加到GrOpsTask中：

    void addDrawOp(std::unique_ptr<GrDrawOp> op, const GrProcessorSet::Analysis& processorAnalysis,
                   GrAppliedClip&& clip, const DstProxyView& dstProxyView,
                   GrTextureResolveManager textureResolveManager, const GrCaps& caps) {
        auto addDependency = [ textureResolveManager, &caps, this ] (
                GrSurfaceProxy* p, GrMipMapped mipmapped) {
            this->addSampledTexture(p);
            this->addDependency(p, mipmapped, textureResolveManager, caps);
        };

        op->visitProxies(addDependency);
        clip.visitProxies(addDependency);
        if (dstProxyView.proxy()) {
            this->addSampledTexture(dstProxyView.proxy());
            addDependency(dstProxyView.proxy(), GrMipMapped::kNo);
        }

        this->recordOp(std::move(op), processorAnalysis, clip.doesClip() ? &clip : nullptr,
                       &dstProxyView, caps);
    }

在recordOp中將被添加到fOpChains中，一個SkSTArray的數據結構！

4.4 GPU處理

真正去處理繪製是在flush函數中：

void SkiaPipeline::renderFrame(const LayerUpdateQueue& layers, const SkRect& clip,
                               const std::vector<sp<RenderNode>>& nodes, bool opaque,
                               const Rect& contentDrawBounds, sk_sp<SkSurface> surface,
                               const SkMatrix& preTransform) {
        ... ...
    renderFrameImpl(clip, nodes, opaque, contentDrawBounds, canvas, preTransform);
    ... ...
    surface->getCanvas()->flush();

    Properties::skpCaptureEnabled = previousSkpEnabled;
}

TextureOp的處理是在onExecute函數中：

    void onExecute(GrOpFlushState* flushState, const SkRect& chainBounds) override {
        auto pipelineFlags = (GrAAType::kMSAA == fMetadata.aaType())
                ? GrPipeline::InputFlags::kHWAntialias
                : GrPipeline::InputFlags::kNone;

        auto pipeline = GrSimpleMeshDrawOpHelper::CreatePipeline(flushState,
                                                                 GrProcessorSet::MakeEmptySet(),
                                                                 pipelineFlags);

        flushState->executeDrawsAndUploadsForMeshDrawOp(this, chainBounds, pipeline);
    }

TextureOp在flush時，Texture將被gpu使用：

01-06 16:32:47.839 19995 20045 D GrGLGpu: #00 pc 001cc4af  /system/lib/libhwui.so (GrGLGpu::bindTexture(int, GrSamplerState, GrGLTexture*)+46)
01-06 16:32:47.839 19995 20045 D GrGLGpu: #01 pc 001c9fa1  /system/lib/libhwui.so (GrGLProgram::updatePrimitiveProcessorTextureBindings(GrPrimitiveProcessor const&, GrTextureProxy const* const*)+68)
01-06 16:32:47.839 19995 20045 D GrGLGpu: #02 pc 001c8f67  /system/lib/libhwui.so (GrGLGpu::draw(GrRenderTarget*, GrSurfaceOrigin, GrPrimitiveProcessor const&, GrPipeline const&, GrPipeline::FixedDynamicState const*, GrPipeline::DynamicStateArrays const*, GrMesh const*, int)+542)
01-06 16:32:47.839 19995 20045 D GrGLGpu: #03 pc 001c8d3f  /system/lib/libhwui.so (GrGLGpuRTCommandBuffer::onDraw(GrPrimitiveProcessor const&, GrPipeline const&, GrPipeline::FixedDynamicState const*, GrPipeline::DynamicStateArrays const*, GrMesh const*, int, SkRect const&)+30)
01-06 16:32:47.839 19995 20045 D GrGLGpu: #04 pc 0018ab83  /system/lib/libhwui.so (GrGpuRTCommandBuffer::draw(GrPrimitiveProcessor const&, GrPipeline const&, GrPipeline::FixedDynamicState const*, GrPipeline::DynamicStateArrays const*, GrMesh const*, int, SkRect const&)+166)
01-06 16:32:47.839 19995 20045 D GrGLGpu: #05 pc 0018a8e3  /system/lib/libhwui.so (GrOpFlushState::executeDrawsAndUploadsForMeshDrawOp(GrOp const*, SkRect const&, GrProcessorSet&&, unsigned int, GrUserStencilSettings const*)+310)
01-06 16:32:47.839 19995 20045 D GrGLGpu: #06 pc 003de943  /system/lib/libhwui.so (_ZN12_GLOBAL__N_19TextureOp9onExecuteEP14GrOpFlushStateRK6SkRect$ab67424b01b2ae857b75443a16f18610+66)
01-06 16:32:47.839 19995 20045 D GrGLGpu: #07 pc 001b8cef  /system/lib/libhwui.so (GrOp::execute(GrOpFlushState*, SkRect const&)+50)
01-06 16:32:47.839 19995 20045 D GrGLGpu: #08 pc 001b8b4f  /system/lib/libhwui.so (GrRenderTargetOpList::onExecute(GrOpFlushState*)+282)
01-06 16:32:47.840 19995 20045 D GrGLGpu: #09 pc 001fce6b  /system/lib/libhwui.so (GrDrawingManager::flush(GrSurfaceProxy*, SkSurface::BackendSurfaceAccess, GrFlushFlags, int, GrBackendSemaphore*, void (*)(void*), void*)+1086)
01-06 16:32:47.840 19995 20045 D GrGLGpu: #10 pc 001fc9a1  /system/lib/libhwui.so (GrDrawingManager::prepareSurfaceForExternalIO(GrSurfaceProxy*, SkSurface::BackendSurfaceAccess, GrFlushFlags, int, GrBackendSemaphore*, void (*)(void*), void*)+128)
01-06 16:32:47.840 19995 20045 D GrGLGpu: #11 pc 001fc86b  /system/lib/libhwui.so (GrRenderTargetContext::prepareForExternalIO(SkSurface::BackendSurfaceAccess, GrFlushFlags, int, GrBackendSemaphore*, void (*)(void*), void*)+86)
01-06 16:32:47.840 19995 20045 D GrGLGpu: #12 pc 001fc80b  /system/lib/libhwui.so (SkGpuDevice::flush()+22)

Texture的GPU處理集中在GrGLGpu的bindTexture函數中。！

整個繪製的操作是在GrGLGpu::draw中完成的。sendToGpu將調調到sendIndexedMeshToGpu函數中，OpenGLES的glDrawElements。

紋理的操作，可以看我的另外一篇博文OpenGLES 純Native實現PNG圖片貼圖

4.5 GL_CALL和GPU

GL_CALL是一個宏定義

#define GL_CALL(X) GR_GL_CALL(this->glGpu()->glInterface(), X)

這是對OpenGLES的封裝，在hwui的Pipeline中，去決定用到什麼interface。

RenderThread::requireGlContext()
RenderThread::requireVkContext()

五、繪製時的幾何處理SkMatrix

繪製時的旋轉，縮放，偏移等，其實現是通過SkMatrix來實現的。我們可能沒有關注過，但是我們的圖片被怎麼樣繪製，繪製在什麼地方，跟SkMatrix的關係很大。
舉個例子，我們一張圖片，將被創建爲對應的Texture，但是很有可能這個圖片只是顯示在屏幕上的一塊很小的區域。這就需要在SkMatrix中設置對應的參數進行縮放了。

這是SkMatrix中各個參數的含義：

| scaleX  skewX transX |
|  skewY scaleY transY |
|  pers0  pers1  pers2 |

我們來看看都有什麼處理：

縮放：scaleX，scaleY分別是水平豎直兩個方向上的縮放。1.0f是原始大小！
偏移：transX，transY分別是水平豎直兩個方向上的偏移。0.0f是原始位置！
傾斜：skewX，skewY分別是水平豎直兩個方向上的偏移。0.0f是原始位置！
透視：perspective， pers0，pers1分別表示透視的座標xy，pers2表示縮放因子。
旋轉：直接通過setRotate函數設置旋轉角度!

我們來通過一張圖，粗類的認識一下這些操作。

需要注意的是，有些操作是互斥的，不能同時進行！

怎麼區分呢，SkMatrix通過typeMask來區分！

    enum TypeMask {
        kIdentity_Mask    = 0,    //!< identity SkMatrix; all bits clear
        kTranslate_Mask   = 0x01, //!< translation SkMatrix
        kScale_Mask       = 0x02, //!< scale SkMatrix
        kAffine_Mask      = 0x04, //!< skew or rotate SkMatrix
        kPerspective_Mask = 0x08, //!< perspective SkMatrix
    };

小結

本文主要是從ImageView的繪製入手，分析了一個目前Android Q中的一個繪製流程，有點虎頭蛇尾，後續再完善一下吧！

參考鏈接：https://www.jianshu.com/p/198701520cd7

至此，本篇已結束。轉載網絡的文章，小編覺得很優秀，歡迎點擊閱讀原文，支持原創作者，如有侵權，懇請聯繫小編刪除，歡迎您的建議與指正。同時期待您的關注，感謝您的閱讀，謝謝！

Android Q Skia的繪製系統

和你一起終身學習，這裏是程序員 Android

一、View的繪製機制

二、HWUI繪製架構

三、渲染設備Device

四、ImageView繪製

4.1 錄製操作

4.1 渲染繪製操作Op

4.3 skia處理

4.4 GPU處理

4.5 GL_CALL和GPU

五、繪製時的幾何處理SkMatrix

小結

高通相機bringup guide

MTK 人像雙攝虛化導通guide

MTK 相機功耗問題學習筆記

MTK 平臺相機bringup點亮

C語言測試題舉例

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結