Android 12(S) 圖形顯示系統 - 解讀Gralloc架構及GraphicBuffer建立/傳遞/釋放（十四）

二的次方發表於2022-03-27

必讀：

Android 12(S) 圖形顯示系統 - 開篇

一、前言

在前面的文章中，已經出現過 GraphicBuffer 的身影，GraphicBuffer 是Android圖形顯示系統中的一個重要概念和元件，顧名思義，它就是用來儲存和傳遞需要繪製的影像資料的。GraphicBuffer 可以在應用程式和 BufferQueue 或 SurfaceFlinger 間傳遞。

本文及接下來的幾篇文章，將聚焦分析 GraphicBuffer 建立的流程，相關元件、服務的基本架構和基本實現原理。

二、GraphicBuffer 相關元件/層級結構預覽

Android 圖形顯示系統中管理、分配、使用 GraphicBuffer 涉及眾多元件，我的理解：

1. 生產者、消費者一般是作為 GraphicBuffer 的使用者，或寫資料，或讀資料；

2. BufferQueue 可以視作 GraphicBuffer 的管理者，它統一處理來自使用者的請求，從而統一管理 GraphicBuffer 的分配、釋放及流轉；

3. Gralloc HAL 是實際快取memory的分配模組，它負責分配可以在程式間共享的圖形buffer;

不同的功能邏輯被封裝為不同的元件/子系統，從系統層級來看，gralloc屬於最底層的HAL層模組，為上層的libui、libgui 庫提供服務，整個層級結構如下所示：

如上圖所示，簡單概述

♦ 最底層是 Gralloc HAL 模組，這部分按照功能劃分為兩部分：allocator 和 mapper。Gralloc 是Android中負責為GraphicBuffer申請和釋放記憶體的HAL層模組，由硬體驅動提供實現，為BufferQueue機制提供了基礎。Gralloc 分配的圖形Buffer是程式間共享的，且根據其Flag支援不同硬體裝置的讀寫。同其它HAL模組一樣，Gralloc 也是實現為 HIDL service的方式，我們暫且稱為 gralloc-allocator hidl service 和 gralloc-mapper hidl service；

♦ 上面一層 libui 庫，主要功能是封裝對 Gralloc HAL 層的呼叫。程式碼目錄是 frameworks/native/include/ui 和 frameworks/native/libs/ui。其中的 GrallocAllocator看作 gralloc-allocator hal 代理，GrallocMapper 看作 gralloc-mapper hal 的代理；

♦ 再向上一層是 libgui 庫，主要功能是封裝連線生產者和消費者的BufferQueue，向下依賴於於libui。程式碼目錄是 frameworks/native/include/gui 和 frameworks/native/libs/gui；

♦ 最上面是使用者，他們對 GraphicBuffer 進行讀寫處理，Skia、Hwui 和 OpenGL ES 是BufferQueue的生產方，SurfaceFlinger 是BufferQueue的消費方；

三、Gralloc HAL介紹

Gralloc HAL 分為了兩部分：一個是 allocator ，一個是 mapper。Android系統定義了標準的 Gralloc HAL interface，具體實現有OEM/晶片廠商完成。

3.1 allocator HAL interface 的定義

[ /hardware/interfaces/graphics/allocator/4.0/IAllocator.hal]

interface IAllocator {
    /**
     * Allocates buffers with the properties specified by the descriptor.
     *
     * Allocations should be optimized for usage bits provided in the
     * descriptor.
     *
     * @param descriptor Properties of the buffers to allocate. This must be
     *     obtained from IMapper::createDescriptor().
     * @param count The number of buffers to allocate.
     * @return error Error status of the call, which may be
     *     - `NONE` upon success.
     *     - `BAD_DESCRIPTOR` if the descriptor is invalid.
     *     - `NO_RESOURCES` if the allocation cannot be fulfilled at this time.
     *     - `UNSUPPORTED` if any of the properties encoded in the descriptor
     *       are not supported.
     * @return stride The number of pixels between two consecutive rows of
     *     an allocated buffer, when the concept of consecutive rows is defined.
     *     Otherwise, it has no meaning.
     * @return buffers Array of raw handles to the allocated buffers.
     */
    allocate(BufferDescriptor descriptor, uint32_t count)
        generates (Error error,
                   uint32_t stride,
                   vec<handle> buffers);
};

IAllocator介面的定義很簡單，只有一個方法allocate，其中引數 descriptor 描述了需要分配的buffer的屬性，它是通過 IMapper::createDescriptor()獲取的，count 標識需要分配的buffer數量。

呼叫成功後返回 raw handle 的陣列buffers。

Allocator 實現為一個 Binderized HAL Service（繫結式HAL）,執行在獨立的程式中，使用者通過 HwBinder 與之建立連線，類似與AIDL獲取服務的方式。

Android 框架層libui庫中的Gralloc4Allocator 就是作為一個代理並對其功能的封裝:

[/frameworks/native/libs/ui/Gralloc4.cpp]

Gralloc4Allocator::Gralloc4Allocator(const Gralloc4Mapper& mapper) : mMapper(mapper) {
    mAllocator = IAllocator::getService();
    ...
}

其中成員sp<hardware::graphics::allocator::V4_0::IAllocator> mAllocator;通過呼叫 IAllocator::getService()便建立了和 allocator hal 的遠端連線。

3.2 mapper HAL interface 的定義

mapper HAL 的定義稍稍複雜一些，原始碼位於/hardware/interfaces/graphics/mapper/4.0/

types.hal 中定義了 Error values 和 BufferDescriptor，比較簡單

IMapper.hal 中定義了介面 IMapper還有一些struct等型別，具體的內容建議直接閱讀原始碼的英文註釋，很詳細。在此我們只列舉幾個主要的相關方法。

[ /hardware/interfaces/graphics/mapper/4.0/IMapper.hal]

