Android SurfaceView 二级双缓冲机制深入分析: 从应用到驱动

于 2025-04-06 22:28:42 发布
阅读量823 收藏 29
点赞数 25
文章标签： android
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/fromair/article/details/147030896
版权

本文统简地分析了 Android 中 SurfaceView 的双缓冲机制实现。我们会一路跑通从 App 端 SurfaceHolder.lockCanvas() 到最终 mmap 显示 buffer 的全过程，并配合 AOSP 和硬件平台代码进行分析。

一、基础缓冲模型

Android 使用 Producer-Consumer 模型，由 App 端的 Surface 作为 BufferQueue 的 producer，由 SurfaceFlinger 或 GPU 作为 consumer，互通 buffer。

App 端:
Canvas canvas = holder.lockCanvas(); // 绘图 buffer
...// 绘图
holder.unlockCanvasAndPost(canvas); // 推送 buffer

从应用角度看，在这个过程中，Android 启用了双缓冲机制：

  • 当前绘图的 buffer
  • 上一帧显示的 buffer

这个机制保证了 UI 滑动和性能的稳定性。

但值得说明的是：实际上 Android 底层的 Surface 在系统级别支持多缓冲的，不止双缓冲，但在 SurfaceView 开发中我们主要操作的是“逻辑上”的双缓冲行为。后面我们会分析到。

二、Surface.lockCanvas 过程分析

Canvas canvas = holder.lockCanvas();最终会调用status_t Surface::lock(
ANativeWindow_Buffer* outBuffer, ARect* inOutDirtyBounds)。canvas应该是对应outBuffer。然后在这个函数里面调用int Surface::dequeueBuffer(android_native_buffer_t** buffer, int* fenceFd)

int Surface::dequeueBuffer(android_native_buffer_t** buffer, int* fenceFd) {
    status_t result = mGraphicBufferProducer->dequeueBuffer(&buf, &fence, dqInput.width,
                                                            dqInput.height, dqInput.format,
                                                            dqInput.usage, &mBufferAge,
                                                            dqInput.getTimestamps ?
                                                                   &frameTimestamps : nullptr);
    
    if ((result & IGraphicBufferProducer::BUFFER_NEEDS_REALLOCATION) || gbuf == nullptr) {
        // 需要重新分
        if (mReportRemovedBuffers && (gbuf != nullptr)) {
            mRemovedBuffers.push_back(gbuf);
        }
        result = mGraphicBufferProducer->requestBuffer(buf, &gbuf);
        if (result != NO_ERROR) {
            ALOGE("dequeueBuffer: IGraphicBufferProducer::requestBuffer failed: %d", result);
            mGraphicBufferProducer->cancelBuffer(buf, fence);
            return result;
        }
    }
}
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) {
    int found = BufferItem::INVALID_BUFFER_SLOT;
    while (found == BufferItem::INVALID_BUFFER_SLOT) {
        // waitForFreeSlotThenRelock: 先从FreeBuffer找，没有再从FreeSlot找
       status_t status = waitForFreeSlotThenRelock(FreeSlotCaller::Dequeue, lock, &found);
       
       const sp<GraphicBuffer>& buffer(mSlots[found].mGraphicBuffer);
       ...
    }
    const sp<GraphicBuffer>& buffer(mSlots[found].mGraphicBuffer);

   if (mCore->mSharedBufferSlot != found) {
       mCore->mActiveBuffers.insert(found);
    }
    *outSlot = found;
    attachedByConsumer = mSlots[found].mNeedsReallocation;
    mSlots[found].mNeedsReallocation = false;

    mSlots[found].mBufferState.dequeue();
    
    if (need realloc) {
        sp<GraphicBuffer> graphicBuffer = new GraphicBuffer(
                width, height, format, BQ_LAYER_COUNT, usage,
                {mConsumerName.string(), mConsumerName.size()});

        status_t error = graphicBuffer->initCheck();
    }
    ...
}

整理下流程:

Surface::lock(ANativeWindow_Buffer*, ARect*)
 → Surface::dequeueBuffer()
     → BufferQueueProducer::dequeueBuffer()
         → waitForFreeSlotThenRelock() // 找到可用 buffer slot
         → mSlots[slot].mGraphicBuffer // 返回 GraphicBuffer
         → GraphicBuffer::initWithSize() // 需新分配时

