和你一起终身学习,这里是程序员Android
经典好文推荐,通过阅读本文,您将收获以下知识点:
一、抓取Systrace
二、CPU模块知识点
三、input 点击事件处理流程
四、Vsync 事件处理
五、Android 绘制一帧流程分析
六、Camx Trace TAG开启方法
七、参考文献
使用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\ >
参考命令如下:
python systrace.py -o mynewtrace.html sched freq idle am wm gfx view binder_driver hal dalvik camera input res
比较麻烦,需要安装环境,不推荐,有成熟脚本除外。
CPU loading 计算公式
CPU 负载loading = Wall duration ÷ 选择CPU 个数÷ 选择CPU的范围
CPU Loading
绿色:运行中 Running
对于在CPU上执行的进程,需要查看其运行时间、是否跑在该跑的核上、频率是否够等。
浅绿色:可运行 Runnable
对于在等待序列中的进程,需要查看是否有过多任务在等待、等待时间是否过长等。
白色:休眠中 Sleeping
这里一般是在等事件驱动。
橘色:不可中断的睡眠态_IO_Block Uninterruptible Sleep | WakeKill - Block I/O
线程在I / O上被阻塞或等待磁盘操作完成。
紫色:不可中断的睡眠态 Uninterruptible Sleep
线程在另一个内核操作(通常是内存管理)上被阻塞。
举例如下:
Thread 在CPU中的状态
首先点击查看当前线程正在哪个 CPU 中运行
CPU 唤醒关系查看一
点击查看 Thread 的 箭头,既可以查看是被谁唤醒的
CPU 唤醒关系查看二
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
Android 点击事件处理流程图如下:
Android 点击事件处理流程图
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 的是 HWC,HWC 可生成 VSYNC 事件并通过回调将事件发送到 SurfaceFlinger , DispSync 将 Vsync 生成由 Choreographer 和 SurfaceFlinger 使用的 VSYNC_APP 和 VSYNC_SF 信号
第一阶段:
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信号处理
第五阶段:
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
原图链接:
https://upload-images.jianshu.io/upload_images/5851256-5d802da2815c12f2.png
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) 进行通信,通过一些处理后显示到手机屏幕上。
生产者,消费者 BufferQueue 流转图
原图链接:
https://upload-images.jianshu.io/upload_images/5851256-1fd0a4018940ddd8.png
dequeue(生产者发起) :
当生产者需要缓冲区时,它会通过调用 dequeueBuffer() 从 BufferQueue 请求一个可用的缓冲区,并指定缓冲区的宽度、高度、像素格式和使用标记。
queue(生产者发起):
生产者填充缓冲区并通过调用 queueBuffer() 将缓冲区返回到队列。
acquire(消费者发起) :
消费者通过 acquireBuffer() 获取该缓冲区并使用该缓冲区的内容
release(消费者发起) :
当消费者操作完成后,它会通过调用 releaseBuffer() 将该缓冲区返回到队列
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消费并显示到屏幕上
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 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
重启后打开kernel trace 开关
adb root
adb remount
adb shell "echo 1 > /sys/kernel/tracing/events/camera/enable"
【腾讯文档】Camera学习知识库
https://docs.qq.com/doc/DSWZ6dUlNemtUWndv
友情推荐:
Android 开发干货集锦
至此,本篇已结束。转载网络的文章,小编觉得很优秀,欢迎点击阅读原文,支持原创作者,如有侵权,恳请联系小编删除,欢迎您的建议与指正。同时期待您的关注,感谢您的阅读,谢谢!
点击阅读原文,为大佬点赞!