1 前言 为了更深刻的理解Android图形系统抽象的概念和BufferQueue的工作机制,这篇文章我们将从Native Level入手,基于Android图形系统API写作一个简单的图形处理小程序.透过这个小程序我们将学习如何使用Native API创建Surface,如何请求图形缓冲区,如何向图形缓冲区中写入数据等知识.Talk is cheap, show me the code.让我们马上开始吧! 注:本系列文章的分析及代码均基于Android 12(S) Source Code,可参

Android显示之应用界面绘制 越到上层,跟业务关联越直接.代码就越繁杂.Android上层显示的代码正是如此.此外,java语言本身繁复的特点(比C语言多了满屏的try-catch,比C++少了析构处理的优雅简洁,和更高级的语言scala.python等就别比了),更加剧了这一现象. 直接去看代码,往往会看得一头雾水,知其然而不知其所以然.在这时候,就要把代码扔掉.细致去理清须要实现什么,怎么实现,画一幅架构设计图出来,然后再跟代码去对照. Android这部分代码并非圣经,有非常多待商榷的

原文  http://blog.csdn.net/yangwen123/article/details/12192401 FrameBuffer驱动程序分析 文中介绍了Linux系统下的显示驱动框架,每个显示屏被抽象为一个帧缓冲区,注册到FrameBuffer模块中,并在/dev/graphics目录下创建对应的fbX设备.Android系统在硬件抽象层中提供了一个Gralloc模块,封装了对帧缓冲区的所有访问操作.用户空间的应用程序在使用帧缓冲区之间,首先要加载Gralloc模块,并且获得一个

https://blog.csdn.net/yangwen123/article/details/12192401 FrameBuffer驱动程序分析文中介绍了Linux系统下的显示驱动框架,每个显示屏被抽象为一个帧缓冲区,注册到FrameBuffer模块中,并在/dev/graphics目录下创建对应的fbX设备.Android系统在硬件抽象层中提供了一个Gralloc模块,封装了对帧缓冲区的所有访问操作.用户空间的应用程序在使用帧缓冲区之间,首先要加载Gralloc模块,并且获得一个gral

1 前言 SurfaceFlinger作为Android图形显示系统处理逻辑的核心单元,我们有必要去了解其是如何启动,初始化及进行消息处理的.这篇文章我们就来简单分析SurfaceFlinger这个Binder系统服务的一些基本处理逻辑.接下来分两部分讲解: >> SurfaceFlinger启动与初始化 >> SurfaceFlinger消息队列处理机制 Tips: 本篇涉及的代码位置: /frameworks/native/services/surfaceflinger/ 2

必读: Android 12(S) 图形显示系统 - 开篇 一.前言 在前面的文章中,已经出现过 GraphicBuffer 的身影,GraphicBuffer 是Android图形显示系统中的一个重要概念和组件,顾名思义,它就是用来存储和传递需要绘制的图像数据的.GraphicBuffer 可以在应用程序和 BufferQueue 或 SurfaceFlinger 间传递. 本文及接下来的几篇文章,将聚焦分析 GraphicBuffer 创建的流程,相关组件.服务的基本架构和基本实现原理. 二

1. Linux内核提供了统一的framebuffer显示驱动,设备节点/dev/graphics/fb*或者/dev/fb*,以fb0表示第一个显示屏,当前实现中只用到了一个显示屏. 2. Android的HAL层提供了Gralloc,分为fb和gralloc两个设备.设备fb负责打开内核中的framebuffer以及提供post. setSwapInterval等操作,设备gralloc则负责管理帧缓冲区的分配和释放.上层只能通过Gralloc访问帧缓冲区,这样一来就实现了 有序的封装保护.

Android窗口系统 我们知道Android系统采用OpenGL来绘制3D图形,OpenGL ES提供了本地窗口(NativeWindow)的概念,无论是在Android平台中还是其他平台中,只要实现OpenGL ES中的本地窗口定义的接口,就可以利用OpenGL ES来绘制图形.由于Android系统所有服务都建立在C/S模式下,因此Android系统在实现OpenGL ES的本地窗口时仍然包括两种本地窗口,服务进程端的本地窗口定义为FramebufferNativeWindow,该本地窗口

1. android单实例运行方法 我们都知道Android平台没有任务管理器,而内部App维护者一个Activity history stack来实现窗口显示和销毁,对于常规从快捷方式运行来看都是startActivity可能会使用FLAG_ACTIVITY_NEW_TASK标记来打开一个新窗口,比如Launcher,所以考虑单任务的实现方法比较简单,首先Android123纠正下大家一种错误的方法就是直接在androidmanifest.xml的application节点中加入android

简介 本文讲解的内容是Android4.1以后的系统机制,将从整体上分析Android图形显示系统的结构,不深入分析每一层内部的代码实现,更多的是使用流程图和结构图来让大家理解Android是如何绘制.合成图形并显示到屏幕上. 本文将从三个层次进行讲解,大致如下图: 可以理解为上层生产,下层消费模型. 其中每一层之间的数据传递是使用Buffer(图形缓冲区)作为载体: 这里的缓冲区,大家可以理解为带有宽高和像素密度的内存区块. 1. 从下层往上层理解 1.1 显示屏 显示屏上的内容,是从硬件帧缓

