Systrace分析知识点
共 6571字，需浏览 14分钟
·
2023-06-20 10:46
和你一起终身学习，这里是程序员Android
经典好文推荐，通过阅读本文，您将收获以下知识点:
一、抓取Systrace
二、CPU模块知识点
三、input 点击事件处理流程
四、Vsync 事件处理
五、Android 绘制一帧流程分析
六、Camx Trace TAG开启方法
七、参考文献
一、抓取Systrace
1.1 使用手机抓取
使用Google 预留的开发者模式中的 系统跟踪 功能抓取systrace。
步骤：
设置--开发者模式--系统跟踪
trace文件保存路径：
/data/local/traces
手机抓取trace
抓取完之后使用adb 命令 pull 出来即可
C:\Users\ >adb pull /data/local/traces .
/data/local/traces/: 1 file pulled, 0 skipped. 95.1 MB/s (51342186 bytes in 0.515s)
C:\Users\ >
1.2 python 命令抓取
参考命令如下：
python systrace.py -o mynewtrace.html sched freq idle am wm gfx view binder_driver hal dalvik camera input res
比较麻烦，需要安装环境，不推荐，有成熟脚本除外。
二、CPU模块知识点
2.1 CPU频率，CPU loading 计算
CPU loading 计算公式
CPU 负载loading = Wall duration ÷ 选择CPU 个数÷ 选择CPU的范围
CPU Loading
2.2 Thread 在CPU中的状态
绿色：运行中 Running
对于在CPU上执行的进程，需要查看其运行时间、是否跑在该跑的核上、频率是否够等。浅绿色：可运行 Runnable
对于在等待序列中的进程，需要查看是否有过多任务在等待、等待时间是否过长等。白色：休眠中 Sleeping
这里一般是在等事件驱动。橘色：不可中断的睡眠态_IO_Block Uninterruptible Sleep | WakeKill - Block I/O
线程在I / O上被阻塞或等待磁盘操作完成。紫色：不可中断的睡眠态 Uninterruptible Sleep
线程在另一个内核操作（通常是内存管理）上被阻塞。
举例如下：
Thread 在CPU中的状态
2.3 CPU 唤醒关系查看
首先点击查看当前线程正在哪个 CPU 中运行
CPU 唤醒关系查看一
点击查看 Thread 的 箭头，既可以查看是被谁唤醒的
CPU 唤醒关系查看二
三、input 点击事件处理流程
3.1 Android 点击事件处理流程概览
SystemServer AppLaunch_dispatchPtr:Up 处理点击up事件
SystemServer 通过InputReader读取屏幕点击事件后，将点击事件通过InputDispatcher 进行分发
SystemServer OutboundQueue 接收存放即将派发给AppConnection 的点击事件
SystemServer WaitQueue接收存放已经派发给AppConnection ,但 App还在处理且没有返回成功的点击事件
Launcher deliverInputEvent: Launcher 桌面 被input事件唤醒
Camera APP bind 通过跟SystemServer bind 调用，开始启动Camera
3.2 Android 点击事件处理流程图
Android 点击事件处理流程图如下：
Android 点击事件处理流程图
3.2 Android 点击事件处理关键TAG
| TAG名字 | 所在进程 | 备注 |
|---|---|---|
| AppLaunch_dispatchPtr:Down | SystemServer | 点击Down事件 |
| AppLaunch_dispatchPtr:Up | SystemServer | 点击up事件 |
| InputReader | SystemServer | 点击事件读取 |
| InputDispatcher | SystemServer | 点击事件分发 |
| oq | SystemServer | OutBoundQueue 点击事件存放 |
| wq | SystemServer | WaitQueue 点击事件待消费返回 |
| deliverInputEvent | Launcher | app 点击事件消费 |
四、Vsync 事件处理
Vsync 信号可以由硬件产生，也可以用软件模拟，不过现在基本上都是硬件产生，负责产生硬件 Vsync 的是 HWC,HWC 可生成 VSYNC 事件并通过回调将事件发送到 SurfaceFlinger , DispSync 将 Vsync 生成由 Choreographer 和 SurfaceFlinger 使用的 VSYNC_APP 和 VSYNC_SF 信号
4.1 VSYNC_app信号app处理
第一阶段：
App 在收到 Vsync-App 的时候，在主线程进行 measure、layout、draw(构建 DisplayList , 里面包含 OpenGL 渲染需要的命令及数据) 。这里对应的 Systrace 中的主线程 doFrame 操作
第二阶段：
CPU 将数据上传（共享或者拷贝）给 GPU, 这里 ARM 设备 内存一般是 GPU 和 CPU 共享内存。这里对应的 Systrace 中的渲染线程的 flush drawing commands 操作
第三阶段：
通知 GPU 渲染，真机一般不会阻塞等待 GPU 渲染结束，CPU 通知结束后就返回继续执行其他任务，使用 Fence 机制辅助 GPU CPU 进行同步操作
第四 阶段：
swapBuffers，并通知 SurfaceFlinger 图层合成。这里对应的 Systrace 中的渲染线程的 eglSwapBuffersWithDamageKHR 操作
VSYNC_app信号处理流程如下：
VSYNC_app信号处理
4.2 VSYNC_sf 信号SF处理
第五阶段：
SurfaceFlinger 开始合成图层，如果之前提交的 GPU 渲染任务没结束，则等待 GPU 渲染完成，再合成（Fence 机制），合成依然是依赖 GPU，不过这就是下一个任务了.这里对应的 Systrace 中的 SurfaceFlinger 主线程的 onMessageReceived 操作（包括 handleTransaction、handleMessageInvalidate、handleMessageRefresh）SurfaceFlinger 在合成的时候，会将一些合成工作委托给 Hardware Composer,从而降低来自 OpenGL 和 GPU 的负载，只有 Hardware Composer 无法处理的图层，或者指定用 OpenGL 处理的图层，其他的 图层偶会使用 Hardware Composer 进行合成
第六阶段 ：
最终合成好的数据放到屏幕对应的 Frame Buffer 中，固定刷新的时候就可以看到了
VSYNC_sf 信号SF处理流程如下：
VSYNC_sf 信号SF处理
五、Android 绘制一帧流程分析
5.1 显示一帧流程概览
程序员Android
原图链接：
https://upload-images.jianshu.io/upload_images/5851256-5d802da2815c12f2.png
5.1.1 Android 显示一帧大致分为下面 八步：
App 接收到 vsync-app 信号后开始工作。
App 主线程被Message唤醒，执行onVsync。
App 执行 doFrame ，处理input、animation、traversal、draw等。
App UIThread 跟RenderThread sync 数据。
App 执行DrawFrame，从SurfaceFlinger(后续简称SF) 的 BufferQueue 中 Dequeue buffer，取出一个bufffer后，执行渲染绘制，接着将绘制好的Buffer 通过queuebuffer 放回到。BufferQueue中给 SF消费。
App queuebuffer 后, SF 中对应的 app buffer 会增加 +1。
Vsync-sf 到来后，SF 从BufferQueue 中 acquireBuffer一个Buffer 进行消费， 对应SF 中的 app buffer 会减 - 1 , SF 消费处理后，通过 releaseBuffer 将buffer 归还到BufferQueue 中。
SF 通过 bind 跟 Hardware Composer HAL(简称HWC) 进行通信，通过一些处理后显示到手机屏幕上。
5.2 生产者，消费者 BufferQueue 流转图
生产者，消费者 BufferQueue 流转图
原图链接：
https://upload-images.jianshu.io/upload_images/5851256-1fd0a4018940ddd8.png
dequeue(生产者发起) ：
当生产者需要缓冲区时，它会通过调用 dequeueBuffer() 从 BufferQueue 请求一个可用的缓冲区，并指定缓冲区的宽度、高度、像素格式和使用标记。queue(生产者发起)：
生产者填充缓冲区并通过调用 queueBuffer() 将缓冲区返回到队列。acquire(消费者发起) ：
消费者通过 acquireBuffer() 获取该缓冲区并使用该缓冲区的内容release(消费者发起) ：
当消费者操作完成后，它会通过调用 releaseBuffer() 将该缓冲区返回到队列
5.3 App ，SF Buffer 交互图
App ，SF Buffer 交互图
原图链接：
https://upload-images.jianshu.io/upload_images/5851256-9ee4c505abf5eff3.png
App 通过bind 向SF dequeuebuffer 进行buffer申请
SF 对端完成对bufferQueue 的dequeuebuffer的申请
App 处理合成完后，通过binder向SF queuebuffer 申请buffer 入队。
SF 对端通过queuebuffer 完成buffer 对BufferQueue的入队申请，供SF消费并显示到屏幕上
5.4 SF 跟 HWC 交互图
SurfaceFlinger 接受来自多个来源的数据缓冲区，对它们进行合成，然后发送到显示设备。
SF 送显图
原图链接：
https://upload-images.jianshu.io/upload_images/5851256-e2998c0cd7dd4219.png
SF 跟 HWC 交互图
原图链接：
https://upload-images.jianshu.io/upload_images/5851256-53d12f9bfef6809a.png
vsync-sf 周期到来，SF 开始绘制准备工作
SF 通过 acquirebuffer 从BufferQueue 中取出一帧进行消费
App 对应的BufferQueue 在SF acquirebuffer 后对那个的值会 -1
App 对应的buffer 值为 2
App 对应的buffer值 在SF acquirebuffer 后变为 1
SF 跟HWC 通过binder 通信处理完后，通过rleasebuffer将buffer 归还到BufferQueue中，紧接着一帧就可以显示出来
六、Camx Trace TAG开启方法
6.1 打开 Camx HAL 层 camx log tag
执行以下命令，打开camx trace log tag
adb root
adb remount
adb shell mkdir /vendor/etc/camera
adb shell rm -rf /vendor/etc/camera/camxoverridesettings.txt
adb shell touch /vendor/etc/camera/camxoverridesettings.txt
adb shell "echo traceGroupsEnable=0x10080 >> /vendor/etc/camera/camxoverridesettings.txt"
adb shell "echo traceErrorEnable=TRUE >> /vendor/etc/camera/camxoverridesettings.txt"
adb shell "echo traceOutputEnable=0x10080 >> /vendor/etc/camera/camxoverridesettings.txt"
adb shell cat /vendor/etc/camera/camxoverridesettings.txt
adb reboot
6.2 重启手机后打开kernel 的trace开关
重启后打开kernel trace 开关
adb root
adb remount
adb shell "echo 1 > /sys/kernel/tracing/events/camera/enable"
七、参考文献
【腾讯文档】Camera学习知识库
https://docs.qq.com/doc/DSWZ6dUlNemtUWndv
友情推荐：
至此，本篇已结束。转载网络的文章，小编觉得很优秀，欢迎点击阅读原文，支持原创作者，如有侵权，恳请联系小编删除，欢迎您的建议与指正。同时期待您的关注，感谢您的阅读，谢谢！
点击阅读原文，为大佬点赞！