前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Android卡顿优化 | 自动化卡顿检测方案与优化(AndroidPerformanceMonitor / BlockCanary)

Android卡顿优化 | 自动化卡顿检测方案与优化(AndroidPerformanceMonitor / BlockCanary)

作者头像
凌川江雪
发布2020-04-09 15:50:25
2.5K0
发布2020-04-09 15:50:25
举报
文章被收录于专栏:李蔚蓬的专栏李蔚蓬的专栏

本文要点

  • 为何需要自动化检测方案
  • 自动卡顿检测方案原理
  • 看一下Looper.loop()源码
  • 实现思路
  • AndroidPerformanceMonitor实战
  • 基于AndroidPerformanceMonitor源码简析
  • 接下来我们讨论一下方案的不足
  • 自动检测方案优化

项目GitHub

为何需要自动化检测方案

  • 前面提到过的系统工具只适合线下针对性分析,无法带到线上!
  • 线上及测试环节需要自动化检测方案

方案原理

  • 源于Android的消息处理机制; 一个线程不管有多少Handler,只会有一个Looper存在, 主线程中所有的代码,都会通过Looper.loop()执行;
  • loop()中有一个**mLogging**对象, 它在每个**Message**处理前后都会被调用:
  • 如果主线程发生卡顿, 一定是在**dispatchMessage**执行了耗时操作!

Handler机制图

由此,我们便可以通过**mLogging**对象 对**dispatchMessage**执行的时间进行监控;

看一下Looper.loop()源码

代码语言:javascript
复制
    public static void loop() {
        final Looper me = myLooper();
        if (me == null) {
            throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
        }
        final MessageQueue queue = me.mQueue;

        // Make sure the identity of this thread is that of the local process,
        // and keep track of what that identity token actually is.
        Binder.clearCallingIdentity();
        final long ident = Binder.clearCallingIdentity();

        // Allow overriding a threshold with a system prop. e.g.
        // adb shell 'setprop log.looper.1000.main.slow 1 && stop && start'
        final int thresholdOverride =
                SystemProperties.getInt("log.looper."
                        + Process.myUid() + "."
                        + Thread.currentThread().getName()
                        + ".slow", 0);

        boolean slowDeliveryDetected = false;

        for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }

            // This must be in a local variable, in case a UI event sets the logger
            final Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }

            final long traceTag = me.mTraceTag;
            long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;
            long slowDeliveryThresholdMs = me.mSlowDeliveryThresholdMs;
            if (thresholdOverride > 0) {
                slowDispatchThresholdMs = thresholdOverride;
                slowDeliveryThresholdMs = thresholdOverride;
            }
            final boolean logSlowDelivery = (slowDeliveryThresholdMs > 0) && (msg.when > 0);
            final boolean logSlowDispatch = (slowDispatchThresholdMs > 0);

            final boolean needStartTime = logSlowDelivery || logSlowDispatch;
            final boolean needEndTime = logSlowDispatch;

            if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
                Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
            }

            final long dispatchStart = needStartTime ? SystemClock.uptimeMillis() : 0;
            final long dispatchEnd;
            try {
                msg.target.dispatchMessage(msg);
                dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
            } finally {
                if (traceTag != 0) {
                    Trace.traceEnd(traceTag);
                }
            }
            if (logSlowDelivery) {
                if (slowDeliveryDetected) {
                    if ((dispatchStart - msg.when) <= 10) {
                        Slog.w(TAG, "Drained");
                        slowDeliveryDetected = false;
                    }
                } else {
                    if (showSlowLog(slowDeliveryThresholdMs, msg.when, dispatchStart, "delivery",
                            msg)) {
                        // Once we write a slow delivery log, suppress until the queue drains.
                        slowDeliveryDetected = true;
                    }
                }
            }
            if (logSlowDispatch) {
                showSlowLog(slowDispatchThresholdMs, dispatchStart, dispatchEnd, "dispatch", msg);
            }

            if (logging != null) {
                logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
            }

            // Make sure that during the course of dispatching the
            // identity of the thread wasn't corrupted.
            final long newIdent = Binder.clearCallingIdentity();
            if (ident != newIdent) {
                Log.wtf(TAG, "Thread identity changed from 0x"
                        + Long.toHexString(ident) + " to 0x"
                        + Long.toHexString(newIdent) + " while dispatching to "
                        + msg.target.getClass().getName() + " "
                        + msg.callback + " what=" + msg.what);
            }

            msg.recycleUnchecked();
        }
    }
  • 里边有一个for循环,