interface IMapper {
    // BufferDescriptorInfo用於描述圖形buffer的屬性(寬、高、格式...)
    struct BufferDescriptorInfo {
        string name; // buffer的名字，用於debugging/tracing
        uint32_t width; // width說明了分配的buffer中有多少個畫素列,但它並不表示相鄰行的同一列元素的偏移量，區別stride。
        uint32_t height; // height說明了分配的buffer中有多少畫素行
        uint32_t layerCount; // 分配的緩衝區中的影像層數
        PixelFormat format; // 畫素格式 (參見/frameworks/native/libs/ui/include/ui/PixelFormat.h中的定義)
        bitfield<BufferUsage> usage;buffer使用方式的標誌位(參見/frameworks/native/libs/ui/include/ui/GraphicBuffer.h的定義)。
        uint64_t reservedSize; // 與緩衝區關聯的保留區域的大小（位元組）。
    };
    /**
     * 建立一個 buffer descriptor，這個descriptor可以用於IAllocator分配buffer
     * 主要完成兩個工作：
     * 1. 檢查引數的合法性(裝置是否支援)；
     * 2. 把BufferDescriptorInfo這個結構體變數進行重新的包裝，本質就是轉化為byte stream，這樣可以傳遞給IAllocator
     */
    createDescriptor(BufferDescriptorInfo description)  
            generates (Error error,
                       BufferDescriptor descriptor);
                       
    /**
     * 把raw buffer handle轉為imported buffer handle，這樣就可以在呼叫程式中使用了
     * 當其他程式分配的GraphicBuffer傳遞到當前程式後，需要通過該方法對映到當前程式，為後續的lock做好準備
     */
    importBuffer(handle rawHandle) generates (Error error, pointer buffer);
    
    /**
     * importBuffer()返回的buffer handle不再使用後必須呼叫freeBuffer()釋放
     */
    freeBuffer(pointer buffer) generates (Error error);

    /**
     * 已指定的CPU usage 鎖定緩衝區的指定區域accessRegion。lock之後就可以對buffer進行讀寫了
     */
    lock(pointer buffer,
         uint64_t cpuUsage,
         Rect accessRegion,
         handle acquireFence)
            generates (Error error,
                       pointer data);
    /**
     * 解鎖緩衝區以指示對緩衝區的所有CPU訪問都已完成
     */
    unlock(pointer buffer) generates (Error error, handle releaseFence);
    
    /**
     * 根據給定的MetadataType獲取對應的buffer metadata 
     */
    get(pointer buffer, MetadataType metadataType)
            generates (Error error,
                       vec<uint8_t> metadata);
 
    /**
     * 設定給定的MetadataType對應的buffer metadata 
     */
    set(pointer buffer, MetadataType metadataType, vec<uint8_t> metadata)
            generates (Error error);
};

IMapper 我們可以理解為完成了 buffer handle 所指向的圖形快取到執行程式的對映。訪問 buffer 資料一般遵循這樣的流程：

importBuffer -> lock -> 讀寫GraphicBuffer-> unlock -> freeBuffer

Mapper 實現為一個 Passthrough HAL Service（直通式HAL）, 執行在呼叫它的程式中。本質上 Mode of HIDL in which the server is a shared library, dlopened by the client. In passthrough mode, client and server are the same process but separate codebases.

Android 框架層libui庫中的Gralloc4Mapper 就是作為一個代理並對其功能的封裝:

Gralloc4Mapper::Gralloc4Mapper() {
    mMapper = IMapper::getService();
    ...
}

其中成員sp<hardware::graphics::mapper::V4_0::IMapper> mMapper;通過呼叫 IMapper::getService()便建立了和 mapper hal 的連線。

對於 Passthrough mode下，IMapper::getService()服務建立的過程，下篇文中有分析，可以參考。為什麼 passthrough mode 下，client and server are the same process 執行在同一個程式中？

下一篇文章中我有做一點簡單的探索，感興趣的可以參考：Android 12(S) 圖形顯示系統 - 簡述Allocator/Mapper HAL服務的獲取過程（十五）

3.3 Gralloc Allocator & Mapper HAL 的實現

Gralloc HAL 一般是由硬體廠商完成的，Android 原始碼中有高通的一些參考，不過貌似是一些舊的適配模式。比如 /hardware/qcom/display/msm8998/libgralloc1/

如果是使用的是 ARM Mali GPUs 可以參考官網的開原始碼：Open Source Mali GPUs Android Gralloc Module

我學習中就參考了最新的一個版本：BX304L01B-SW-99005-r36p0-01eac0.tar在它的原始碼目錄下 driver\product\android\gralloc\src\4.x就有 IAllocator 和 IMapper 的具體實現。這部分在此就不做分析了。

四、libui庫中的基本元件

libui 庫主要封裝了對 gralloc allocator /mapper HAL模組的呼叫，管理GraphicBuffer的分配釋放以及在不同程式間的對映，主要包含3個核心類，類圖如下所示：

1. GraphicBuffer：對應gralloc分配的圖形Buffer（也可能是普通記憶體，具體要看gralloc實現），它繼承ANativeWindowBuffer結構體，核心成員是指向圖形快取的控制程式碼（native_handle_t * handle），並且圖形Buffer本身是多程式共享的，跨程式傳輸的是GraphicBuffer的關鍵屬性，這樣在使用程式可以重建GraphicBuffer，同時指向同一塊圖形Buffer。

2. GraphicBufferAllocator：向下對接gralloc allocator HAL服務，是程式內單例，負責分配程式間共享的圖形Buffer，對外即GraphicBuffer。

3. GraphicBufferMapper：向下對接gralloc mapper HAL服務，是程式內單例，負責把GraphicBufferAllocator分配的GraphicBuffer對映到當前程式空間。

五、建立 CraphicBuffer 的基本流程

5.1 生產者請求去建立 GraphicBuffer

在之前講解 BufferQueue 的工作流程 Android 12(S) 圖形顯示系統 - BufferQueue的工作流程（九）這篇文章中，應用程式作為生產者，在準備繪製影像時，呼叫 dequeuBuffer 函式向 BufferQueue 請求一塊可用的圖形快取 GraphicBuffer。

