hwui opengl VS skia opengl VS skia vulkan?

之前討論過skia codec部分在o,p上的變化，比如增加了heif解碼等。
其實skia在android o,p的變化不只這些。

印象最深刻的還是渲染部分

從o開始hwui渲染支持skia opengl，原來hwui只支持opengl渲染，只不過在o裏，skia opengl是可選的方式，默認還是opengl，但在p上已經默認採用skia opengl了，而且去掉了選擇。

Android o上的選項

Android O上相關的代碼

/**

 * Defines the rendering pipeline to be used by the ThreadedRenderer.
 *
 * Possible values:
 * "opengl", will use the existing OpenGL renderer
 * "skiagl", will use Skia's OpenGL renderer
 * "skiavk", will use Skia's Vulkan renderer
 *
 * @hide
 */
public static final String DEBUG_RENDERER_PROPERTY = "debug.hwui.renderer";

上邊定義了可選的幾個選項，是不是看到了vulkan，看來android早有打算

Readback& RenderThread::readback() {

if (!mReadback) {
    auto renderType = Properties::getRenderPipelineType();
    switch (renderType) {
        case RenderPipelineType::OpenGL:
            mReadback = new OpenGLReadbackImpl(*this);
            break;
        case RenderPipelineType::SkiaGL:
        case RenderPipelineType::SkiaVulkan:
            // It works to use the OpenGL pipeline for Vulkan but this is not
            // ideal as it causes us to create an OpenGL context in addition
            // to the Vulkan one.
            mReadback = new skiapipeline::SkiaOpenGLReadback(*this);
            break;
        default:
            LOG_ALWAYS_FATAL("canvas context type %d not supported", (int32_t) renderType);
            break;
    }
}
return *mReadback;

}
同樣看到了vulkan，以及相關代碼，但是並沒有啓動，應該還沒有實現好

Android P上的代碼

Readback& RenderThread::readback() {

if (!mReadback) {
    auto renderType = Properties::getRenderPipelineType();
    switch (renderType) {
        case RenderPipelineType::OpenGL:
            mReadback = new OpenGLReadbackImpl(*this);
            break;
        case RenderPipelineType::SkiaGL:
            mReadback = new skiapipeline::SkiaOpenGLReadback(*this);
            break;
        case RenderPipelineType::SkiaVulkan:
            mReadback = new skiapipeline::SkiaVulkanReadback(*this);
            break;
        default:
            LOG_ALWAYS_FATAL("canvas context type %d not supported", (int32_t)renderType);
            break;
    }
}
return *mReadback;

}
看上去p上hwui已經開始支持vulkan了

class SkiaVulkanReadback : public Readback {
public:

SkiaVulkanReadback(renderthread::RenderThread& thread) : Readback(thread) {}
virtual CopyResult copySurfaceInto(Surface& surface, const Rect& srcRect,
        SkBitmap* bitmap) override {
    //TODO: implement Vulkan readback.
    return CopyResult::UnknownError;
}
virtual CopyResult copyGraphicBufferInto(GraphicBuffer* graphicBuffer,
        SkBitmap* bitmap) override {
    //TODO: implement Vulkan readback.
    return CopyResult::UnknownError;
}

但看代碼實際上還是未啓用狀態可能有很多問題還沒解決

效率問題

skia opengl會比opengl快嗎？

網上很多人都表示skia opengl比opengl快，但是從實現的角度上講核心沒有不同，不同的可能是模塊代碼結構流程，並沒有實質的提升，更不會出現能從使用者的角度觀察到變化。因此做了一個實驗，在60fps的一個場景下對opengl和skia opengl的gl繪製耗時做了一個對比。
OpenGL

OpenGL skia

draw: display list繪製信息
prepare: 同步時間
Process: gl繪製時間
Execute: swapbuffer時間

從上邊的數據可以看到兩種方式process的時間基本沒有差別，而且整體渲染的時間也不相上下。所以從實驗角度也不存在誰比誰更快。
而且兩個cpu使用情況也基本相同。沒什麼差別。

真正的提升應該是在vulkan實現之後

arm官方和提供了一些測試數據表明無論從性能還是功耗上都比opengl es有很大提升。如下鏈接有些可能需要翻牆。
https://community.arm.com/gra...
https://www.youtube.com/watch...

這是官方的數據，有必要去了解下android vulkan以及skia vulkan。

android 2DUI的渲染髮展大概是這麼一個進化過程

Android早期通過skia庫進行2d渲染，後來加入了hwui利用opengl替換skia進行大部分渲染工作，現在開始用skia opengl替換掉之前的opengl，從p的代碼結構上也可以看出，p開始skia庫不再作爲一個單獨的動態庫so，而是靜態庫a編譯到hwui的動態庫裏，將skia整合進hwui，hwui調用skia opengl，也爲以後hwui使用skia vulkan做鋪墊。