Android Display buffer_handle_t的定义

最新推荐文章于 2024-07-29 15:54:03 发布
最新推荐文章于 2024-07-29 15:54:03 发布
阅读量381 收藏
点赞数
文章标签： 移动开发
本文介绍了Android系统中buffer_handle_t与native_handle_t的数据结构定义及其作用。buffer_handle_t作为图形缓冲区的句柄类型，而native_handle_t则是用于传递文件描述符和整数数据的通用容器。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

1. buffer_handle_t

文件位置：system\core\include\system\window.h

typedef const native_handle_t* buffer_handle_t;

2. native_handle_t

文件位置：system\core\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] */
    int data[0];        /* numFds + numInts ints */
} native_handle_t;

 

显示Gralloc模块分配内存（buffer_handle_t、private_handle_t数据结构的关系）
kc58236582的博客
04-13 8046
这篇文章我们主要分析下显示中gralloc模块分配内存以及一些数据结构的介绍。 在博客http://blog.youkuaiyun.com/kc58236582/article/details/52681363中，我们分析过了从BufferQueueProducer的dequeueBuffer函数开始分配内存的流程。我们直接从如下开始分析。 分配内存流程 我们是调用了GraphicBufferAlloc
ANDROID ION_BUFFER
fangwei1993的博客
06-28 2216
android ion buf
Android buffer_handle_t的定义（转载）
weixin_30613343的博客
05-22 803
转自：http://www.cnblogs.com/eustoma/archive/2012/06/08/2541416.html 1. buffer_handle_t 文件位置：system\core\include\system\window.h typedef const native_handle_t* buffer_handle_t; 2. native_handle_t 文件...
DVSDK中的 Buffer_Handle结构
zhangjikuan的专栏
06-19 1160
会看到线程中有        Buffer_Handle       hOutBuf;
android display ： lcd buffer的打哪来到拿去
jet
03-16 1309
buffer handle跨进程传递
jgdu1981的专栏
02-21 1098
private_handle_t     int version;        /* sizeof(native_handle_t) */     int numFds;         /* number of file-descriptors at &data[0] */     int numInts;        /* number of ints at &data[numFds
Android display架构学习
Neil驱动的博客
12-26 2614
一、Linux FrameBuffer 设备 什么是framebuffer设备？ Documentation\fb\framebuffer.rst fbmem.c
android display 笔记（四）hardware 硬件抽象层
镇元子的博客
07-29 531
源码：android14硬件抽象层的接口定义在 hardware.h定义了以下三个结构体其中还有 hw_get_module方法，该方法用于获取模块第一个参数获取模块的 id，根据id查找对应库文件，匹配成功后通过第二个参数返回模块对象。
深入浅出CameraServer的Buffer管理机制
既不是天才，便做那疯子！
05-19 7032
文章目录概述 概述
Android下HWC以及drm_hwcomposer普法(上)
IT先森
05-29 4901
当VSync信号到来时，SurfaceFlinger被唤醒，处理Layer的新建，销毁和更新，并且为相应Layer设置期望的合成方式。所有Layer更新后，SurfaceFlinger调用validateDisplay，让HWC决定每个Layer的合成方式。
Android 源码分析 - 显示 - HAL层
luansxx的专栏
10-20 757
Android Graphic UI with GPU Hardware Acceleration 接口定义 源代码： hardware/libhardware/include/hardware/gralloc.h hardware/libhardware/include/hardware/fb.h gralloc_module_t（"gralloc"） alloc_device_t（"gpu0"） framebuffer_device_t（"fb0"） g
Android GDI 显示系统
姥姥教我学编程
09-16 995
第一章Android GDI之基本原理及其总体框架 Android GDI基本框架 在Android中所涉及的概念和代码最多，最繁杂的就是GDI相关的代码了。但是本质从抽象上来讲，这么多的代码和框架就干了一件事情：对显示缓冲区的操作和管理。    GDI主要管理图形图像的输出,从整体方向上来看,GDI可以被认为是一个物理屏幕使用的管理器。因为在实际的产品中，我们需要在物理屏幕上输出不同的窗
Android核心分析（25）------Android GDI之共享缓冲区机制
热门推荐
maxleng的专栏
06-14 3万+
Androird GDI之共享缓冲区机制 1  native_handle_t对private_handle_t 的包裹      private_handle_t是gralloc.so使用的本地缓冲区私有的数据结构，而Native_handle_t是上层抽象的可以在进程间传递的数据结构。在客户端是如何还原所传递的数据结构呢？首先看看native_handle_t对private_handle_t的抽象包装。 numFds= sNumFds=1; numInts= sNumInt
Android核心分析之(25)Android GDI之共享缓冲区机制
反思与改变
08-22 1308
Androird GDI之共享缓冲区机制 　　1  native_handle_t对private_handle_t 的包裹     private_handle_t是gralloc.so使用的本地缓冲区私有的数据结构，而Native_handle_t是上层抽象的可以在进程间传递的数据结构。在客户端是如何还原所传递的数据结构呢？首先看看native_handle_t对private_handle
android graphic(7)—gralloc分配图形缓冲区
shuwu
11-05 1558
http://blog.youkuaiyun.com/lewif/article/details/50703833 版权声明：本文为博主原创文章，未经博主允许不得转载。 目录(?)[+] mmap gralloc分配framebuffer图形缓冲区 gralloc分配普通图形缓冲区 Android中，HAL层的gralloc库负责了申请图形缓冲区的所有工作，HAL层之上的S
Android图形缓冲区映射过程源码分析
颇锐克
06-06 636
android图形缓冲区分配过程源码分析中介绍了图形buffer的分配过程，图形buffer可以从系统帧缓冲区分配也可以从内存中分配，分配一个图形buffer后还需要将该图形缓冲区映射到分配该buffer的进程地址空间来，在Android系统中，图形buffer的管理由SurfaceFlinger服务来负责，在Android SurfaceFlinger服务启动过程源码分析中我们了解到Surf
伯特说_终极笔记_备份
chouhuo6409的博客
07-30 500
数组和链表的区别 从逻辑结构来看 数组必须实现定义固定长度的元素，不能适应动态地增减的情况。当数据增加时，可能超出原先设定的元素个数；当数据减少时，造成内存浪费，数组可以根据下标直接存取。 链表动态地进行存储分配，可以使用数据动态地增减的情况，且可以方便地插入、删除数据...
linux多线程理解，附小例子
qq_40443457的博客
09-26 280
今天写了4部分内容： 在线程和进程的基础上，理解多线程是干什么的 相关函数 一个包含了2个线程的小例子 经常遇到的一个错误 一、首先，先来说几点关于线程、进程、多线程的理解： 一个cpu有多个核，通常情况下一个核心对应一个线程，就可以提高程序运行效率。有篇文章是这么比喻的：没有线程的多核CPU 就像是 多个人在一个桌子上吃饭，有时候出现争抢的情况 会降低效率。有多线程的多核CPU 就像是多个人...
HWCDisplay::HWCDisplay(CoreInterface *core_intf, BufferAllocator *buffer_allocator, 502 HWCCallbacks *callbacks, HWCDisplayEventHandler* event_handler, 503 qService::QService *qservice, DisplayType type, hwc2_display_t id, 504 int32_t sdm_id, DisplayClass display_class) 505 : core_intf_(core_intf), 506 callbacks_(callbacks), 507 event_handler_(event_handler), 508 type_(type), 509 id_(id), 510 sdm_id_(sdm_id), 511 qservice_(qservice), 512 display_class_(display_class) { 513 buffer_allocator_ = static_cast<HWCBufferAllocator *>(buffer_allocator); 514 }
最新发布
08-16
<think>我们正在分析HWCDisplayBuiltIn构造函数的实现，特别是成员初始化列表。根据用户提供的代码片段： ```cpp HWCDisplayBuiltIn::HWCDisplayBuiltIn(CoreInterface *core_intf, BufferAllocator *buffer_allocator, HWCCallbacks *callbacks, HWCDisplayEventHandler *event_handler, qService::QService *qservice, hwc2_display_t id, int32_t sdm_id) : HWCDisplay(core_intf, buffer_allocator, callbacks, event_handler, qservice, kBuiltIn, id, sdm_id, DISPLAY_CLASS_BUILTIN), buffer_allocator_(buffer_allocator), cpu_hint_(NULL), layer_stitch_task_(*this) { } ``` ### 1. 构造函数初始化列表详解 #### 1.1 基类初始化 首先，构造函数通过初始化列表调用基类`HWCDisplay`的构造函数： ```cpp HWCDisplay(core_intf, buffer_allocator, callbacks, event_handler, qservice, kBuiltIn, id, sdm_id, DISPLAY_CLASS_BUILTIN) ``` - **参数传递**：将传入的`core_intf`（核心接口指针）、`buffer_allocator`（缓冲区分配器）、`callbacks`（回调函数）、`event_handler`（事件处理器）、`qservice`（QService服务）以及显示器标识`id`和`sdm_id`（SDM层显示ID）传递给基类。 - **固定参数**： - `kBuiltIn`：表示显示器类型为内置（如手机屏幕）。 - `DISPLAY_CLASS_BUILTIN`：指定显示类别为内置。 #### 1.2 成员变量初始化 在基类初始化后，依次初始化派生类的成员变量： ```cpp buffer_allocator_(buffer_allocator), cpu_hint_(NULL), layer_stitch_task_(*this) ``` - **`buffer_allocator_(buffer_allocator)`**： - 将传入的`buffer_allocator`参数赋值给成员变量`buffer_allocator_`。 - 用途：管理图形缓冲区的分配与释放。 - **`cpu_hint_(NULL)`**： - 初始化`cpu_hint_`为`NULL`，表示初始状态下无CPU性能提示。 - 用途：后续可能用于设置CPU调度策略（如大核优先）。 - **`layer_stitch_task_(*this)`**： - 初始化`layer_stitch_task_`（图层拼接任务），并传入当前对象的引用（`*this`）。 - 用途：处理跨图层的拼接操作（如分屏显示）。 ### 2. 成员变量初始化规则 根据C++标准，成员变量的初始化顺序**严格遵循类定义中的声明顺序**，与初始化列表中的顺序无关[^3]。假设`HWCDisplayBuiltIn`类定义如下： ```cpp class HWCDisplayBuiltIn : public HWCDisplay { // 成员变量声明顺序 BufferAllocator *buffer_allocator_; CPUBoost *cpu_hint_; LayerStitchTask layer_stitch_task_; }; ``` 则初始化顺序为： 1. `buffer_allocator_` 2. `cpu_hint_` 3. `layer_stitch_task_` ### 3. 特殊成员初始化要求 #### 3.1 常量成员（`const`）与引用成员 - **常量成员**：必须在初始化列表中初始化（如`const int kMaxLayers = 16;`）[^4]。 - **引用成员**：同样必须在初始化列表中初始化（如`BufferQueue& mBufferQueue;`）[^4]。 #### 3.2 无默认构造函数的类成员 若类成员（如`LayerStitchTask`）没有默认构造函数，则必须在初始化列表中显式初始化[^4]。例如： ```cpp layer_stitch_task_(*this) // 调用LayerStitchTask的带参构造函数 ``` ### 4. 初始化列表 vs 构造函数体内赋值 | 特性 | 初始化列表 | 构造函数体内赋值 | |--------------------|-------------------------------|--------------------------| | **执行时机** | 进入构造函数体前 | 构造函数体内 | | **效率** | 直接构造（高效） | 先默认构造再赋值（低效） | | **适用成员** | 所有类型 | 非`const`/非引用类型 | | **强制要求成员** | `const`成员、引用成员、无默认构造的类成员 | 不可用 | > **示例对比**： > 若`layer_stitch_task_`在构造函数体内初始化： > ```cpp > HWCDisplayBuiltIn(...) : ... { > layer_stitch_task_ = LayerStitchTask(*this); // 错误！无默认构造函数 > } > ``` > 将导致编译失败，因为`LayerStitchTask`可能没有默认构造函数。 ### 5. 成员变量初始化过程总结 1. **基类构造**：调用`HWCDisplay`构造函数，建立显示基础能力。 2. **成员构造**： - `buffer_allocator_`：指向外部传入的缓冲区分配器。 - `cpu_hint_`：初始化为`NULL`（后续可能动态创建）。 - `layer_stitch_task_`：通过传入`*this`构造，绑定当前显示对象。 3. **构造函数体**：示例中为空，但可添加额外逻辑（如日志打印）。 ### 6. 关键设计意图 - **资源依赖传递**：通过初始化列表确保`buffer_allocator_`等关键资源在对象创建后立即可用。 - **任务绑定**：`layer_stitch_task_(*this)`实现显示对象与拼接任务的强关联。 - **安全初始化**：避免未初始化指针（如`cpu_hint_`设为`NULL`）导致的未定义行为。 --- ### 附录：完整初始化流程图示 ```mermaid sequenceDiagram participant Derived as HWCDisplayBuiltIn participant Base as HWCDisplay participant Member1 as buffer_allocator_ participant Member2 as cpu_hint_ participant Member3 as layer_stitch_task_ Note over Derived: 开始构造 Base->>Derived: 初始化基类（传递核心参数） Derived->>Member1: 初始化buffer_allocator_（指针赋值） Derived->>Member2: 初始化cpu_hint_(设为NULL) Derived->>Member3: 构造layer_stitch_task_（传入*this） Note over Derived: 进入构造函数体（示例中为空） ``` §§相关问题§§ 1. 为什么`layer_stitch_task_`需要在初始化列表中初始化？ 2. 如果`buffer_allocator_`是`const`成员，构造函数应如何修改？ 3. 基类`HWCDisplay`的构造函数可能执行哪些关键操作？ 4. `LayerStitchTask`对象为什么需要持有`HWCDisplayBuiltIn`的引用？</think>### HWCDisplay构造函数实现详解及成员变量初始化过程 #### 一、构造函数初始化流程 ```cpp HWCDisplayBuiltIn::HWCDisplayBuiltIn( CoreInterface *core_intf, BufferAllocator *buffer_allocator, HWCCallbacks *callbacks, HWCDisplayEventHandler *event_handler, qService::QService *qservice, hwc2_display_t id, int32_t sdm_id) : HWCDisplay( // 基类初始化 core_intf, buffer_allocator, callbacks, event_handler, qservice, kBuiltIn, id, sdm_id, DISPLAY_CLASS_BUILTIN), buffer_allocator_(buffer_allocator), // 成员初始化 cpu_hint_(NULL), layer_stitch_task_(*this) // 成员对象构造 { // 构造函数体（此处为空） } ``` #### 二、成员初始化关键步骤 1. **基类初始化（最先执行）** ```cpp : HWCDisplay(core_intf, buffer_allocator, ..., DISPLAY_CLASS_BUILTIN) ``` - 调用基类`HWCDisplay`的构造函数 - 传递显示器类型`kBuiltIn`（内置显示器） - 设置显示类别`DISPLAY_CLASS_BUILTIN` - **执行顺序**：基类初始化优先于派生类成员[^3] 2. **指针成员初始化** ```cpp buffer_allocator_(buffer_allocator), // 显式初始化 cpu_hint_(NULL) // 显式初始化为NULL ``` - `buffer_allocator_`：直接使用传入参数初始化 - `cpu_hint_`：安全初始化为空指针，避免野指针风险 - **必要性**：指针成员不自动初始化，必须显式设置[^4] 3. **对象成员构造** ```cpp layer_stitch_task_(*this) // 调用带参构造函数 ``` - 调用`LayerStitchTask`的构造函数并传入`*this`（当前对象） - **特殊要求**：若类无默认构造函数，必须在此初始化[^4] #### 三、初始化顺序规则 1. **严格顺序**（与声明顺序一致）： ```mermaid graph LR A[基类HWCDisplay] --> B[buffer_allocator_] B --> C[cpu_hint_] C --> D[layer_stitch_task_] ``` 2. **与初始化列表顺序无关**：即使写成`cpu_hint_(NULL), buffer_allocator_(...)`，实际仍按声明顺序执行[^3] #### 四、特殊成员处理 1. **`const`成员**：必须在初始化列表设置（如`const int mMaxLayers`） 2. **引用成员**：必须在初始化列表绑定（如`DisplayConfig& mConfig`） 3. **无默认构造的成员**：必须显式调用构造函数（如`layer_stitch_task_`）[^4] #### 五、与构造函数体赋值的区别 | 特性 | 初始化列表 | 构造函数体内赋值 | |--------------------|-------------------------------|--------------------------| | **执行时机** | 对象构造前 | 对象构造后 | | **效率** | 直接构造（高效） | 构造+赋值（额外开销） | | **`const`成员** | 支持初始化 | 不可赋值 | | **引用成员** | 支持绑定 | 不可重新绑定 | | **无默认构造成员** | 必须在此初始化 | 无法初始化 | > **示例**：若`layer_stitch_task_`在构造函数体内"初始化"： > ```cpp > // 错误示例！ > HWCDisplayBuiltIn(...) { > layer_stitch_task_ = LayerStitchTask(*this); // 需要先调用默认构造 > } > ``` > 将导致编译错误，因为`LayerStitchTask`可能没有默认构造函数[^4]。 #### 六、设计意图分析 1. **资源安全**： - `buffer_allocator_`直接传递，避免拷贝开销 - `cpu_hint_`显式置空，消除未初始化风险 2. **对象依赖**： - `layer_stitch_task_`持有`*this`，建立双向关联 3. **类型标识**： - 通过`kBuiltIn`和`DISPLAY_CLASS_BUILTIN`明确显示器类型 4. **扩展性**： - 空构造函数体为后续逻辑预留位置 ### 总结 HWCDisplayBuiltIn构造函数通过**初始化列表**： 1. 优先完成基类构造 2. 严格按声明顺序初始化成员 3. 安全处理特殊成员（指针/对象/常量） 4. 建立关键对象间依赖关系 5. 为内置显示器提供类型标识 这种模式确保了显示系统核心组件的可靠初始化，为后续的图层合成和显示控制奠定安全基础[^1][^4]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值