文章目录
- 一、从XML到屏幕上的展示
- 造成跳帧的因素有那些
- 发现问题
- 定位问题
- 定位代码
一、从XML到屏幕上的展示
-
数据加载阶段
-
数据控制阶段
-
数据展示阶段
xml —> view
onCreat —> 解析layout.xml
resume —> view —> wms
ViewRootImpl
UI 绘制流程 ：测量 —> 布局 —> 绘制
处理数据（CPU业务数据范围）
Android当中数据的生产依托两个硬件 ：CPU/GPU
CPU处理的最常规的代码调用（指令），比如IO/线程/对象的分配
GPU处理图像数据的生成（算术）
Canvas是作为当前Android中的图像生产者
canvas.draw —> native —> C++ —> skia/opengl —> GPU的调用处理
Android Surface —> Java 画面的宽度 - 外框数据
Surface —> native canvas产生的图像数据是保存在底层的这个里面
canvas.draw
native这里给了一个队列空间，里面的空间是给Surface 使用
SurfaceFilnger Android真正和硬件沟通（调用驱动代码），给硬件（屏幕）提供数据
数据交给屏幕 —> 显示
FrameBuffer 帧缓冲区（驱动提供的一个容器）
设备性能因素问题
- CPU/GPU（制图速度）
1秒钟可以生成多少张图像数据
FPS —> 帧率 - 屏幕（刷新率）
1秒钟能支撑多少次的图像变更
Android肯定不能放任随便推数据或者更新数据
需要节奏
vsync =垂直同步信号
1次刷新帧缓冲区的时机
SF —> 按自己的节奏去固定更新帧缓冲区
1秒 60帧的节奏刷新
1秒 = 1000ms
1000/60 = 16.66ms
SF —> 16.66ms启动一次帧缓冲区刷新
固定在刷新前判断图像数据是否准备好 —> 推送刷新
编舞者 - Choreographer 控制节奏
SurfaceFilnger 在发送垂直同步信号时不会去管其他人的因素
16.66ms节点，同时数据准备完成，刷新数据，没到16.66ms节点和过了节点都不更新
卡顿就是跳帧造成的
16ms主要处理两件事
- 将UI对象转换成多边形和纹理
- CPU传递数据到GPU，GPU进行绘制
造成跳帧的因素有那些
常规因素：
层级
过度绘制问题
写代码所造成的问题——卡顿原因不大
核心因素
- 内存引起的
- 线程引起的
STW停顿时间 Stop The World 停止所有工作线程，清理内存
等待时间片段
IO阻塞时间
锁阻塞时间
卡顿的本质是因为错过了垂直同步信号的时间
影响
- 常规影响
层级以及过度绘制导致 - 内存影响
STW现象导致（时间或是定义view的绘制时，new对象） - 线程影响
阻塞当前主线程的代码都会造成卡顿
发现问题
IT基础:内存管理，线程管理，网络，算法
android: 通信机制+andorid内部支撑他运作的多个进程之间的写作问题
定位问题
systrace ： 找事故原因
大面积呈现状态：
大面积绿色：代码的时机运行时间确实超过了
层级多，代码里面写了耗时的，绘制出问题了
大面积紫色：代码里面有高频生产对象的代码（事件、draw）
大面积灰色：有锁的问题
大面积蓝色：系统资源不够
大面积橙色：有IO问题出现
定位代码
blockcannary
制图速度高于刷新速度就会出现
制图速度跟不上刷新速度
