【Android 性能优化】布局渲染优化 ( CPU 与 GPU 架构分析 | 安卓布局显示流程 | 视觉与帧率分析 | 渲染超时卡顿分析 | 渲染过程与优化 )

简介: 【Android 性能优化】布局渲染优化 ( CPU 与 GPU 架构分析 | 安卓布局显示流程 | 视觉与帧率分析 | 渲染超时卡顿分析 | 渲染过程与优化 )

文章目录

一、 CPU 在图形处理领域的情况

二、 CPU 与 GPU 架构对比

三、 Android 布局显示到屏幕流程

四、 人眼的视觉相关分析

五、 渲染超时卡顿分析

六、 渲染过程与优化





一、 CPU 在图形处理领域的情况


GPU 出现前 CPU 在图形处理领域的情况 :



① 承担工作多 : GPU 没有出现之前 , CPU 要承担很多工作 , 如逻辑运算 , 内存管理 , 显示控制 , 界面渲染 等操作 ;


② 设备弊端 : 不能显示复杂的图形 , 不能运行渲染逼真的游戏 , 如大型 3D 游戏等 ;


③ CPU 在图形领域的性能瓶颈 : CPU 即使超过 2GHz 的主频 , 其运算能力并不能完全发挥出来 , 无法显示复杂画面 , 不能提高图形绘制的质量 ;



鉴于上述 CPU 的各种弊端 , 就有了 GPU 的设计 , CPU 将显示相关的计算交给 GPU 完成 ;






二、 CPU 与 GPU 架构对比




CPU 与 GPU 架构 :



① 控制单元 ( 黄色部分 ) : 控制器 , 控制 CPU 运行工作 , 执行如 取出指令操作 , 控制其它模块运行 ;


② 计算单元 ( 绿色部分 ) : 算术逻辑单元 , 负责数学运算 , 逻辑运算 ;


③ 存储单元 ( 橙色部分 ) : Cache 高速缓存器 , DRAM , 用于存储 CPU 运算信息 ;




CPU 与 GPU 对比 :

image.png


① 逻辑算术运算 : 图像处理时 , 大量使用逻辑运算 , 如 RGB 像素值的位运算 ; GPU 的计算单元多于 CPU , 因此 GPU 的逻辑运算能力强于 CPU ;


② 程序执行逻辑 : CPU 中控制单元与存储单元功能强大 , 控制程序运行的能力远远高于 GPU ;


③ 总结 : GPU 适合用于大量的复杂的算术逻辑计算 , 如图像运算 , 声音运算等 ; CPU 适合用于控制系统 , 应用运行 ;






三、 Android 布局显示到屏幕流程


Android 布局显示到屏幕流程 :



① 定义布局中的组件 : 在 xml 布局文件中定义 ImageView 布局 ;


② 加载组件到内存 : 通过 LayoutInflater 将该 ImageView 组件解析成 ImageView 对象 , 加载到内存中 , 该对象中封装了组件位置 , 显示图片等信息 ;


③ CPU 处理 : 将上述 ImageView 对象进行计算处理 , 最终得到该组件对应的多维向量图形 ( 使用向量表示的图形 ) ;


④ GPU 处理 : GPU 接收上述多维向量图形 , GPU 将该向量图进行栅格化 , 将向量图转为位图 ( 矢量图转为像素图 ) , 计算出对应屏幕上每个像素点显示的值 ;


⑤ 显示器显示 : GPU 向显示器推送位图 , 会判定前面的 4 44 个步骤花费时间是否小于 16ms , 如果小于该值 , 那么就显示该位图 , 如果大于该值 , 那么不绘制 , 等待下一帧位图绘制完成 , 这是为了避免显示卡顿而设计的机制 , 虽然丢了一帧数据 , 但是显示很流畅 ;






四、 人眼的视觉相关分析


1 . Android 刷新帧率 :


① 最低流畅帧率 : 保持画面流畅的最低帧率是 60FPS , 当帧率低于 60 FPS 时 , 就会画面卡顿的感觉 ;


② 60 帧率对应的每一帧刷新间隔 : 1000 60 = 16.66 \dfrac{1000}{60} = 16.66

60

1000


=16.66 , 即每隔 16.66 毫秒刷新一次 ;


③ Android 设备刷新机制 : Android 中每隔 16ms 就会发出 VSYNC 信号通知屏幕该进行渲染 , 每次渲染的时间都必须小于 16 毫秒 , 才能保证 60 FPS 的帧率 ; 如果渲染时间大于 16 毫秒 , 就无法保证 60 FPS 的帧率, 此时就会造成卡顿 ;




2 . 人眼对于各个帧率的接受程度 :



① 12 FPS : 达到这个帧率 , 人眼可以认为该图像是连续的动作 , 如 GIF 图像 , 翻动作小人书等 ;


② 24 FPS : 初期的电影动画的帧率 , 勉强接收 ;


③ 30 FPS : 早期的电子游戏 , 要求高于电影 ;


上面的三种都是人与视频内容不交互 , 或少量交互 , 人感觉不出来卡顿 ;


④ 60 FPS : 在交互频繁的游戏中 , 低于 60 FPS , 是可以感觉出来的 , 因此动作类的游戏尽量都要达到 60 FPS ;


⑤ 60 FPS 以上 : 60 FPS 与 144 FPS 是等效的 , 人眼察觉不到这个差异 ;



打游戏时 , 感觉很卡 , 说明帧率低于 60 帧了 , 越低迟滞感越强烈 ;






五、 渲染超时卡顿分析


1. VSync 信号 : Android 每隔 16 毫秒发出 VSync 信号 , 屏幕接收到该信号时 , 开始显示渲染好的位图 , CPU 和 GPU 开始渲染新的图像 ;



