Android Display Graphics #2 整体框架介绍二

最新推荐文章于 2024-07-31 16:29:45 发布
最新推荐文章于 2024-07-31 16:29:45 发布
阅读量799 收藏 24
点赞数 21
文章标签： android
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/oDwyane03/article/details/140826083
版权

系列文章请扫关注公众号！

1、Android 图形元素

不管开发的小伙伴使用系统的哪个API显示内容，最终都会将显示内容渲染到surface上。前面说了，Surface理解为存储数据的内存块，实际上Surface表示缓冲区队列BufferQueue的生产者角色，而缓冲区队列BufferQueue一般被SurfaceFlinger消费掉，也就是说SurfaceFlinger扮演的是缓冲区队列BufferQueue的消费者。

Android平台上创建的每一个窗口都由Surface提供支持的。所有被渲染的可见的Surface都被SurfaceFlinger合成并送显到Display上。

协作图如下：

上图的系统架构是生产者-消费者模式，从上到下的层次：

  1. Image Stream Producers

•  图像数据的生产者,可以是Media Player视频解码器，Camera预览，NDK调用，OpenGL ES接口。可以分为两类数据的传输，一个是真正的显示帧数据BufferData，即Surface，通过BufferQueue的方式调用libgui的接口入队。一个是窗口信息的传递WindowMetadata，即窗口的大小，位置等。

•  例如view每次执行lockCanvas->draw->unlockCanvas，会存入一帧数据进入BufferQueue中。

  1. Native Framework

•  Framework对上层提供的接口在libgui中，frameworks/native/libs/gui。在这里可以操作Surface出队入队Buffer队列BufferQueue。实现Buffer的生成和BufferQueue数据跨进程之间的传递。

  1. WindowManager

• 计算窗口大小，位置等，并传递相应的参数到SurfaceFlinger，SurfaceFlinger根据这些Window Metadata信息，设置窗口Window的大小、z-order等。

  1. Image Stream Consumers

• 代表的是图像数据的消费者。SurfaceFlinger消耗的是BufferQueue中visible的Surface，并使用WindowManager中的Metadata信息对这些Surface进行合成。SurfaceFlinger是可以修改显示内容的唯一服务，也是显示系统中承上启下的核心服务。

•  SurfaceFlinger 使用 OpenGL 和 Hardware Composer 来合成一组 Surface。OpenGL ES 应用也可以消耗图像流，例如相机应用会消耗相机预览图像流。非 GL 应用也可以是消费者，例如 ImageReader。

5、HAL 硬件混合渲染器

•  这块主要如前一节介绍的HWC，DPU相关。一块是Hardware Composer也用于合成和送显。当SurfaceFlinger中合成的图层时，会请求composer合成，因为它合成的快，功耗又低。如果合成的layer数大于composer支持的最大数了，那剩下的就让SurfaceFlinger通过GPU合成，最后统一送给HardwareComposer送显。

•  SurfaceFlinger在请求HWC Composer合成时，本身充当了一个OpenGL ES的client端。

•  Gralloc 是系统图像显示的内存分配器，用来分配图像生产者请求的内存。和系统的ION是有关的。

GraphicBuffer介绍

应用有显示需求时，应用会向系统申请一块GraphicBuffer内存，这块内存将会共享给GPU用于执行渲染工作，接着会同步给HWC用于合成和显示。

GraphicBuffer是Display系统中的显示内存管理类，在APP、SurfaceFlinger、HardwareComposer之间传递。渲染和合成操作都将在GraphicBuffer上进行的。

定义在/frameworks/native/libs/ui/include/ui/GraphicBuffer.h

class GraphicBuffer

     : public ANativeObjectBase<ANativeWindowBuffer, GraphicBuffer, RefBase>,

       public Flattenable<GraphicBuffer>

{

    friend class Flattenable<GraphicBuffer>;

public:

......

static sp<GraphicBuffer> from(ANativeWindowBuffer *);

static GraphicBuffer* fromAHardwareBuffer(AHardwareBuffer*);

static GraphicBuffer const* fromAHardwareBuffer(AHardwareBuffer const*);

     AHardwareBuffer* toAHardwareBuffer();

     AHardwareBuffer const* toAHardwareBuffer() const;

     // Create a GraphicBuffer to be unflatten'ed into or be reallocated.

     GraphicBuffer();

    // Create a GraphicBuffer by allocating and managing a buffer internally.

     // This function is privileged.  See reallocate for details.

     GraphicBuffer(uint32_t inWidth, uint32_t inHeight, PixelFormat inFormat,

             uint32_t inLayerCount, uint64_t inUsage,

             std::string requestorName = "<Unknown>");

......

}