双缓冲/多缓冲在这个链条中的体现

mSlots[]数组其实就是 缓冲池（buffer pool） ，默认支持 3 个缓冲区（不一定固定是 2 个，所以系统上是多缓冲机制的）。

缓冲区的生命周期大致如下：

  1. Dequeue（出队）

上层（如 SurfaceView）调用 lockCanvas() → 系统从 mSlots[] 中找一个空闲 buffer 返回 → 如果没有可用，就 block 或失败（除非允许 allocate）。

  1. 绘制（CPU/GPU）

应用在这个 GraphicBuffer 上绘图。

  1. Queue（入队）

调用 unlockCanvasAndPost() → 把绘制完的 buffer 送回 BufferQueue，由 SurfaceFlinger 等消费者接管。

  1. 显示（或合成）

SurfaceFlinger 作为 consumer，从队列里拿到 buffer → Composite → 显示。

三、GraphicBuffer 实际分配

GraphicBuffer 是一个 Android Framework 层对 native graphic memory 的封装。

GraphicBuffer::initWithSize()
 → GraphicBufferAllocator::allocate()
     → GrallocXAllocator::allocate()
         → mAllocator->allocate() // IAllocator (HIDL)

相关代码如下

status_t GraphicBuffer::initWithSize(uint32_t inWidth, uint32_t inHeight,
        PixelFormat inFormat, uint32_t inLayerCount, uint64_t inUsage,
        std::string requestorName)
{
    GraphicBufferAllocator& allocator = GraphicBufferAllocator::get();
    uint32_t outStride = 0;
    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);
        ...
    }
}
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,
                                          std::string requestorName) {
    return allocateHelper(width, height, format, layerCount, usage, handle, stride, requestorName,
                          true);
}

GraphicBufferAllocator::GraphicBufferAllocator() : mMapper(GraphicBufferMapper::getInstance()) {
    switch (mMapper.getMapperVersion()) {
        case GraphicBufferMapper::GRALLOC_5:
            mAllocator = std::make_unique<const Gralloc5Allocator>(
                    reinterpret_cast<const Gralloc5Mapper&>(mMapper.getGrallocMapper()));
            break;
        case GraphicBufferMapper::GRALLOC_4:
            mAllocator = std::make_unique<const Gralloc4Allocator>(
                    reinterpret_cast<const Gralloc4Mapper&>(mMapper.getGrallocMapper()));
            break;
        case GraphicBufferMapper::GRALLOC_3:
            mAllocator = std::make_unique<const Gralloc3Allocator>(
                    reinterpret_cast<const Gralloc3Mapper&>(mMapper.getGrallocMapper()));
            break;
        case GraphicBufferMapper::GRALLOC_2:
            mAllocator = std::make_unique<const Gralloc2Allocator>(
                    reinterpret_cast<const Gralloc2Mapper&>(mMapper.getGrallocMapper()));
            break;
    }
    LOG_ALWAYS_FATAL_IF(!mAllocator->isLoaded(),
                        "Failed to load matching allocator for mapper version %d",
                        mMapper.getMapperVersion());
}

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) {
   ATRACE_CALL();
   ....
   // std::unique_ptr<const GrallocAllocator> mAllocator;
   status_t error = mAllocator->allocate(requestorName, width, height, format, layerCount, usage,
                                          stride, handle, importBuffer);
  ...
}
// mAllocator->allocate应该就进入驱动层了，以Gralloc3Allocator为例：

Gralloc3Allocator::Gralloc3Allocator(const Gralloc3Mapper& mapper) : mMapper(mapper) {
    mAllocator = IAllocator::getService();
    if (mAllocator == nullptr) {
        ALOGW("allocator 3.x is not supported");
        return;
    }
}

status_t Gralloc3Allocator::allocate(std::string /*requestorName*/, uint32_t width, uint32_t height,
                                     android::PixelFormat format, uint32_t layerCount,
                                     uint64_t usage, uint32_t* outStride,
                                     buffer_handle_t* outBufferHandles, bool importBuffers) const {
 auto ret = mAllocator->allocate(...)...
}

上面的IAllocator::getService()->allocate(...) 就是 Binder 跨进程到 HAL 服务了， 通过 HIDL 获取 Gralloc HAL 服务。这个接口在系统启动时就由 vendor.gralloc 实现注册到了 HAL 服务管理器。