在 dequeuBuffer 函式中，如果找到的 BufferSlot 沒有繫結 GraphicBuffer 或者已繫結的 GraphicBuffer 的屬性與我們需要的不一致，設定標誌 BUFFER_NEEDS_REALLOCATION，這個時候就要去分配圖形快取了，即需要去建立 GraphicBuffer 物件了。

可以先看看 dequeueBuffer 函式中程式碼：

[/frameworks/native/libs/gui/BufferQueueProducer.cpp]

status_t BufferQueueProducer::dequeueBuffer(int* outSlot, sp<android::Fence>* outFence,
                                            uint32_t width, uint32_t height, PixelFormat format,
                                            uint64_t usage, uint64_t* outBufferAge,
                                            FrameEventHistoryDelta* outTimestamps) {
    ...
    // 判斷需要去分配圖形快取，建立 GraphicBuffer 物件
    if (returnFlags & BUFFER_NEEDS_REALLOCATION) {
        BQ_LOGV("dequeueBuffer: allocating a new buffer for slot %d", *outSlot);
        sp<GraphicBuffer> graphicBuffer = new GraphicBuffer(
                width, height, format, BQ_LAYER_COUNT, usage,
                {mConsumerName.string(), mConsumerName.size()});
        
    }
    ...
}

5.2 GraphicBuffer 的定義

[/frameworks/native/libs/ui/include/ui/GraphicBuffer.h]

class GraphicBuffer
    : public ANativeObjectBase<ANativeWindowBuffer, GraphicBuffer, RefBase>,
      public Flattenable<GraphicBuffer>
{
    ...
}

ANativeObjectBase 繼承了 ANativeWindowBuffer 和 RefBase，GraphicBuffer 繼承了 ANativeObjectBase和Flattenable，這樣可以達到：

1. 繼承了 RefBase，使 GraphicBuffer 支援引用計數；

2. 繼承了 Flattenable，使 GraphicBuffer 支援序列化，可以透過 Binder IPC 程式間傳遞；

還有重要的一點，其父類 ANativeWindowBuffer 中儲存有各種屬性資訊，摘取基本資訊如下：

[/frameworks/native/libs/nativebase/include/nativebase/nativebase.h]

// 圖形Buffer的Size = stride * height * 每畫素位元組數
typedef struct ANativeWindowBuffer
{   
    ...
    int width;      // 圖形Buffer的寬度
    int height;     // 圖形Buffer的高度
    int stride;     // 圖形Buffer的步長，為了處理對齊問題，與width可能不同
    int format;     // 圖形Buffer的畫素格式
    const native_handle_t* handle; // 指向一塊圖形Buffer
    uint64_t usage; // 圖形Buffer的使用規則（gralloc會分配不同屬性的圖形Buffer）
    ...

} ANativeWindowBuffer_t;

5.3 GraphicBuffer 的建構函式

GraphicBuffer有好幾個，我們僅列出上述過程中涉及到的，原始碼如下：

[/frameworks/native/libs/ui/GraphicBuffer.cpp]

GraphicBuffer::GraphicBuffer()
    : BASE(), mOwner(ownData), mBufferMapper(GraphicBufferMapper::get()), // 注意這裡去初始化了 mBufferMapper
      mInitCheck(NO_ERROR), mId(getUniqueId()), mGenerationNumber(0)
{
    width  =
    height =
    stride =
    format =
    usage_deprecated = 0;
    usage  = 0;
    layerCount = 0;
    handle = nullptr;
}

GraphicBuffer::GraphicBuffer(uint32_t inWidth, uint32_t inHeight, PixelFormat inFormat,
                             uint32_t inLayerCount, uint64_t inUsage, std::string requestorName)
      : GraphicBuffer() {
    // 呼叫 initWithSize 去完成記憶體分配
    mInitCheck = initWithSize(inWidth, inHeight, inFormat, inLayerCount, inUsage,
                              std::move(requestorName));
}

GraphicBuffer 的建構函式非常簡單, 它只是呼叫了一個初始化函式 initWithSize，還有一點要注意就是去呼叫 GraphicBufferMapper::get() 初始化了 mBufferMapper。

GraphicBufferMapper 是一個單例模式的類，每個程式中只有一個例項，它向下對接 gralloc-mapper hal 的功能，負責把GraphicBufferAllocator分配的GraphicBuffer對映到當前程式空間。先簡單看一下 GraphicBufferMapper 建構函式：

[/frameworks/native/libs/ui/GraphicBufferMapper.cpp]

GraphicBufferMapper::GraphicBufferMapper() {
    // 按照版本由高到低的順序載入 gralloc mapper, 成功則記錄版本，然後退出
    mMapper = std::make_unique<const Gralloc4Mapper>(); // 建立 Gralloc4Mapper 物件
    if (mMapper->isLoaded()) {
        mMapperVersion = Version::GRALLOC_4; // 載入成功 設定 mapper 的版本
        return;
    }
    ...

    LOG_ALWAYS_FATAL("gralloc-mapper is missing");
}

建立 GraphicBufferMapper 物件時，其建構函式中會去建立GrallocMapper物件，系統中會有不同版本的 grolloc-mapper，優先使用高版本，所以建立 Gralloc4Mapper 物件，再看 Gralloc4Mapper 的建構函式：

[/frameworks/native/libs/ui/Gralloc4.cpp]

Gralloc4Mapper::Gralloc4Mapper() {
    mMapper = IMapper::getService(); // 去獲取 gralloc mapper 服務，
    ...
}

Gralloc4Mapper 的建構函式中去獲取 gralloc-mapper hal service，這是一個 passthrough hal service，具體的資訊我們等之後在講解。

這裡我們先暫時理解為：透過 GraphicBufferMapper & Gralloc4Mapper 我們就可以使用 gralloc-mapper hal 的功能了。

5.4 GraphicBuffer::initWithSize

