Android卡顿优化

卡顿的定义

如果在一个Vsync周期内(60HZ的屏幕上就是16.6ms),按照整个上帧显示的执行的顺序来看,应用UI线程的绘制、RenderThread线程的渲染、SurfaceFlinger/HWC的图层合成以及最终屏幕上的显示这些动作没有全部都执行完成的话,屏幕上就会显示上一帧画面的内容,也就是掉帧,而人的肉眼就可能会感觉到画面卡顿。

卡顿监控
线下监控工具

BlockCanary: 动态检测消息执行耗时。

基于消息机制,向Looper中设置Printer,监控dispatcher到finish之间的操作,满足耗时阀值dump堆栈、设备信息,以通知形式弹出卡顿信息以供分析。
在这里插入图片描述其中最核心的两步是在调用msg.target.dispatchMessage(msg),进行消息的分发前记录时间T1,调用msg.target.dispatchMessage(msg)进行消息分发后记录时间T2,如果T2-T1大于设置的卡顿阈值就会打印当前方法调用堆栈以及显示其他相关提示或打印日志;
blockcanary充分的利用了Loop的机制,在MainLooper的loop方法中执行dispatchMessage前后都会执行printer的println进行输出,并且提供了方法设置printer。通过分析前后打印的时差与阈值进行比对,从而判定是否卡顿。

创建AppBlockCanaryContext:

class AppBlockCanaryContext : BlockCanaryContext() {
    
    
}

在application中初始化blockCanary:

BlockCanary.install(this, AppBlockCanaryContext()).start()

BlockCanary会在发生卡顿(通过MonitorEnv的getConfigBlockThreshold设置)的时候记录各种信息,输出到配置目录下的文件,并弹出消息栏通知(可关闭)。

dump的信息包括:

基本信息:安装包标示、机型、api等级、uid、CPU内核数、进程名、内存、版本号等
耗时信息:实际耗时、主线程时钟耗时、卡顿开始时间和结束时间
CPU信息:时间段内CPU是否忙,时间段内的系统CPU/应用CPU占比,I/O占CPU使用率
堆栈信息:发生卡慢前的最近堆栈,可以用来定位卡慢发生的地方和重现路径

滴滴Dokit接入
https://xingyun.xiaojukeji.com/docs/dokit#/intro
在这里插入图片描述帧率检测:帧率信息提供波形图查看功能,让帧率监控的趋势更加明显。

在这里插入图片描述CPU检测:CPU 使用率信息提供波形图查看功能,让 CPU 监控的趋势更加形象。

在这里插入图片描述卡顿检测:我们做App开发时,可能会遇到卡顿的情况,往往会忽略,而且复现时出现卡顿的概率也挺挺小的。而卡顿功能帮助我们把App出现的卡顿记录下来,锁定 App 出现卡顿的时刻,打印出对应的代码调用堆栈。
在这里插入图片描述线上监控工具
https://www.tingyun.com/tingyun-apm

基调听云APM(应用性能管理)产品能够提供代码级性能监控并对故障快速定位,能够兼容OpenTelemetry框架实现全量采集,支持微服务架构下的应用性能监控和治理。

大致工作流程:
1、首先在客户端(Android、iOS、Web等)采集数据;
2、接着将采集到的数据整理上报到服务器;
3、服务器接收到数据后建模、存储、挖掘分析,让后将数据可视化,供用户使用。

Android APM 的原理其实非常简单,用一句话总结就是:

依据打包原理,在 class 转换为 dex 的过程中,调用 gradle transform api 遍历 class 文件,借助 Javassist、ASM 等框架修改字节码,插入我们自己的代码实现性能数据的统计。以上所有过程都是在编译期完成的。

猜你喜欢

转载自blog.csdn.net/qq_24252589/article/details/131343448