会不断地读取消息队列队头进行处理:

  • 处理之前,会调用**logging.println()**

执行之后再次调用

我们可以从打印日志的前缀来判断Message处理的**开始**和**结束**;

实现思路

  • 通过**Looper.getMainLooper().setMessageLogging();**, 来设置我们自己的Logging; 这样每次Message处理的前后, 调用的就是我们自己的Logging;
  • 如果匹配到**>>>>> Dispatching**, 我们就可以执行一个代码, 即在指定的阈值时间之后, 在子线程中开始执行一个【获取当前子线程的堆栈信息以及当前的一些场景信息(如内存大小、变量、网络状态等)】的任务;

如果匹配到**<<<<< Finished**,

则说明在指定的阈值时间内,Message被执行完成,没有发生卡顿,

那便将这个任务取消掉;

AndroidPerformanceMonitor实战

  • AndroidPerformanceMonitor原理:便是上述的实现思路和原理;
  • 特性1:非侵入式的**性能监控组件**, 可以用**通知的方式** 弹出卡顿信息,同时用**logcat**打印出关于卡顿的详细信息; 可以检测所有线程中执行的任何方法,又不需要手动埋点, 设置好阈值等配置,就“坐享其成”,等卡顿问题“愿者上钩”!!
  • 特性2:方便精确,可以把问题定位到代码的具体某一行!!!

【方案的**不足** 以及**框架源码解析** 在下面实战之后总结!!】

实战开始---------------------------------------------------
  • 库的依赖:implementation 'com.github.markzhai:blockcanary-android:1.5.0'
  • 库的主页:https://github.com/markzhai/AndroidPerformanceMonitor
  • 在项目中引入依赖后, 在Application进行初始化, BlockCanary.install(this, new AppBlockCanaryContext()).start(); 第一个参数是**上下文**, 第二个参数是需要传入一个**Block的配置类实例**【BlockCanaryContext类实例或者其子类实例】:
代码语言:javascript
复制
public class TestApp extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        ...

        //AndroidPerformanceMonitor测试
        BlockCanary.install(this, new AppBlockCanaryContext()).start();

    }
}    
  • AppBlockCanaryContext**是我们自定义的类,** 配置了**BlockCanary**的各种信息, 代码较多,可以看下GitHub,这里就不贴全部代码了~ 下面两个配置方法分别是 给出一个**uid**,可以用于在上报时上报**当前的用户信息**; 第二个是自定义**卡顿的阈值时间**,过了阈值便认为是卡顿, 这里指定的是**500ms**;
代码语言:javascript
复制
    /**
     * Implement in your project.
     *
     * @return user id
     */
    public String provideUid() {
        return "uid";
    }

    /**
     * Config block threshold (in millis), dispatch over this duration is regarded as a BLOCK. You may set it
     * from performance of device.
     *
     * @return threshold in mills
     */
    public int provideBlockThreshold() {
        return 500;
    }
  • 接着在**MainActivity**的**onCreate()**中, 让主线程沉睡两秒(2000ms > 设定的阈值500ms);
  • 运行时,因为主线程停滞时间超过既定阈值, 组件会认为其卡顿并且弹出通知!! 当然Android8.0以后比较麻烦, 因为notificationManager需要配置Channel等才能用, 或者允许**后台弹出界面**,