這個函式是核心功能的實現的地方，

[ /frameworks/native/libs/ui/GraphicBuffer.cpp]

status_t GraphicBuffer::initWithSize(uint32_t inWidth, uint32_t inHeight,
        PixelFormat inFormat, uint32_t inLayerCount, uint64_t inUsage,
        std::string requestorName)
{
    // 獲取 GraphicBufferAllocator 物件,程式中單例
    // GraphicBufferAllocator負責分配程式間共享的圖形Buffer
    GraphicBufferAllocator& allocator = GraphicBufferAllocator::get(); 
    uint32_t outStride = 0;
    // 分配一塊指定寬高的 GraphicBuffer
    status_t err = allocator.allocate(inWidth, inHeight, inFormat, inLayerCount,
            inUsage, &handle, &outStride, mId,
            std::move(requestorName));
    if (err == NO_ERROR) {
        mBufferMapper.getTransportSize(handle, &mTransportNumFds, &mTransportNumInts);

        width = static_cast<int>(inWidth);
        height = static_cast<int>(inHeight);
        format = inFormat;
        layerCount = inLayerCount;
        usage = inUsage;
        usage_deprecated = int(usage);
        stride = static_cast<int>(outStride);
    }
    return err;
}

申請成功的圖形Buffer的屬性會儲存在GraphicBuffer父類ANativeWindowBuffer對應欄位中：width/height/stride/format/usage/handle 。

圖形buffer的分配，最終是通過 GraphicBufferAllocator 完成的，GraphicBufferAllocator 向下對接 gralloc-allocator hal 的功能。它是程式內單例，負責分配程式間共享的圖形Buffer，對外即GraphicBuffer。簡單看看其建構函式：

[/frameworks/native/libs/ui/GraphicBufferAllocator.cpp]

GraphicBufferAllocator::GraphicBufferAllocator() : mMapper(GraphicBufferMapper::getInstance()) {
    // 按照版本由高到低的順序載入 gralloc allocator, 成功則退出
    mAllocator = std::make_unique<const Gralloc4Allocator>(
            reinterpret_cast<const Gralloc4Mapper&>(mMapper.getGrallocMapper())); // 建立 Gralloc4Allocator 
    ...
}

建構函式中會去建立一個 Gralloc4Allocator 物件，並且傳遞一個 Gralloc4Mapper 物件作為引數：

[/frameworks/native/libs/ui/Gralloc4.cpp]

Gralloc4Allocator::Gralloc4Allocator(const Gralloc4Mapper& mapper) : mMapper(mapper) {
    mAllocator = IAllocator::getService(); // 獲取 gralloc allocator 服務
    if (mAllocator == nullptr) {
        ALOGW("allocator 3.x is not supported");
        return;
    }
}

Gralloc4Allocator 的建構函式中去獲取 gralloc-allocator hal service，這是一個 binderized hal service，具體的資訊我們等之後在講解。

這裡我們先暫時理解為：透過 GraphicBufferAllocator & Gralloc4Allocator 我們就可以使用 gralloc-alloctor hal 的功能了。

申請圖形Buffer時，除了寬、高、畫素格式，還有一個usage引數，它表示申請方使用GraphicBuffer的行為，gralloc可以根據usage做對應優化，如下部分的 usage 列舉值：

[/frameworks/native/libs/ui/include/ui/GraphicBuffer.h]
[/hardware/libhardware/include/hardware/gralloc.h]

enum {
    USAGE_SW_READ_NEVER     = GRALLOC_USAGE_SW_READ_NEVER, // CPU不會讀GraphicBuffer
    USAGE_SW_READ_RARELY    = GRALLOC_USAGE_SW_READ_RARELY, // CPU很少讀GraphicBuffer
    USAGE_SW_READ_OFTEN     = GRALLOC_USAGE_SW_READ_OFTEN, // CPU經常讀GraphicBuffer
    USAGE_SW_READ_MASK      = GRALLOC_USAGE_SW_READ_MASK,

    USAGE_SW_WRITE_NEVER    = GRALLOC_USAGE_SW_WRITE_NEVER, // CPU不會寫GraphicBuffer
    USAGE_SW_WRITE_RARELY   = GRALLOC_USAGE_SW_WRITE_RARELY, // CPU很少寫GraphicBuffer
    USAGE_SW_WRITE_OFTEN    = GRALLOC_USAGE_SW_WRITE_OFTEN, // CPU經常寫GraphicBuffer
    USAGE_SW_WRITE_MASK     = GRALLOC_USAGE_SW_WRITE_MASK,

    USAGE_SOFTWARE_MASK     = USAGE_SW_READ_MASK|USAGE_SW_WRITE_MASK,

    USAGE_PROTECTED         = GRALLOC_USAGE_PROTECTED,

    USAGE_HW_TEXTURE        = GRALLOC_USAGE_HW_TEXTURE, // GraphicBuffer可以被上傳為OpenGL ES texture，相當於GPU讀GraphicBuffer
    USAGE_HW_RENDER         = GRALLOC_USAGE_HW_RENDER, // GraphicBuffer可以被當做OpenGL ES的渲染目標，相當於GPU寫GraphicBuffer
    USAGE_HW_2D             = GRALLOC_USAGE_HW_2D, // GraphicBuffer will be used by the 2D hardware blitter
    USAGE_HW_COMPOSER       = GRALLOC_USAGE_HW_COMPOSER, // HWC可以直接使用GraphicBuffer進行合成
    USAGE_HW_VIDEO_ENCODER  = GRALLOC_USAGE_HW_VIDEO_ENCODER, // GraphicBuffer可以作為Video硬編碼器的輸入物件
    USAGE_HW_MASK           = GRALLOC_USAGE_HW_MASK,

    USAGE_CURSOR            = GRALLOC_USAGE_CURSOR, // buffer may be used as a cursor
};

圖形Buffer的申請方可以根據場景，使用不同的usage組合。

5.5 GraphicBufferAllocator::allocate