可以与ANativeWindowBuffer、AHardwareBuffer相互转换。上层JNI的调用封装在android_hardware_HardwareBuffer.cpp、android_graphics_GraphicBuffer.cpp 。

Libgui.so中有广泛使用这个对象，并将封装在一个Surface中，例如

/frameworks/native/libs/gui/Surface.cpp

Surface::attachBuffer函数将Surface与GraphicBuffer attached。

GraphicBuffer 的分配和回收由gralloc管理。

Fence机制

一个GraphicBuffer对象完整的生命周期大概是这样：

  • 渲染阶段：应用有绘图需求了，由GPU分配一块内存给应用，应用调用GPU执行绘图，此时使用者是GPU
  • 合成阶段：GPU渲染完成后将图层传递给sf进程，sf进程决定由谁来合成，hwc或者GPU 
    • 如果使用GPU合成，那么此时buffer的使用者依旧是GPU
    • 如果使用hwc合成，那么此时buffer的使用者是hwc
  • 显示阶段：所有的buffer在此阶段的使用者都是hwc，因为hwc控制着显示芯片

从生命周期可以看出GraphicBuffer对象在流转的过程中，会被GPU、CPU、DPU三个不同的硬件访问，此时需要一个同步机制。用来保证跨硬件访问时的数据安全。可以把Fence理解为一把硬件的互斥锁。

每个需要访问GraphicBuffer的角色，在使用前都要检查这把锁是否signaled了才能进行安全的操作，否则就要等待。

  • active状态，该GraphicBuffer正在被占用
  • signaled状态，表明不再控制buffer

BufferQueue

GraphicBuffer的queue队列，BufferQueue的引入是为了解决性能问题。如果只有一个Buffer，是不合理的，因为在渲染、合成、送显这个相当于线性执行，效率太低。所以就有了double和triple缓冲机制，相当于有的Buffer在渲染的同事，另外Buffer可以合成、送显。这样就提高了效率。

Surface的概念是对APP进程讲的，Layer是对系统进程讲的，例如SurfaceFlinger。

前面说的生产者-消费者模型，对于BufferQueue来说就是

这里的producer就是前面说的各app，当app create一个Surface时就向BufferQueue队列申请一个buffer，这个过程称为dequeue。当app绘制(渲染)好这个Surface后就放入BufferQueue中，这个过程称为queue。

这里的Consumer如上面说的，对于可见layer，它就是SurfaceFlinger。当buffer 放入BufferQueue后，通知SurfaceFlinger消费。SurfaceFlinger从BufferQueue拿buffer的过程称为acquire。当SurfaceFlinger合成完后，就将buffer释放并放回BufferQueue中，这个过程称为release。

声明和定义在libgui.so中 /frameworks/native/libs/gui/include/gui/BufferQueue.h

class BufferQueue {

static void createBufferQueue(sp<IGraphicBufferProducer>* outProducer,

            sp<IGraphicBufferConsumer>* outConsumer,

            bool consumerIsSurfaceFlinger = false);

}

创建BufferQueue时需要传入producer和Consumer。

GraphicBuffer在producer、BufferQueue、Consumer之间传递，是有状态的。GraphicBuffer就是在不断地循环FREE->DEQUEUED->QUEUED->ACQUIRED->FREE这个过程。

数据流

。。。。。。

2、Google组件库

。。。。。。。

详细全文关注公众号查看

