往期知识点整理
- 鸿蒙(HarmonyOS)北向开发知识点记录~
- 【鸿蒙实战开发】ArkTS多线程的多线程系列(一):ArkTS多线能力入门
- 【鸿蒙实战开发】ArkTS多线程的多线程系列(二):基于Sendable共享对象实现跨线程通信及UI状态刷新
- 【鸿蒙实战开发】ArkTS多线性的多线程系列(三):基于单例实现跨线程缓存
- 【鸿蒙实战开发】ArkTS多线程的多线程系列(四):基于生产者-消费者实现多线程协同
- 【鸿蒙实战开发】ArkTS多线程的多线程系列(五):通过子线程实现全局弹窗
- 【鸿蒙UI实战开发】基于List和Scroller由简单到复杂列表布局开发实践
- 【鸿蒙UI实战开发】基于原生能力的键盘控制
- 【鸿蒙UI实战开发】基于ArkUI现有能力实现自定义弹窗封装方案
- 【鸿蒙实战开发】Native保存图片到应用沙箱
- 【鸿蒙实战开发】基于加解密算法框架的常见规格问题
- 【鸿蒙实战开发】图片选择和下载保存案例
- 【鸿蒙实战开发】折叠屏扫描二维码方案
- 【鸿蒙实战开发】关于图像撕裂、掉帧等异常现象的原理以及优化方案
- 持续更新中……
屏幕显示原理:
屏幕显示是通过类似逐行扫描而把图像显示到屏幕上,而其在底层则是通过一个帧缓存区映射到屏幕显示器上的。也就是通过CPU对图像的数据进行处理,交给显示处理器,显示处理器再处理成图像数据存储到帧缓冲区等待视频控制器的信号,将帧缓冲区的内容同步到显示器。
异常场景:
- 图像撕裂:
假设显示器的刷新率是60Hz,但是显卡每秒能够画120张图片。显卡每一秒往帧缓存器放120张图片,但是显示器每秒只能拿走60张,两者之间又没有沟通,显示器不知道显卡很强,显卡也不知道显示器速度太慢,一直往帧缓存器里写,等它写满了帧缓存器,就用新的图片从头覆盖,于是,显示器还没来得及拿走的图片,就被显卡重新覆盖掉了。结果就是,画面呈现到一半,下面的跟上面的画面完全对不上。
- 跳帧:
如果显卡速度更快那么下一帧的图像还没来得及显示,下下一帧的数据就覆盖上来了,中间这帧就跳过了。
- 图像缺失:
如果显卡帧率小于显示器刷新率,那每次在屏幕上看到的可能不是完整的图形,每次看到的图形比上次更完整一些。
- 掉帧:
当GPU渲染速度小于屏幕刷新速度时,则屏幕将会继续绘制上一帧画面,这样就会导致画面掉帧(也就是卡顿)的现象。
优化方案:
针对图像撕裂,跳帧问题HarmonyOS采用与业界对标的垂直同步信号(Vsync信号)解决,原理是让显卡适应显示器的刷新率,如果显示器刷新来不及,就让显卡等一等。
针对图像缺失,画面闪烁问题,又在Vsync信号的基础上,增加了双缓冲机制。 但是双缓冲机制会导致频繁掉帧,CPU资源浪费等问题。
针对频繁掉帧现象又引进了三缓冲机制,大大降低掉帧概率并提高CPU效率。
- Vsync 信号:
Vsync 信号一般是由硬件(屏幕)产生的,每个 Vsync 信号之间的时间,就是每一帧生产 / 消费的间隙。
为了把显示器的显示和系统视频控制器同步,显示器会用硬件时钟产生一系列定时信号。当扫描到换行时,显示器会发出一个水平同步信号HSync。当一帧画面绘制完成后,扫描回复到原位,再准备绘制下一帧前,显示器会发出一个垂直同步信号VSync。显示器通常以VSync信号的频率来刷新。此时CPU计算好画面数据并提交到GPU,GPU渲染完成后将渲染结果放入帧缓冲区,随后视频控制器就会按照VSync信号逐行读取帧缓冲区的数据,然后在显示器上显示。
- 双缓冲机制:
GPU 开辟A、B两个缓冲区,并对缓冲区进行同步加锁处理,执行流程就是当A缓冲区拿到第一帧数据,就给A缓冲区加上一把锁,屏幕控制器从A拿到数据并逐行扫描完成,A帧缓冲区解锁,并把屏幕控制器指向B缓冲区,B缓冲区加锁并逐行扫描显示,在屏幕控制器扫描B缓冲区的时候,A缓冲区拿到GPU传过来的新数据,以此类推。
通过上述图片可以看出,双缓冲区+垂直同步会解决图像显示不全的问题,但是A图像本来应该显示一帧,但是由于GPU与CPU处理速度太慢导致了A的这一帧显示了两次,从而导致B晚一帧显示出来,这就导致了新问题掉帧,掉帧并不是丢失图片,而是屏幕重复渲染了同一帧数据。
另外也可以看出来期间存在CPU资源浪费,双缓冲只会提供两个Buffer,B被GPU处理占用,A正在用显示,那么在第二个16ms里面,CPU就无法获取到Buffer处理UI更新,在Jank的阶段空空等待。而且,一般出现这种场景都是连续的:比如复杂视觉效果,那么GPU可能会一直超负荷,CPU一直跟GPU抢Buffer,这样带来的问题就是滚雪球似的掉帧,一直浪费,完全没有利用CPU与GPU并行处理的效率,成了串行处理。为了解决该问题提出了三缓冲概念。
- 三缓冲机制:
多增加一个Buffer给CPU用,让它提前忙起来,这样就能做到三方都有Buffer可用,CPU不用跟GPU争一个Buffer,真正实现并行处理。
如上图所示,虽然即使每帧需要的时间都超出了预期,但是由于多加了一个Buffer,实现了CPU跟GPU并行,便可以做到了只在开始掉一帧,后续却不掉帧,双缓冲充分利用16.67ms(一般60hz的刷新率,对应每隔16.667ms就会刷新一次)做到低延时,并保障了其稳定性。
总是有很多小伙伴反馈说:鸿蒙开发不知道学习哪些技术?不知道需要重点掌握哪些鸿蒙开发知识点? 为了解决大家这些学习烦恼。在这准备了一份很实用的鸿蒙全栈开发学习路线与学习文档给大家用来跟着学习。
针对一些列因素,整理了一套纯血版鸿蒙(HarmonyOS Next)全栈开发技术的学习路线,包含了鸿蒙开发必掌握的核心知识要点,内容有(OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、OpenHarmony驱动开发、系统定制移植……等)技术知识点。
《鸿蒙 (Harmony OS)开发学习手册》(共计892页):https://gitcode.com/HarmonyOS_MN/733GH/overview
如何快速入门?
1.基本概念
2.构建第一个ArkTS应用
3.……
开发基础知识:
1.应用基础知识
2.配置文件
3.应用数据管理
4.应用安全管理
5.应用隐私保护
6.三方应用调用管控机制
7.资源分类与访问
8.学习ArkTS语言
9.……
基于ArkTS 开发
1.Ability开发
2.UI开发
3.公共事件与通知
4.窗口管理
5.媒体
6.安全
7.网络与链接
8.电话服务
9.数据管理
10.后台任务(Background Task)管理
11.设备管理
12.设备使用信息统计
13.DFX
14.国际化开发
15.折叠屏系列
16.……
鸿蒙开发面试真题(含参考答案):https://gitcode.com/HarmonyOS_MN/733GH/overview
OpenHarmony 开发环境搭建
《OpenHarmony源码解析》:https://gitcode.com/HarmonyOS_MN/733GH/overview
- 搭建开发环境
- Windows 开发环境的搭建
- Ubuntu 开发环境搭建
- Linux 与 Windows 之间的文件共享
- ……
- 系统架构分析
- 构建子系统
- 启动流程
- 子系统
- 分布式任务调度子系统
- 分布式通信子系统
- 驱动子系统
- ……