GraphicBufferAllocator 它是一個單例，外部使用時可以通過它來為 GraphicBuffer 來分配記憶體，Android 系統是為了遮蔽不同硬體平臺的差異性，所以在framework 層使用它來為外部提供一個統一的介面。allocate 方法就是對外提供的分配記憶體的介面。

[/frameworks/native/libs/ui/GraphicBufferAllocator.cpp]

status_t GraphicBufferAllocator::allocate(uint32_t width, uint32_t height, PixelFormat format,
                                          uint32_t layerCount, uint64_t usage,
                                          buffer_handle_t* handle, uint32_t* stride,
                                          uint64_t /*graphicBufferId*/, std::string requestorName) {
    return allocateHelper(width, height, format, layerCount, usage, handle, stride, requestorName,
                          true);
}

繼續呼叫到 allocateHelper

status_t GraphicBufferAllocator::allocateHelper(uint32_t width, uint32_t height, PixelFormat format,
                                                uint32_t layerCount, uint64_t usage,
                                                buffer_handle_t* handle, uint32_t* stride,
                                                std::string requestorName, bool importBuffer) {

    // 前面一些程式碼都是在判斷 width/height/format/layerCount 等資訊是否合法及預處理

    // 分配記憶體，呼叫 Gralloc4Allocator::allocate 去分配指定 width/height/format..的圖形buffer
    // 完成後handle就指向了這塊圖形快取
    status_t error = mAllocator->allocate(requestorName, width, height, format, layerCount, usage,
                                          1, stride, handle, importBuffer);
    ...

    if (!importBuffer) { // 如果不需要 註冊buffer則返回，我們講的流程 importBuffer = true
        return NO_ERROR;
    }
    size_t bufSize;

    // 計算 buffer size
    if ((*stride) != 0 &&
        std::numeric_limits<size_t>::max() / height / (*stride) < static_cast<size_t>(bpp)) {
        bufSize = static_cast<size_t>(width) * height * bpp;
    } else {
        bufSize = static_cast<size_t>((*stride)) * height * bpp;
    }

    Mutex::Autolock _l(sLock);
    KeyedVector<buffer_handle_t, alloc_rec_t>& list(sAllocList);
    alloc_rec_t rec;
    rec.width = width;
    rec.height = height;
    rec.stride = *stride;
    rec.format = format;
    rec.layerCount = layerCount;
    rec.usage = usage;
    rec.size = bufSize;
    rec.requestorName = std::move(requestorName);
    list.add(*handle, rec); // 把這塊buffer的資訊記錄下來，放到sAllocList中，dumpsys SurfaceFlinger可以看到所有已分配的buffer的資訊

    return NO_ERROR;
}

GraphicBufferAllocator::allocateHelper 的還是要繼續呼叫 Gralloc4Allocator::allocate 去完成圖形儲存空間的分配，另一個就是它會把分配好的buffer的資訊記錄下來，放到 sAllocList 中，sAllocList 並不是儲存具體的Buffer，而是Buffer的屬性資訊 alloc_rec_t。這樣 dumpsys SurfaceFlinger可以看到所有已分配的buffer的資訊。

比如下面我執行 dumpsys SurfaceFlinger 擷取的部分資訊，可以看到每一個 GraphicBuffer 的資訊，包括 width/height/stride/usage/format/size

GraphicBufferAllocator buffers:
    Handle |        Size |     W (Stride) x H | Layers |   Format |      Usage | Requestor
0xf2fc1060 | 8100.00 KiB | 1920 (1920) x 1080 |      1 |        1 | 0x    1b00 | FramebufferSurface
0xf2fc29c0 | 8100.00 KiB | 1920 (1920) x 1080 |      1 |        1 | 0x    1b00 | FramebufferSurface
0xf2fc32d0 | 8100.00 KiB | 1920 (1920) x 1080 |      1 |        1 | 0x    1b00 | FramebufferSurface
Total allocated by GraphicBufferAllocator (estimate): 24300.00 KB

5.6 Gralloc4Allocator::allocate

GrallocAllocator 有多個實現版本，優先使用高版本 Gralloc4Allocator

[/frameworks/native/libs/ui/Gralloc4.cpp]


status_t Gralloc4Allocator::allocate(std::string requestorName, uint32_t width, uint32_t height,
                                     android::PixelFormat format, uint32_t layerCount,
                                     uint64_t usage, uint32_t bufferCount, uint32_t* outStride,
                                     buffer_handle_t* outBufferHandles, bool importBuffers) const {
    // 構建descriptorInfo物件，用於儲存待建立的圖形buffer的屬性
    IMapper::BufferDescriptorInfo descriptorInfo;
    sBufferDescriptorInfo(requestorName, width, height, format, layerCount, usage, &descriptorInfo);
    // 建立 BufferDescriptor 物件
    // createDescriptor主要完成兩個工作：1. 檢查引數的合法性(裝置是否支援)；
    //                                   2. 把BufferDescriptorInfo這個結構體變數進行重新的包裝，
    //                                      本質就是轉化為byte stream，IPC時傳遞給IAllocator
    BufferDescriptor descriptor;
    status_t error = mMapper.createDescriptor(static_cast<void*>(&descriptorInfo),
                                              static_cast<void*>(&descriptor));
    if (error != NO_ERROR) {
        return error;
    }
    // 呼叫 gralloc allocator hal service 去分配圖形快取
    auto ret = mAllocator->allocate(descriptor, bufferCount,
                                    [&](const auto& tmpError, const auto& tmpStride,
                                        const auto& tmpBuffers) {
                                        error = static_cast<status_t>(tmpError);
                                        if (tmpError != Error::NONE) {
                                            return;
                                        }

                                        if (importBuffers) {
                                            for (uint32_t i = 0; i < bufferCount; i++) {
                                                // importBuffer
                                                error = mMapper.importBuffer(tmpBuffers[i],
                                                                             &outBufferHandles[i]);
                                                if (error != NO_ERROR) {
                                                    for (uint32_t j = 0; j < i; j++) {
                                                        mMapper.freeBuffer(outBufferHandles[j]);
                                                        outBufferHandles[j] = nullptr;
                                                    }
                                                    return;
                                                }
                                            }
                                        } else {
                                            for (uint32_t i = 0; i < bufferCount; i++) {
                                                outBufferHandles[i] = native_handle_clone(
                                                        tmpBuffers[i].getNativeHandle());
                                                if (!outBufferHandles[i]) {
                                                    for (uint32_t j = 0; j < i; j++) {
                                                        auto buffer = const_cast<native_handle_t*>(
                                                                outBufferHandles[j]);
                                                        native_handle_close(buffer);
                                                        native_handle_delete(buffer);
                                                        outBufferHandles[j] = nullptr;
                                                    }
                                                }
                                            }
                                        }
                                        *outStride = tmpStride;
                                    });

    // make sure the kernel driver sees BC_FREE_BUFFER and closes the fds now
    hardware::IPCThreadState::self()->flushCommands();

    return (ret.isOk()) ? error : static_cast<status_t>(kTransactionError);
}

