Systrace分析知识点介绍

一、抓取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

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 流转图

dequeue(生产者发起) ：
当生产者需要缓冲区时，它会通过调用 dequeueBuffer() 从 BufferQueue 请求一个可用的缓冲区，并指定缓冲区的宽度、高度、像素格式和使用标记。

queue(生产者发起)：
生产者填充缓冲区并通过调用 queueBuffer() 将缓冲区返回到队列。

acquire(消费者发起) ：
消费者通过 acquireBuffer() 获取该缓冲区并使用该缓冲区的内容

release(消费者发起) ：
当消费者操作完成后，它会通过调用 releaseBuffer() 将该缓冲区返回到队列

5.3 App ，SF Buffer 交互图

App ，SF Buffer 交互图

App 通过bind 向SF dequeuebuffer 进行buffer申请

SF 对端完成对bufferQueue 的dequeuebuffer的申请

App 处理合成完后，通过binder向SF queuebuffer 申请buffer 入队。

SF 对端通过queuebuffer 完成buffer 对BufferQueue的入队申请，供SF消费并显示到屏幕上

5.4 SF 跟 HWC 交互图

SurfaceFlinger 接受来自多个来源的数据缓冲区，对它们进行合成，然后发送到显示设备。

SF 送显图

SF 跟 HWC 交互图

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"

 

审核编辑：刘清