自建APM之卡顿优化

卡顿介绍及优化工具选择

CPU Profiler
Systrace
StrictMode

背景介绍

很多性能问题不易被发现，但是卡顿很容易被直观感受
卡顿问题难以定位

卡顿问题难在哪里

产生原因错综复杂：代码、内存、绘制、IO？
不易复现：当时场景强相关

CPU Profiler

图形展示执行时间、调用栈
信息全面，包含所有线程
运行时开销严重，整体都会变慢（带偏优化方向）

TraceView和Systrace

StrictMode

严苛模式，Android提供的一种运行时检测机制
方便强大，容易被忽略
包含：线程策略和虚拟机策略检测

线程策略：
自定义的耗时操作，detectCustomSlowCalls()
磁盘读取操作，detectDiskReads
网络请求，detectNetwork

虚拟机策略：
Activity泄漏，detectActivityLeaks()
Sqlite对象泄漏，detectLeakedSqlLiteObjects()
检测实例数量，setClassInstanceLimit()

自动化卡顿检测方案及优化

自动化卡顿检测方案原理

为什么需要自动化检测方案？

• 系统工具适合线下针对性分析
• 线上及测试环节需要自动化检测方案

方案原理

• 消息处理机制，一个线程只有一个Looper
• mLogging对象在每个message处理前后被调用
• 主线程发生卡顿，实在dispatchMessage执行耗时操作

具体实现

• Looper.getMainLooper().setMessageLogging();
• 匹配>>>>Dispatching,阈值时间后执行任务（获取堆栈信息）
• 匹配<<<<Finished,任务启动之前取消掉

AndroidPerformanceMonitor

• 非侵入式的性能监控组件，通知形式弹出卡顿信息
• com.github.markzhai:blockcanary-android
• https://github.com/markzhai/AndroidPerformanceMonitor

BlockCanary.install(this,new BlockCanaryContext()).start();

方案总结

• 非侵入式
• 方便精准，定位到代码的某一行

自动化检测方案问题

• 确实卡顿了，但是卡顿堆栈可能不准确
• 和OOM一样，最后的堆栈只是表象，不是真正问题

自动检测方案优化

• 获取监控周期内的多个堆栈，而不是最后一个
• startMonitor->高频采集堆栈->endMonitor->记录多个堆栈->上报

海量卡顿堆栈处理

• 高频卡顿上报太大，服务端有压力
• 分析：一个卡顿下多个堆栈大概率有重复
• 解决：对一个卡顿下堆栈进行hash排重，找出重复堆栈
• 效果：极大的减少展示量同时更高效找到卡顿堆栈

总结
自动化卡顿检测方案
问题及优化思路

ANR分析与实战

ANR介绍与实战</