Gralloc4Allocator::allocate 中呼叫 gralloc-allocator hal service 完成最終的圖形快取分配，HAL 層呼叫使用的通訊方式就是 HIDL，其實和我們使用的 AIDL 是類似的原理，最終得到指向圖形buffer的 buffer_handle_t

本文作者@二的次方 2022-03-28 釋出於部落格園

ANativeWindowBuffer.handle是GraphicBuffer的核心資料成員，其型別native_handle_t的定義如下，其中還有定義 create, close, init, delete, clone等操作方法。

[ /system/core/libcutils/include/cutils/native_handle.h]

typedef struct native_handle
{
    int version;        /* sizeof(native_handle_t) */
    int numFds;         /* number of file-descriptors at &data[0] */
    int numInts;        /* number of ints at &data[numFds] */
#if defined(__clang__)
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wzero-length-array"
#endif
    int data[0];        /* numFds + numInts ints */
#if defined(__clang__)
#pragma clang diagnostic pop
#endif
} native_handle_t;

typedef const native_handle_t* buffer_handle_t;

int native_handle_close(const native_handle_t* h);
native_handle_t* native_handle_init(char* storage, int numFds, int numInts);
native_handle_t* native_handle_create(int numFds, int numInts);
native_handle_t* native_handle_clone(const native_handle_t* handle);
int native_handle_delete(native_handle_t* h);

5.7 基本流程圖

我們把上面程式碼描述的過程，簡單總結為下面的圖示。

六、GraphicBuffer的跨程式共享

在圖形系統中，生產者和最終的消費者往往不在同一個程式中，所以 GraphicBuffer 需要跨程式傳遞，以實現資料共享。我們先用一張流程圖來概況：

1. 首先，生產程式通過GraphicBuffer::flatten把ANativeWindowBuffer關鍵屬性儲存在兩個陣列中：buffer和fds,其實就是 Binder 資料傳輸前的序列化處理；

2. 其次，跨程式傳輸buffer和fds，這裡一般就是 Binder IPC 跨程式通訊；

3. 然後，消費程式通過GraphicBuffer::unflatten在自己的程式中重建ANativeWindowBuffer，關鍵是重建ANativeWindowBuffer.handle這個結構體成員，相當於把生產程式的GraphicBuffer對映到了消費程式；

4. 最後，遵循 importBuffer->lock->讀寫GraphicBuffer->unlock->freeBuffer 的基本流程操作GraphicBuffer。

Binder只是傳輸ANativeWindowBuffer屬性（width,height,stride...），真正的底層圖形視訊記憶體（記憶體）是程式間共享的。從上下文可以看出，GraphicBufferAllocator負責在生產程式申請和釋放GraphicBuffer，GraphicBufferMapper負責在消費程式操作GraphicBuffer。

GraphicBufferMapper對GraphicBuffer的所有操作最後都是通過 gralloc mapper HAL 模組實現的。感興趣的的可以去參考原始碼中 IMapper的定義：/hardware/interfaces/graphics/mapper/4.0/IMapper.hal，還有一些廠商的實現 Open Source Mali GPUs Android Gralloc Module

根據上面的流程，我們看看一些關鍵的程式碼：

[/frameworks/native/libs/ui/GraphicBuffer.cpp]