最终会调用硬件平台的 gralloc HAL：

以 QCOM 为例：

gr_ion_alloc.cpp:
addr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
  • ion_alloc_fd() 分配显实 memory
  • 将 fd 用 mmap 映射成用户端地址
  • 返回这个地址给 GraphicBuffer

四、mmap 问题分析

给定 platform (如 msm8909) 下调用 mmap 分析：

$ grep mmap -rn ./hardware/qcom/display/msm8909
./libqdutils/qdMetaData.cpp:55:        void *base = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED,
./libqdutils/qdMetaData.cpp:58:            ALOGE("%s: metadata mmap failed - handle:%p fd: %d err: %s",
./gralloc/gr_ion_alloc.cpp:132:  addr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
./libgralloc/ionalloc.cpp:103:        base = mmap(0, ionAllocData.len, PROT_READ|PROT_WRITE,
./libgralloc/ionalloc.cpp:153:    base = mmap(0, size, PROT_READ| PROT_WRITE,
./libgralloc/framebuffer.cpp:331:    void* vaddr = mmap(0, fbSize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
./libgralloc/mapper.cpp:70:            ALOGE("Could not mmap metadata for handle %p, fd=%d (%s)",
./libgralloc/mapper.cpp:100:            ALOGE("Could not mmap handle %p, fd=%d (%s)",
./sdm/libs/hwc2/hwc_color_manager.cpp:226:      void *buffer = mmap(NULL, buffer_info.alloc_buffer_info.size, PROT_READ | PROT_WRITE,
./sdm/libs/hwc2/hwc_color_manager.cpp:230:        DLOGE("mmap failed. err = %d", errno);
./sdm/libs/hwc2/hwc_display_external_test.cpp:223:  char *buffer = reinterpret_cast<char *>(mmap(NULL, buffer_info_.alloc_buffer_info.size,
./sdm/libs/hwc2/hwc_display_external_test.cpp:227:    DLOGW("mmap failed. err = %d", errno);
./sdm/libs/hwc2/hwc_display_external_test.cpp:328:  uint8_t *buffer = reinterpret_cast<uint8_t *>(mmap(NULL, buffer_info_.alloc_buffer_info.size,
./sdm/libs/hwc2/hwc_display_external_test.cpp:332:    DLOGE("mmap failed. err = %d", errno);
./sdm/libs/hwc2/hwc_display_primary.cpp:524:  void *buffer = mmap(NULL, output_buffer_info_.alloc_buffer_info.size, PROT_READ | PROT_WRITE,
./sdm/libs/hwc2/hwc_display_primary.cpp:528:    DLOGE("mmap failed with err %d", errno);
./sdm/libs/hwc/hwc_color_manager.cpp:375:      void *buffer = mmap(NULL, buffer_info.alloc_buffer_info.size,
./sdm/libs/hwc/hwc_color_manager.cpp:380:        DLOGE("mmap failed. err = %d", errno);
./sdm/libs/hwc/hwc_display_external_test.cpp:230:  char *buffer = reinterpret_cast<char *>(mmap(NULL, buffer_info_.alloc_buffer_info.size,
./sdm/libs/hwc/hwc_display_external_test.cpp:234:    DLOGW("mmap failed. err = %d", errno);
./sdm/libs/hwc/hwc_display_external_test.cpp:335:  uint8_t *buffer = reinterpret_cast<uint8_t *>(mmap(NULL, buffer_info_.alloc_buffer_info.size,
./sdm/libs/hwc/hwc_display_external_test.cpp:339:    DLOGE("mmap failed. err = %d", errno);
./sdm/libs/hwc/hwc_display_primary.cpp:484:  void *buffer = mmap(NULL, output_buffer_info_.alloc_buffer_info.size,
./sdm/libs/hwc/hwc_display_primary.cpp:489:    DLOGE("mmap failed with err %d", errno);

上面已经接近看到真正显存映射到用户空间的「关键点」了。有兴趣可以看看哪些值得深入阅读。

关键代码：

文件mmap 说明
gralloc/gr_ion_alloc.cpp:132主分配 + mmap 场景
libgralloc/ionalloc.cppION 分配器层，是 HAL 实现
libgralloc/mapper.cpp:100GraphicBufferMapper::lock() 实现

五、总结

  • Android 通过 BufferQueue 实现双缓冲
  • buffer 最终是由 Gralloc HAL 分配显实存储
  • 用 mmap 将 fd 映射成进程地址
  • 通过 binder + fd 进行跨进程共享

这些设计使 Android 的 UI 控制有着极高效率和扩展性，也是 SurfaceFlinger / SurfaceView 可靠性操作的基础。

fromair
关注
从零开始仿写一个抖音App——Android绘制机制以及Surface家族源码全解析
2401_84123557的博客
04-19 957
今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司20年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。还有。
Android面试从新手到架构师，一篇解析就够（网络、算法、Java、Android通信、系统、优化(1)
最新发布
2401_83601703的博客
05-05 697
定义：等待时间最久的线程会优先获得锁非公平锁无法保证哪个线程获取到锁，synchronized 就是非公平锁ReentrantLock 默认时非公平锁，可以设置为公平锁悲观锁：线程一旦得到锁，其他线程就挂起等待，适用于写入操作频繁的场景；synchronized 就是悲观锁乐观锁：假设没有冲突，不加锁，更新数据时判断该数据是否过期，过期的话则不进行数据更新，适用于读取操作频繁的场景乐观锁 CAS：Compare And Swap，更新数据时先比较原值是否相等，不相等则表示数据过去，不进行数据更新乐观锁实现：
android+多线程和双缓冲,Android应用之SurfaceView的双缓冲使用
weixin_39789646的博客
05-25 159
这次介绍SurfaceView的双缓冲使用。双缓冲是为了防止动画闪烁而实现的一种多线程应用，基于SurfaceView的双缓冲实现很简单，开一条线程并在其中绘图即可。本文介绍基于SurfaceView的双缓冲实现，以及介绍类似的更高效的实现方法。本文程序运行截图如下，左边是开单个线程读取并绘图，右边是开两个线程，一个专门读取图片，一个专门绘图：对比一下，右边动画的帧速明显比左边的快，左右两者都没使...
SurfaceView的双缓冲机制
rabbit_in_android的博客
03-05 1万+
一、首先SurfaceView是双缓冲机制，有front和back，这两个交替显示，每post一次交替一次。 二、dirty区域是根据front和back来进行计算的。 三、程序没有填充的都算dirty区域 有了这几个前提后，自己的问题发现就解决了。首先自己第一、二次点击时，LockCanvas(Rect rect)无效，是因为back没有进行过程序填充，所以和front
什么是SurfaceView的双缓冲机制
guanguanboy的专栏
08-19 732
在运用时可以理解为：SurfaceView在更新视图时用到了两张 Canvas，一张 frontCanvas 和一张 backCanvas ，每次实际显示的是 frontCanvas ，backCanvas 存储的是上一次更改前的视图。当你在播放这一帧的时候，它已经提前帮你加载好后面一帧了，所以播放起视频很流畅。 当使用lockCanvas（）获取画布时，得到的实际上是backCanvas 而不是...
SurfaceView双缓冲机制
墨漓
11-08 1533
什么是缓冲？ 在我们的界面中图形都是在画布上绘制出来的，所以这个绘制的过程就叫缓冲,而画布也就可以称作缓冲区。 缓冲的种类： 无缓冲：不使用画布的情况下直接在窗口上进行绘图就叫做无缓冲绘图。 单缓冲：用了一个画布，将所有的内容先绘制到画布上，再整体绘制到窗口，这个就叫做单缓冲绘图。 双缓冲：用了两个画布，一个进行临时的绘图，一个进行最终的绘图，这样的就叫做双缓冲绘图。 surfaceV...
SurfaceView 的双缓冲
liuqinhou的博客
08-10 771
SurfaceView
【USB摄像头控制代码示例】：Android应用扩展的实现方法
![【USB摄像头控制代码示例】：Android应用扩展的实现方法]...本文探讨了Android平台下USB摄像头控制的技术理论、实现步骤、实践应用、高级功能开发以及性能优化与测试。首先阐述了USB摄像头控制的基础理论，接着详
Android面试题(持续更新中)
Bearin的博客
04-30 9284
Android面试题
Android 演示View双缓冲、SurfaceView缓冲的区别.rar
07-10
Android 演示View双缓冲、SurfaceView缓冲的区别，使用了部分Canvas的方法，本实例通过使用View和SurfaceView分别绘制两条曲线图，然后可以比较出两者的区别，能看出两条线在绘制过程中的差异。
深入探索Android布局优化（上）
十年代码写十年
05-22 755
前言 成为一名优秀的Android开发，需要一份完备的知识体系，在这里，让我们一起成长为自己所想的那样~。 Android的绘制优化其实可以分为两个部分，即布局(UI)优化和卡顿优化，而布局优化的核心问题就是要解决因布局渲染性能不佳而导致应用卡顿的问题，所以它可以认为是卡顿优化的一个子集。对于Android开发来说，写布局可以说是一个比较简单的工作，但是如果想将写的每一个布局的渲染性能提升到比较好的程度，要付出的努力是要远远超过写布局所付出的。由于布局优化这一主题包含的内容太多，因此，笔者将它分为了上、
SurfaceView闪烁问题的根源-双缓存机制
热门推荐
^-^
12-05 2万+
上篇中提到了SurfaceView绘制触摸轨迹时出现的闪烁问题，这里就说明下产生这种困扰的根源——双缓存机制。     Android中的SurfaceView在更新视图时，为了提高更新效率，加强用户体验，采用了双缓存机制。     Android的官方说明有： Note: On each pass you retrieve the Canvas from the SurfaceHolder,
SurfaceView的使用以及缓冲机制
陈德山
08-04 3127
背景 基于有些动画要求帧数比较高，具有实时性，传统的View刷新的帧数不高，并且会出现卡顿的现象，而SurfaceView就能解决这个问题。
Android SurfaceView 使用双缓冲机制_双缓冲优化之只改变动态精灵_ Handler线程外通信_弹出对话框与提示信息
LW_Hadoop的博客
05-31 792
SurfaceView是游戏中最常用的组件，但是SurfaceView的动态绘制会造成闪屏、黑屏的现象，利用双缓冲可以缓解这一现象，并且这里对双缓冲就行了二次优化处理,并且Handler与其他线程的通信方式 1、普通双缓冲机制的实现 这里仅截取实现的一部分 // 游戏界面 public class GameView extends SurfaceView implements SurfaceHolder.Callback,Runnable{ private Canvas canvas; //画布
surfaceview缓存问题
wjtzc1990的专栏
12-22 2582
之前在网上看到surfaceview有双缓存机制,但是实际用起来并不是绝对的双缓存,还在网上看到有说三缓存的,但是实际操作中发现这并不是绝对的. 用surfaceview绘图的时候,先调用holder.lockCanvas()获得一个canvas,然后可以在这个canvas上继续画东西,然后调用holder.unlockCanvasAndPost(canvas)将这个canvas绘制到s
Android SurfaceView双缓冲绘图
Ethan的博客
03-14 3251
这篇文章与下一篇关于DialogFragment与Activity通信的博客共同组成了一个Demo，即使用SurfaceView实现自由手绘，功能包括颜色选择、画笔粗细、撤销重做、橡皮擦。源码托管在github，欢迎follow and fork！ 源码地址：https://github.com/boomstack/MySurfaceView 双缓冲其实解决的问题是不加缓冲时的闪烁、卡顿问题，不
Android surfaceview双缓冲机制和闪屏的解决方法内附代码详解
啃黄瓜的蜗牛
12-15 7712
1、双缓冲机制： 至于什么是双缓冲机制，我这里简单介绍一下，大家可以上网查看别人的资料都很详细了：这种机制的原理就是第一次显示缓存A的内容，下次显示缓存B的内容，在下次又显示缓存A的内容，即两个缓存中的内容交替显示，并且两个缓存中的数据是相互独立的。 这个机制在surfaceview中是如何实现的呢？通过这几个方法：surfaceholder.lockCanvas--surfaceholder
SurfaceView双缓冲技术在Android中的应用
"SurfaceView的双缓冲使用Android" 在Android开发中，SurfaceView是一个重要的视图组件，常用于处理高性能的图形渲染，如游戏或者视频播放等。双缓冲技术是SurfaceView提高性能和避免屏幕闪烁的关键策略。在Android...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值