2. 渲染与显示时间固定 : 渲染开始 与 屏幕绘制的时间都是固定的 , 就是 VSync 信号发出时间 , 并且其间隔必须是 16 毫秒 , 在固定的时间开始渲染 , 在固定的 16 毫秒之后 , 显示到屏幕中 , 这样就是固定的 60Hz 的屏幕刷新频率 ;



3. 渲染提前完成 : 渲染可以提早完成 , 如 CPU 和 GPU 在 10 毫秒时已经渲染完毕 , 将向量图栅格化后的位图传递给屏幕 , 此时等待 6 毫秒后 , 屏幕触发显示操作 , 将已经渲染完毕的位图显示出来 ;



4. 显然超时未完成 : 在某个固定的时间 , 开始渲染图片 , CPU , GPU 对布局组件对应画面进行渲染后 , 如果从开始渲染 , 到显示器显示之间的时间间隔超过了 16 毫秒 , 屏幕在 16 毫秒的时刻接收 VSync 信号触发显示 , 但是此时还处于渲染阶段 , 没有将位图传递给屏幕 , 因此仍然显示上一帧图片 , 这里就少了一帧 , 变成了 59 Hz 的刷新频率 , 如果这种超时很多 , 变成 40Hz , 30Hz , 那就非常卡了 ;




上图中应该绘制 4 帧数据 , 但是实际上只绘制了 3 帧 , 实际刷新率少了一帧 ;



image.png



六、 渲染过程与优化


1. 渲染耗时分析 : 在开始渲染到显示的 16 毫秒时间内 , 主要有 3 33 个比较大块的时间 , 3 33 个耗时操作分别与 CPU 和 GPU 相关 ;



① 布局转换工作 : CPU 将布局中的 UI 组件对象转为多维向量图形 ( 纹理 / 多边形 / 向量 ) ;


② 图像传递工作 : CPU 传递向量图形给 GPU , CPU 与 GPU 之间数据传递非常耗时 ;


③ 图像绘制工作 : GPU 将该向量图形转为由像素点组成的位图 ;




2. 渲染优化 : 优化这里有引出了布局渲染优化 , 从上述 3 33 个角度去进行渲染优化 :



① 布局转换优化 : 减少 CPU 将 UI 组件对象转为多维向量图形的耗时 ;


② 图像传递优化 : 减少 CPU 传递给 GPU 的图像数据 ;


③ 图像绘制优化 : GPU 会执行 CPU 传递过来的任何计算工作 , 即使出现了图像覆盖重绘 , GPU 也会照常执行 , 减少 GPU 的图像覆盖重绘 ;


相关实践学习
部署Stable Diffusion玩转AI绘画(GPU云服务器)
本实验通过在ECS上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。
目录
相关文章
|
9天前
|
监控
SMoA: 基于稀疏混合架构的大语言模型协同优化框架
通过引入稀疏化和角色多样性,SMoA为大语言模型多代理系统的发展开辟了新的方向。
25 6
SMoA: 基于稀疏混合架构的大语言模型协同优化框架
|
7天前
|
存储 NoSQL 分布式数据库
微服务架构下的数据库设计与优化策略####
本文深入探讨了在微服务架构下,如何进行高效的数据库设计与优化,以确保系统的可扩展性、低延迟与高并发处理能力。不同于传统单一数据库模式,微服务架构要求更细粒度的服务划分,这对数据库设计提出了新的挑战。本文将从数据库分片、复制、事务管理及性能调优等方面阐述最佳实践,旨在为开发者提供一套系统性的解决方案框架。 ####
|
16天前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
51 1
|
25天前
|
Android开发
Android面试之Activity启动流程简述
Android面试之Activity启动流程简述
70 6
|
26天前
|
监控 API 开发者
后端开发中的微服务架构实践与优化
【10月更文挑战第17天】 本文深入探讨了微服务架构在后端开发中的应用及其优化策略。通过分析微服务的核心理念、设计原则及实际案例,揭示了如何构建高效、可扩展的微服务系统。文章强调了微服务架构对于提升系统灵活性、降低耦合度的重要性,并提供了实用的优化建议,帮助开发者更好地应对复杂业务场景下的挑战。
21 7
|
23天前
|
XML 前端开发 Android开发
Android面试高频知识点(3) 详解Android View的绘制流程
Android面试高频知识点(3) 详解Android View的绘制流程
Android面试高频知识点(3) 详解Android View的绘制流程
|
26天前
|
消息中间件 Android开发 索引
Android面试高频知识点(4) 详解Activity的启动流程
Android面试高频知识点(4) 详解Activity的启动流程
25 3
|
27天前
|
XML 前端开发 Android开发
Android面试高频知识点(3) 详解Android View的绘制流程
Android面试高频知识点(3) 详解Android View的绘制流程
24 2
|
29天前
|
运维 监控 Serverless
利用Serverless架构优化成本和可伸缩性
【10月更文挑战第13天】Serverless架构让开发者无需管理服务器即可构建和运行应用,实现成本优化与自动扩展。本文介绍其工作原理、核心优势及实施步骤,探讨在Web应用后端、数据处理等领域的应用,并分享实战技巧。
|
29天前
|
Cloud Native API 持续交付
利用云原生技术优化微服务架构
【10月更文挑战第13天】云原生技术通过容器化、动态编排、服务网格和声明式API,优化了微服务架构的可伸缩性、可靠性和灵活性。本文介绍了云原生技术的核心概念、优势及实施步骤,探讨了其在自动扩展、CI/CD、服务发现和弹性设计等方面的应用,并提供了实战技巧。