// 計算傳輸GraphicBuffer需要的Size,位元組數
size_t GraphicBuffer::getFlattenedSize() const {
    return static_cast<size_t>(13 + (handle ? mTransportNumInts : 0)) * sizeof(int);
}
// 獲取native_handle_t中需要傳輸的檔案描述符數量
size_t GraphicBuffer::getFdCount() const {
    return static_cast<size_t>(handle ? mTransportNumFds : 0);
}
// 把GraphicBuffer關鍵屬性儲存在buffer和fds中，以進行Binder傳輸
// size表示buffer陣列可用長度，count表示fds陣列可用長度
status_t GraphicBuffer::flatten(void*& buffer, size_t& size, int*& fds, size_t& count) const {
    size_t sizeNeeded = GraphicBuffer::getFlattenedSize();
    if (size < sizeNeeded) return NO_MEMORY; // 判斷buffer可用長度是否足夠

    size_t fdCountNeeded = GraphicBuffer::getFdCount();
    if (count < fdCountNeeded) return NO_MEMORY;  //判斷fds陣列長度是否足夠

    // 把當前GraphicBuffer的關鍵屬性儲存在buffer中
    int32_t* buf = static_cast<int32_t*>(buffer);
    buf[0] = 'GB01';
    buf[1] = width;
    buf[2] = height;
    buf[3] = stride;
    buf[4] = format;
    buf[5] = static_cast<int32_t>(layerCount);
    buf[6] = int(usage); // low 32-bits
    buf[7] = static_cast<int32_t>(mId >> 32);
    buf[8] = static_cast<int32_t>(mId & 0xFFFFFFFFull);
    buf[9] = static_cast<int32_t>(mGenerationNumber);
    buf[10] = 0;
    buf[11] = 0;
    buf[12] = int(usage >> 32); // high 32-bits

    if (handle) {
        buf[10] = int32_t(mTransportNumFds); // 儲存傳遞的檔案描述符數量
        buf[11] = int32_t(mTransportNumInts); // 儲存傳遞的int資料的數量
        // copy檔案描述符陣列到fds
        memcpy(fds, handle->data, static_cast<size_t>(mTransportNumFds) * sizeof(int));
        // copy int陣列到buffer
        memcpy(buf + 13, handle->data + handle->numFds,
               static_cast<size_t>(mTransportNumInts) * sizeof(int));
    }
    // 修改buffer地址和可用長度
    buffer = static_cast<void*>(static_cast<uint8_t*>(buffer) + sizeNeeded);
    size -= sizeNeeded;
    if (handle) {
        fds += mTransportNumFds; // 修改fds地址和可用長度
        count -= static_cast<size_t>(mTransportNumFds);
    }
    return NO_ERROR;
}
// 根據Binder傳輸的buffer和fds中，把建立程式的GraphicBuffer對映到使用程式
status_t GraphicBuffer::unflatten(void const*& buffer, size_t& size, int const*& fds,
                                  size_t& count) {
    // Check if size is not smaller than buf[0] is supposed to take.
    if (size < sizeof(int)) {
        return NO_MEMORY; 
    }

    int const* buf = static_cast<int const*>(buffer);

    // NOTE: it turns out that some media code generates a flattened GraphicBuffer manually!!!!!
    // see H2BGraphicBufferProducer.cpp
    uint32_t flattenWordCount = 0;
    if (buf[0] == 'GB01') {
        // new version with 64-bits usage bits
        flattenWordCount = 13;
    } else if (buf[0] == 'GBFR') {
        // old version, when usage bits were 32-bits
        flattenWordCount = 12;
    } else {
        return BAD_TYPE;
    }
    // 判斷buffer的正確性
    if (size < 12 * sizeof(int)) {
        android_errorWriteLog(0x534e4554, "114223584");
        return NO_MEMORY;
    }
    // 取出檔案描述符和int陣列的數量
    const size_t numFds  = static_cast<size_t>(buf[10]);
    const size_t numInts = static_cast<size_t>(buf[11]);

    // Limit the maxNumber to be relatively small. The number of fds or ints
    // should not come close to this number, and the number itself was simply
    // chosen to be high enough to not cause issues and low enough to prevent
    // overflow problems.
    const size_t maxNumber = 4096;
    if (numFds >= maxNumber || numInts >= (maxNumber - flattenWordCount)) {
        width = height = stride = format = usage_deprecated = 0;
        layerCount = 0;
        usage = 0;
        handle = nullptr;
        ALOGE("unflatten: numFds or numInts is too large: %zd, %zd", numFds, numInts);
        return BAD_VALUE;
    }

    const size_t sizeNeeded = (flattenWordCount + numInts) * sizeof(int);
    if (size < sizeNeeded) return NO_MEMORY; // 判斷buffer長度是否正確

    size_t fdCountNeeded = numFds;
    if (count < fdCountNeeded) return NO_MEMORY; // 判斷fds長度是否正確

    if (handle) {
        // free previous handle if any
        free_handle(); // 如果有，先釋放之前的ANativeWindowBuffer.handle
    }

    if (numFds || numInts) {
        width  = buf[1];
        height = buf[2];
        stride = buf[3];
        format = buf[4];
        layerCount = static_cast<uintptr_t>(buf[5]);
        usage_deprecated = buf[6];
        if (flattenWordCount == 13) {
            usage = (uint64_t(buf[12]) << 32) | uint32_t(buf[6]);
        } else {
            usage = uint64_t(usage_deprecated);
        }
        native_handle* h = // 建立ANativeWindowBuffer.handle，native_handle_create定義在native_handle.c
                native_handle_create(static_cast<int>(numFds), static_cast<int>(numInts));
        if (!h) {
            width = height = stride = format = usage_deprecated = 0;
            layerCount = 0;
            usage = 0;
            handle = nullptr;
            ALOGE("unflatten: native_handle_create failed");
            return NO_MEMORY;
        }
        // 從fds和buffer中copy檔案描述符和int陣列到ANativeWindowBuffer.handle結構體
        memcpy(h->data, fds, numFds * sizeof(int));
        memcpy(h->data + numFds, buf + flattenWordCount, numInts * sizeof(int));
        handle = h;
    } else {
        width = height = stride = format = usage_deprecated = 0;
        layerCount = 0;
        usage = 0;
        handle = nullptr;
    }
    // 從buffer中恢復其他欄位
    mId = static_cast<uint64_t>(buf[7]) << 32;
    mId |= static_cast<uint32_t>(buf[8]);

    mGenerationNumber = static_cast<uint32_t>(buf[9]);
    // 表示GraphicBuffer是從其他程式對映過來的，決定了釋放GraphicBuffer的邏輯
    mOwner = ownHandle;

    if (handle != nullptr) {
        // 呼叫importBuffer，把GraphicBuffer對映到當前程式
        buffer_handle_t importedHandle;
        status_t err = mBufferMapper.importBuffer(handle, uint32_t(width), uint32_t(height),
                uint32_t(layerCount), format, usage, uint32_t(stride), &importedHandle);
        if (err != NO_ERROR) {
            width = height = stride = format = usage_deprecated = 0;
            layerCount = 0;
            usage = 0;
            handle = nullptr;
            ALOGE("unflatten: registerBuffer failed: %s (%d)", strerror(-err), err);
            return err;
        }
        // 關閉釋放對映前的handle
        native_handle_close(handle);
        native_handle_delete(const_cast<native_handle_t*>(handle));
        // 賦值為importedHandle，這個handle即可以在當前程式使用了
        handle = importedHandle;
        mBufferMapper.getTransportSize(handle, &mTransportNumFds, &mTransportNumInts);
    }
    // 調整buffer和fds陣列的地址和可用長度
    buffer = static_cast<void const*>(static_cast<uint8_t const*>(buffer) + sizeNeeded);
    size -= sizeNeeded;
    fds += numFds;
    count -= numFds;
    return NO_ERROR;
}