Dwyane03
关注
Android 显示系统框架
weixin_49303682的博客
03-03 1937
FrameBuffer中文译名为帧缓冲驱动，它是出现在2.2.xx内核中的一种驱动程序接口。主设备号为29，次设备号递增。Linux抽象出FrameBuffer这个设备来供用户态进程实现直接写屏。FrameBuffer机制模仿显卡的功能，将显卡硬件结构抽象掉，可以通过FrameBuffer的读写直接对显存进行操作。用户可以将FrameBuffer看成是显示内存的一个映像，将其映射到进程地址空间之后，就可以直接进行读写操作，而写操作可以立即反应在屏幕上。这种操作是抽象的，统一的。
Linux/Android显示框架
OneSea的专栏
04-28 2568
0 前言 早期Linux系统主要使用Framebuffer显示框架，但2016年之后各主流平台逐渐切换到DRM框架。本文重点介绍相关发展历程，已经对FB和DRM显示框架进行对比分析。 1 正文 。。。更新中 参考资料 ...
Android display架构分析
BonderWu的专栏
08-12 2万+
Android display架构分析（一） http://hi.baidu.com/leowenj/blog/item/429c2dd6ac1480c851da4b95.html 高通7系列硬件架构分析 如上图，高通7系列 Display的硬件部分主要由下面几个部分组成： A、MDP 高通MSM7200A内部模块，主要负责显示数据的转换和部分图像处理功能理，如YUV转RGB，放大缩
Android显示系统设计框架介绍
热门推荐
深入剖析Android系统
04-02 3万+
1. Linux内核提供了统一的framebuffer显示驱动，设备节点/dev/graphics/fb*或者/dev/fb*，以fb0表示第一个显示屏，当前实现中只用到了一个显示屏。 2. Android的HAL层提供了Gralloc，分为fb和gralloc两个设备。设备fb负责打开内核中的framebuffer以及提供post、setSwapInterval等操作，设备gralloc则负责
Android display架构分析-SW架构分析(1-4)
wealoong的专栏
07-03 5247
参考： Android display架构分析二-SW架构分析 Android display架构分析三-Kernel Space Display架构介绍 Android display架构分析四-msm_fb.c 函数和数据结构介绍。。。。。 高通Android平台下关于display部分的几个关键问题 高通Qc FB驱动 以及 LCD调试过程 And
Android显示框架详细分析
06-09
神作。。从高通7系列硬件架构，Android Display SW架构，到Android显示系统的C/S架构，SurfaceFlinger系统服务等，详细分析了Android的显示机制。
Android显示架构
岩之有理的博客
12-13 885
一.术语 二.显示机制 2.1 水平和垂直同步信号 在早期的CRT显示器，电子枪从上到下逐行扫描，扫描完成后显示器就呈现一帧画面。然后电子枪回到初始位置进行下一次扫描。为了同步显示器的显示过程和系统的视频控制器，显示器会用硬件时钟产生一系列的定时信号。 当电子枪换行进行扫描时，显示器会发出一个水平同步信号（horizonal synchronization），简称 HSync 当一帧画面绘制完成后，电子枪回复到原位，准备画下一帧前，显示器会发出一个垂直同步信号（vertical synchronizat
Android显示框架：Android应用视图的载体View
Android062001的博客
07-01 432
关于作者 郭孝星，程序员，吉他手，主要从事Android平台基础架构方面的工作，欢迎交流技术方面的问题，可以去我的Github提issue或者发邮件至guoxiaoxingse@163.com与我交流。 第一次阅览本系列文章，请参见导读，更多文章请参见文章目录。 文章目录 一 View的生命周期 二 View的测量流程 三 View的布局流程 四 View的绘制流程 五 View事件分发机制 This class represents the basic building block for us
android display 框架,高通android display subsystem
weixin_39562327的博客
05-30 653
转自：http://blog.csdn.net/shichaog/article/details/61191716MDSS：Multimedia Display Sub-systemDisplay driver包括：SurfaceFlinger，Hardware Composer(HWC)，以及overlayFramebufferMIPI DSI驱动系统架构MDSS 1.0显示子系统Soure S...
高通Android display分析【转】
zzb2760715357的博客
02-17 279
本文转载自：http://blog.csdn.net/zhangchiytu/article/details/6777039 高通7系列硬件架构分析 如上图，高通7系列 Display的硬件部分主要由下面几个部分组成： A、MDP 高通MSM7200A内部模块，主要负责显示数据的转换和部分图像处理功能理，如YUV转RGB，放大缩小、旋转等。MDP内部的MDP DMA负责数据从DDR到MDDI ...
Android Display Graphics #1 整体框架介绍一
oDwyane03的博客
07-31 861
手机屏上显示的内容，2D或3D ，如果是 3D 的，不管是 App 还是游戏，或者简单的图片界面，底层都是通过 GPU、 通过 OpenGL(ES)绘制出来的。是Java层的一个类，提供了一系列API，使用这些API可以实现各种的产品经理要求的效果。显示的不同阶段对这块内存的叫法不同，在上层可以是Window、ANnativeWindow、Surface、SurfaceView、layer、buffer，这些本质上没啥区别，可以广泛意义上理解为用于显示内容的那块内存，只不过各个阶段的操作接口不同。
android裁剪视频框架,android图像裁剪框架uCrop
weixin_30120049的博客
05-29 595
第一步先导入依赖implementation 'com.github.yalantis:ucrop:2.2.1'implementation 'pub.devrel:easypermissions:1.2.0' //权限库下面开始上代码这个是重点 网上很多这里就不解释，可以自己问度娘/*** 裁剪图片** @param sourceUri*/private void startUCrop(Uri ...
Android Graphics -2 架构概述
GuoQun01的专栏
08-02 616
Graphics 架构 摘要：Low-level 组件，High-level 组件 每个开发者都应该知道的关于Surface，SurfaceHolder，EGLSurface，SurfaceView，GLSurfaceVIew，SurfaceTexture，TextureView，SurfaceFlinger，and Vulkan。 本文描述了Android系统级（system-level）...
android显示系统框架分析
Android framework
07-28 301
Android显示系统
Android 显示框架：Surface详解之一
爱睡觉的潘sky的博客
03-20 5187
所有surface在native的构建都需要一个graphicbufferproducer作为参数。而这也真好印证了中所提到的surface在java层由三种构建方式，同样对于IGraphicBufferProducer也有不同的渠道获得。
AndroidO 下图形显示框架变化介绍
深入剖析Android系统
05-07 9589
Android显示框架随着Android版本的不断升级，也在不断变化修改，但主体框架未变，依然保持Android4.0上定制的实现结构，只是类命名更加清晰，实现方式更加明了，同时随着HAL版本的不断升级，增加了一些额外的接口，随着AndroidO引入Treble架构，显示框架也作了必要的调整。AndroidO之前版本下的显示实现框架如下图所示：整个显示过程由App，system_server和su...
(转)Android display架构分析（四）
lovekoala的专栏
05-07 1241
<br />msm_fb.c 函数和数据结构介绍<br />该文件为高通显卡的驱动文件，比较重要的函数接口和数据结构如下：<br />A、高通msm fb设备的文件操作函数接口<br />static struct fb_ops msm_fb_ops = {<br />.owner = THIS_MODULE,<br />.fb_open = msm_fb_open,<br />.fb_release = msm_fb_release,<br />.fb_read = NULL,<br />.fb_writ
Android Display 系统分析
小码农的小梦想
11-30 2万+
Android Display 系统分析大概两年前做过一个项目，大致是在Android 系统上实现双显的支持，其中有个需求是需要手动配置每个显示器的旋转角度，当时对Android 的 Display系统有关简单了解，但是不够深入。一直觉得是留下了一个遗憾，现在趁有时间来把这一块再好好了解下。闲话少说，开始吧。本文将按照以下方式来组织：Android Display 框架 Android Surfac
Android Display Graphics #从Activity看surface的创建(2)
最新发布
oDwyane03的博客
07-31 700
Surface创建标志明确了要创建哪种Surface和特定的选项，比如Surface可以被认为是不透明的，是否应该在初始的时候隐藏。一个好的实践是，首先使用HIDDEN标志创建Surface，接着打开一个Transactionn，设置Surface的layer、layer堆栈、透明度、位置，然后再合适的时机调用Transaction.show，最后关闭Transactoin。如果这个Surface没有buffer或者是crop，那么这个Surface就是无边界的，只被它的父Surface的界限尺寸所限制。
（转）Android display架构分析（六）
lovekoala的专栏
05-07 639
<br /><br />本部分介绍的完全是用户空间显示部分的架构，与kernel并没有直接的联系，主要是JNI以下到HAL以上的部分。1、Surface manager（surface flinger）简介<br />Surface manager是用户空间中framework下libraries中负责显示相关的一个模块。<br /><br />    当系统同时执行多个应用程序时，Surface Manager会负责管理显示与存取操作间的互动，另外也负责将2D绘图与3D绘图进行显示上的合成。<br /> 
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值