1. android 单实例运行方法 我们都知道 Android 平台没有任务管理器,而内部 App 维护者一个 Activity history stack 来实现窗口显示和销毁,对于常规从快捷方式运行来看都是 startActivity 可能会使用 FLAG_ACTIVITY_NEW_TASK 标记来打开一个新窗口,比如 Launcher,所以考虑单任务的实现方法比较简单,首先 Android123 纠正下大家一种错误的方法就是直接在androidmanifest.xml 的 applica

1 前言 Android图形系统是系统框架中一个非常重要的子系统,与其它子系统一样,Android 框架提供了各种用于 2D 和 3D 图形渲染的 API供开发者使用来创建绚丽多彩的应用APP.图形渲染的 API的底层可与制造商的图形驱动程序实现代码交互,了解这些API的工作原理及图形系统框架层的处理逻辑可以帮助我们更好的使用这些功能. 本系列文章将侧重于图形系统BufferQueue的知识做分析讲解.BufferQueues 是 Android 图形组件之间的粘合剂,BufferQueue 类

1 前言 上一篇文章中我们已经创建了一个Native示例应用,从使用者的角度了解了图形显示系统API的基本使用,从这篇文章开始我们将基于这个示例应用深入图形显示系统API的内部实现逻辑,分析运作流程. 本篇将聚焦应用和SurfaceFlinger的活动,即应用是如何与SurfaceFlinger这个服务建立连接并进行通信的.让我们开始吧! 注:本篇涉及的代码位置: /frameworks/native/libs/gui/ /frameworks/native/libs/gui/include/g

题外话 刚刚开始着笔写作这篇文章时,正好看电视在采访一位92岁的考古学家,在他的日记中有这样一句话,写在这里与君共勉"不要等待幸运的降临,要去努力的掌握知识".如此朴实的一句话,此时此刻,正适合我们. 1 前言 回到前面的文章:Android 12(S) 图形显示系统 - 示例应用(二)  ,在上一篇文章中已经讲解了应用如何与SurfaceFlinger建立连接和通信,接下来就要去创建Surface了,当然在此之前,还有获取屏幕Display信息的操作,这不是关注的重点,先不展开讲解.

题外话 你有没有听见,心里有一声咆哮,那一声咆哮,它好像在说:我就是要从后面追上去! 写文章真的好痛苦,特别是自己对这方面的知识也一知半解就更加痛苦了.这已经是这个系列的第六篇了,很多次都想放弃了,但最终还是坚持下来了,因为我真的好像搞懂这一块. 1 前言 前面一篇文章中,我们已经介绍了createSurface的流程,也在SurfaceFlinger中去创建了图层layer,但一直没有看到buffer queue的踪影.其实,据我观察 Android 12 将BufferQueue的相关逻辑移

题外话 "行百里者半九十",是说步行一百里路,走过九十里,只能算是走了一半.因为步行越接近目的地,走起来越困难.借指凡事到了接近成功,往往是最吃力.最艰难的时段.劝人做事贵在坚持,有始容易,有终实难. 不多说了,希望自己能坚持写完这个系列 ...... 1 前言 在前几篇文章中,你应该已经看到文中有冒出来比较多的陌生的类,比如 Surface/SurfaceControl/ANativeWindow/ANativeWindowBuffer,这些类有什么作用?它们之间有什么关系?以及它们

题外话 最近总有一个感觉:在不断学习中,越发的感觉自己的无知,自己是不是要从"愚昧之巅"掉到"绝望之谷"了,哈哈哈 邓宁-克鲁格效应 一.前言 前面的文章中已经讲解了如何去创建一个Surface,也讲了一些操作Surface的知识,接下来就是如何利用这个Surface进行绘图呢? 在此开始讲解buffer queue的工作流程,看看图形数据是怎样流转的? 图形缓冲区的申请和消费流程是怎样的?有哪些核心类?等等问题在接下来的文章中陆续展开. 这篇文章中,先介绍一些基本

题外话 Covid-19疫情的强烈反弹,小区里检测出了无症状感染者.小区封闭管理,我也不得不居家办公了.既然这么大把的时间可以光明正大的宅家里,自然要好好利用,八个字 == 努力工作,好好学习 一.前言 这篇文章中,将详细讲解 生产者 -- 图形缓冲队列 -- 消费者 这个模型的的具体工作流程.我们还是从我们的demo运行流程着手. 可以再回头看看 Android 12(S) 图形显示系统 - 示例应用(二) 在demo示例中,我们获取buffer --> 填充数据 --> 送出显示的代码如下

题外话 疫情隔离在家,周末还在努力学习的我  ..... 一.前言 上一篇文章中,有基本讲清楚Producer一端的处理逻辑,最后也留下了一个疑问: Consumer是什么时候来消费数据的?他是自己主动来取的?还是收到了某种通知后再来处理的? 这篇文章,就带着这些疑问来开始分析源码.开头还是把这种流程图贴一下 二.Listener监听器的回调过程解析 生产者写完数据,把buffer还给buffer queue后,又是怎样通知消费者来使用的呢? 下面这些解析步骤,就是回答上面的问题 1. 生产者把

必读: Android 12(S) 图形显示系统 - 开篇 一.前言 因为个人工作主要是Android多媒体播放的内容,在工作中查看源码或设计程序经常会遇到调用API: static inline int native_window_api_connect(struct ANativeWindow* window, int api) static inline int native_window_api_disconnect(struct ANativeWindow* window, int a