桌面上便会出现这个图标:

进去之后就可以看到了相应的信息了:

当然,我们可以在logcat中定位关键词**blockInfo**,

看到同样的详细的信息:

如上,

Block框架打印出来了【当前子线程的**堆栈信息**以及当前的一些**场景信息**(如内存大小、变量、网络状态等)】,

time-start time-end**的**时间间隔**又可以知道**阻塞的时间**,如上图展示出来的,正是我们设置的**2秒**!!!!**

也可以看到**uid键**的值 便是我们刚刚设定的**字符串“uid”**;

同时还直接帮我们定位到**卡顿问题的出处**!!!

可见得BlockCanary已然 成功检测到**卡顿**问题的各种具体信息了!!!

基于AndroidPerformanceMonitor源码简析

由于篇幅原因,笔者把以下解析内容提取出来单独作一篇博客哈~

目录 1. 监控周期的 定义 2. dump模块 / 关于.log文件 3. 采集堆栈周期的 设定 4. 框架的 配置存储类 以及 文件系统操作封装 5. 文件写入过程(生成.log文件的源码) 6. 上传文件 7. 设计模式、技巧 8. 框架中各个主要类的功能划分

接下来我们讨论一下方案的不足

  • 不足1:确实检测到卡顿,但获取到的卡顿堆栈信息可能不准确;
  • 不足2:和OOM一样,最后的打印堆栈只是表象,不是真正的问题; 我们还需要监控过程中的一次次log信息来确定原因;

【假设初始方案,整个**监控周期**只采集一次】

如上图,

假设主线程

在**时间点T1(开始阻塞)**与**T2(阻塞结束)**之间的时间段中发生了卡顿,

而**卡顿检测方案**是在**T2时刻**,

也就是 阻塞时间完全结束 (前提是**T2-T1大于阈值**,确定了是卡顿问题)的时刻,

方案**才开始**获取**卡顿堆栈的信息**,

而**实际发生卡顿**(如发生**违例耗时处理过程**)的**时间点**,

可能是在这个时间段内,而非获取信息的T2点,

那有可能,

耗时操作**在**时间段内**,即在T2点之前就已经**执行完成**了,**

T2点获取到的可能不是卡顿发生的准确时刻,

也就是说**T2时刻**获取到的信息,不能够完全**反映卡顿的现场**;

最后的T2点的堆栈信息只是表象,不能反映真正的问题;

我们需要缩小采集堆栈信息的周期,进行**高频采集**,详细如下;

自动检测方案优化

  • 优化思路:获取监控周期内的多个堆栈,而不仅是一个;
  • 主要步骤: startMonitor**开始监控(Message分发、处理前),** 接着**高频采集堆栈**!!! 阻塞结束,Message分发、处理后,前后时间差——阻塞时间超过阈值,即发生卡顿,便调用**endMonitor**; 记录 高频采集好的堆栈信息 到文件中**;【具体源码解析见上面解析部分(另一篇博客)】** 在合适的时机**上报**给服务器;【相关方案以及源码解析见上面解析部分(另一篇博客)】
  • 如此一来, 便能更清楚地知道在整个卡顿周期(阻塞开始到结束;Message分发、处理前到后)之内, 究竟是哪些方法在执行,哪些方法执行比较耗时; 优化**卡顿现场**不能还原的问题;
  • 新问题:面对 高频卡顿堆栈信息的上报、处理,服务端有压力;
代码语言:txt
复制
- **突破点:一个卡顿下多个堆栈大概率有重复;**
- **解决:对一个卡顿下的堆栈进行hash排重,** 

参考:

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 为何需要自动化检测方案
  • 方案原理
  • 看一下Looper.loop()源码
  • 实现思路
  • AndroidPerformanceMonitor实战
  • 基于AndroidPerformanceMonitor源码简析
    • 接下来我们讨论一下方案的不足
      • 自动检测方案优化
      相关产品与服务
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档