七、GraphicBuffer的釋放

前面講了 GraphicBuffer 的建立，那它是怎樣被釋放的呢？先看看解構函式的定義：

[/frameworks/native/libs/ui/GraphicBuffer.cpp]

GraphicBuffer::~GraphicBuffer()
{
    ATRACE_CALL();
    if (handle) {
        free_handle(); // handle不是null,需要free
    }
    for (auto& [callback, context] : mDeathCallbacks) {
        callback(context, mId);
    }
}

void GraphicBuffer::free_handle()
{
    if (mOwner == ownHandle) {
        // 僅僅持有handle控制程式碼, 表示圖形Buffer不是自己建立的，
        // 而是從生產程式對映過來的，即當前處於消費程式
        mBufferMapper.freeBuffer(handle);
    } else if (mOwner == ownData) {
        // 擁有資料，表示圖形Buffer是自己建立的，需要自己釋放，即處於生產程式
        GraphicBufferAllocator& allocator(GraphicBufferAllocator::get());
        allocator.free(handle);
    }
    handle = nullptr;
}

指向同一塊圖形Buffer的GraphicBuffer可以存在多個例項，但是底層的圖形Buffer是同一個。講到這裡突然有個疑問：生產程式和消費程式是如何做到同步的？即會不會出現生產程式把GraphicBuffer釋放掉了，而消費程式還在訪問這個GraphicBuffer的狀況？

八、小結

本篇文章分析了GraphicBuffer相關的元件、概念及建立釋放的流程。包括 Gralloc HAL模組，以及libui庫中的主要元件的邏輯。文中觀點也是本人邊學習，邊輸出的，難免有錯誤之處。部分內容的細節也沒有深入刨析，後續在學習中會再陸續補充。

下一篇文中中會講講 Binderized HAL 和 Passthrough HAL 的一點知識，加深對 IMapper 和 IAllocator 模組的理解。

Android 12(S) 影像顯示系統 - GraphicBuffer同步機制 - Fence
2022-05-20
Android
Android 12(S) 圖形顯示系統 - 開篇
2022-01-19
Android
Android 12(S) 圖形顯示系統 - 示例應用（二）
2022-01-18
Android
Android 12(S) 圖形顯示系統 - 基本概念（一）
2022-01-19
Android
Android 12(S) 圖形顯示系統 - createSurface的流程（五）
2022-02-08
Android
Android 12(S) 圖形顯示系統 - BufferQueue/BLASTBufferQueue之初識（六）
2022-03-15
AndroidAST
Android 12(S) 圖形顯示系統 - BufferQueue的工作流程（十一）
2022-03-23
Android
Android 12(S) 圖形顯示系統 - BufferQueue的工作流程（八）
2022-03-20
Android
Android 12(S) 圖形顯示系統 - BufferQueue的工作流程（十）
2022-03-22
Android
Android圖形顯示系統（一）
2017-05-05
Android
Android 12(S) 圖形顯示系統 - 初識ANativeWindow/Surface/SurfaceControl（七）
2022-03-17
Android
Android 12(S) 圖形顯示系統 - 應用建立和SurfaceFlinger的溝通橋樑（三）
2022-01-21
Android
Android 12(S) 圖形顯示系統 - 簡單聊聊 SurfaceView 與 BufferQueue的關聯（十三）
2022-03-25
AndroidView
Android 12(S) 圖形顯示系統 - 簡述Allocator/Mapper HAL服務的獲取過程（十五）
2022-03-28
AndroidAPP
Android 影像顯示系統 - 匯出圖層資料的方法介紹(dump GraphicBuffer raw data)
2022-05-04
Android
Android系統耳機圖示顯示
2020-11-30
Android
Android 圖形架構
2017-07-11
Android架構
Android 12(S) 影像顯示系統 - 基礎知識之 BitTube
2022-04-18
Android
Android 12(S) 圖形顯示系統 - SurfaceFlinger的啟動和訊息佇列處理機制（四）
2022-01-24
Android佇列
Android系統架構圖
2018-11-04
Android架構
Android 12(S) 影像顯示系統 - drm_hwcomposer 簡析（上）
2022-07-05
Android
Android 12(S) 影像顯示系統 - drm_hwcomposer 簡析（下）
2022-07-06
Android
Android 12(S) 影像顯示系統 - HWC HAL 初始化與呼叫流程
2022-06-28
Android
Android 圖形架構簡介
2018-11-10
Android架構
Android 多級樹形結構顯示
2018-03-23
Android
Android 12(S) 影像顯示系統 - SurfaceFlinger 之 VSync - 中篇（十七）
2022-04-26
Android
Android 顯示系統
2014-11-05
Android
Android系統架構-----Android的系統體系架構
2013-10-26
Android架構
Android 12(S) 影像顯示系統 - SurfaceFlinger之VSync-上篇（十六）
2022-04-19
Android
Win10系統如何建立顯示桌面圖示_win10怎麼新增顯示桌面
2019-11-13
Win10
【許曉笛】EOS 系統架構圖解
2018-11-20
架構圖解
Android 12(S) 影像顯示系統 - SurfaceFlinger GPU合成/CLIENT合成方式 - 隨筆1
2022-05-10
AndroidGPUclient
在Windwos系統中用Xmanager2.0連線遠端AIX系統顯示圖形介面
2009-04-02
AI
Android系統架構詳解(2)--Android Runtime
2018-11-12
Android架構
【Android系統】Android系統架構簡介
2018-11-04
Android架構
Android的系統架構
2017-02-26
Android架構
Android-系統架構
2018-05-20
Android架構
React-Quill中的圖片上傳及顯示
2017-12-19
ReactUI