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

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: Android卡顿优化 | 自动化卡顿检测方案与优化(AndroidPerformanceMonitor / BlockCanary)

本文要点

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

项目GitHub

为何需要自动化检测方案

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

方案原理

  • **源于Android的消息处理机制;

一个线程不管有多少Handler,只会有一个Looper存在,
主线程中所有的代码,都会通过Looper.loop()执行;**

  • **loop()中有一个mLogging对象,

它在每个Message处理前后都会被调用:**

  • **如果主线程发生卡顿,

一定是在dispatchMessage执行了耗时操作!**Handler机制图

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

看一下Looper.loop()源码

    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:方便精确,可以把问题定位到代码的具体某一行!!!

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


实战开始---------------------------------------------------

在Application进行初始化,
BlockCanary.install(this, new AppBlockCanaryContext()).start();
第一个参数是上下文
第二个参数是需要传入一个Block的配置类实例【BlockCanaryContext类实例或者其子类实例】:**

public class TestApp extends Application {

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

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

    }
}    
  • **AppBlockCanaryContext是我们自定义的类,

配置了BlockCanary的各种信息,
代码较多,可以看下GitHub,这里就不贴全部代码了~
下面两个配置方法分别是
给出一个uid,可以用于在上报时上报当前的用户信息
第二个是自定义卡顿的阈值时间,过了阈值便认为是卡顿,
这里指定的是500ms;**

    /**
     * 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;
    }
  • **接着在MainActivityonCreate()中,

让主线程沉睡两秒(2000ms > 设定的阈值500ms);**

  • **运行时,因为主线程停滞时间超过既定阈值,

组件会认为其卡顿并且弹出通知!!
当然Android8.0以后比较麻烦,
因为notificationManager需要配置Channel等才能用,
或者允许后台弹出界面桌面上便会出现这个图标:进去之后就可以看到了相应的信息了:当然,我们可以在logcat中定位关键词blockInfo
看到同样的详细的信息:如上,
Block框架打印出来了【当前子线程的堆栈信息以及当前的一些场景信息(如内存大小、变量、网络状态等)】,
time-starttime-end时间间隔又可以知道阻塞的时间,如上图展示出来的,正是我们设置的2秒!!!!
也可以看到uid键的值 便是我们刚刚设定的字符串“uid”
同时还直接帮我们定位到卡顿问题的出处!!!**

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


基于AndroidPerformanceMonitor源码简析

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

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



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

  • 不足1:确实检测到卡顿,但获取到的卡顿堆栈信息可能不准确;
  • **不足2:和OOM一样,最后的打印堆栈只是表象,不是真正的问题;

我们还需要监控过程中的一次次log信息来确定原因;
【假设初始方案,整个监控周期只采集一次】
如上图,
假设主线程
时间点T1(Message分发、处理前)T2(Message分发、处理后)之间的时间段中发生了卡顿,
卡顿检测方案是在T2时刻
也就是 阻塞时间完全结束 (前提是T2-T1大于阈值,确定了是卡顿问题)的时刻,
方案才开始获取卡顿堆栈的信息

实际发生卡顿(如发生违例耗时处理过程)的时间点
可能是在这个时间段内,而非获取信息的T2点,
那有可能,
耗时操作时间段内,即在T2点之前就已经执行完成了,
T2点获取到的可能不是卡顿发生的准确时刻,
也就是说T2时刻获取到的信息,不能够完全反映卡顿的现场
最后的T2点的堆栈信息只是表象,不能反映真正的问题;

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

自动检测方案优化

  • 优化思路:获取监控周期内的多个堆栈,而不仅是一个;
  • **主要步骤:

startMonitor开始监控(Message分发、处理前),
接着高频采集堆栈!!!
阻塞结束,Message分发、处理后,前后时间差——阻塞时间超过阈值,即发生卡顿,便调用endMonitor(Message分发、处理后);
记录 高频采集好的堆栈信息 到文件中;【具体源码解析见上面解析部分(另一篇博客)】
在合适的时机上报给服务器;【相关方案以及源码解析见上面解析部分(另一篇博客)】**

  • **如此一来,

便能更清楚地知道在整个卡顿周期(阻塞开始到结束;Message分发、处理前到后)之内,
究竟是哪些方法在执行,哪些方法执行比较耗时;
优化卡顿现场不能还原的问题;**

  • 新问题:面对 高频卡顿堆栈信息的上报、处理,服务端有压力;

    • 突破点:一个卡顿下多个堆栈大概率有重复;
    • **解决:对一个卡顿下的堆栈进行hash排重,

找出重复的堆栈;**

  • 效果:极大地减少展示量,同时更高效地找到卡顿堆栈;





参考:

相关文章
|
16天前
|
人工智能 前端开发 测试技术
探索软件测试中的自动化框架选择与优化策略####
本文深入剖析了当前主流的自动化测试框架,通过对比分析各自的优势、局限性及适用场景,为读者提供了一套系统性的选择与优化指南。文章首先概述了自动化测试的重要性及其在软件开发生命周期中的位置,接着逐一探讨了Selenium、Appium、Cypress等热门框架的特点,并通过实际案例展示了如何根据项目需求灵活选用与配置框架,以提升测试效率和质量。最后,文章还分享了若干最佳实践和未来趋势预测,旨在帮助测试工程师更好地应对复杂多变的测试环境。 ####
40 4
|
22天前
|
机器学习/深度学习 前端开发 测试技术
探索软件测试中的自动化测试框架选择与优化策略####
本文深入探讨了在当前软件开发生命周期中,自动化测试框架的选择对于提升测试效率、保障产品质量的重要性。通过分析市场上主流的自动化测试工具,如Selenium、Appium、Jest等,结合具体项目需求,提出了一套系统化的选型与优化策略。文章首先概述了自动化测试的基本原理及其在现代软件开发中的角色变迁,随后详细对比了各主流框架的功能特点、适用场景及优缺点,最后基于实际案例,阐述了如何根据项目特性量身定制自动化测试解决方案,并给出了持续集成/持续部署(CI/CD)环境下的最佳实践建议。 --- ####
|
27天前
|
运维 监控 Linux
自动化运维:如何利用Python脚本优化日常任务##
【10月更文挑战第29天】在现代IT运维中,自动化已成为提升效率、减少人为错误的关键技术。本文将介绍如何通过Python脚本来简化和自动化日常的运维任务,从而让运维人员能够专注于更高层次的工作。从备份管理到系统监控,再到日志分析,我们将一步步展示如何编写实用的Python脚本来处理这些任务。 ##
|
3月前
|
存储 缓存 编解码
Android经典面试题之图片Bitmap怎么做优化
本文介绍了图片相关的内存优化方法,包括分辨率适配、图片压缩与缓存。文中详细讲解了如何根据不同分辨率放置图片资源,避免图片拉伸变形;并通过示例代码展示了使用`BitmapFactory.Options`进行图片压缩的具体步骤。此外,还介绍了Glide等第三方库如何利用LRU算法实现高效图片缓存。
68 20
Android经典面试题之图片Bitmap怎么做优化
|
2月前
|
调度 Android开发 开发者
构建高效Android应用:探究Kotlin多线程优化策略
【10月更文挑战第11天】本文探讨了如何在Kotlin中实现高效的多线程方案,特别是在Android应用开发中。通过介绍Kotlin协程的基础知识、异步数据加载的实际案例,以及合理使用不同调度器的方法,帮助开发者提升应用性能和用户体验。
55 4
|
2月前
|
机器学习/深度学习 存储 测试技术
从0到1:如何规划一套流量回放自动化测试方案
本文介绍了流量回放自动化测试的完整方法,从企业战略到交付的四个关键环节:Discovery(深度挖掘)、Define(定义目标)、Design(详细设计)和Delivery(交付与反馈)。通过这些步骤,帮助企业优化系统性能和稳定性,确保产品的高质量。
60 4
|
2月前
|
存储 运维 监控
高效运维管理:从基础架构优化到自动化实践
在当今数字化时代,高效运维管理已成为企业IT部门的重要任务。本文将探讨如何通过基础架构优化和自动化实践来提升运维效率,确保系统的稳定性和可靠性。我们将从服务器选型、存储优化、网络配置等方面入手,逐步引导读者了解运维管理的核心内容。同时,我们还将介绍自动化工具的使用,帮助运维人员提高工作效率,降低人为错误的发生。通过本文的学习,您将掌握高效运维管理的关键技巧,为企业的发展提供有力支持。
|
27天前
|
安全 Android开发 iOS开发
深入探索iOS与Android系统的差异性及优化策略
在当今数字化时代,移动操作系统的竞争尤为激烈,其中iOS和Android作为市场上的两大巨头,各自拥有庞大的用户基础和独特的技术特点。本文旨在通过对比分析iOS与Android的核心差异,探讨各自的优势与局限,并提出针对性的优化策略,以期为用户提供更优质的使用体验和为开发者提供有价值的参考。
|
3月前
|
开发框架 Dart 前端开发
Android 跨平台方案对比之Flutter 和 React Native
本文对比了 Flutter 和 React Native 这两个跨平台移动应用开发框架。Flutter 使用 Dart 语言,提供接近原生的性能和丰富的组件库;React Native 则基于 JavaScript,具备庞大的社区支持和灵活性。两者各有优势,选择时需考虑团队技能和项目需求。
390 8
|
3月前
|
监控 算法 数据可视化
深入解析Android应用开发中的高效内存管理策略在移动应用开发领域,Android平台因其开放性和灵活性备受开发者青睐。然而,随之而来的是内存管理的复杂性,这对开发者提出了更高的要求。高效的内存管理不仅能够提升应用的性能,还能有效避免因内存泄漏导致的应用崩溃。本文将探讨Android应用开发中的内存管理问题,并提供一系列实用的优化策略,帮助开发者打造更稳定、更高效的应用。
在Android开发中,内存管理是一个绕不开的话题。良好的内存管理机制不仅可以提高应用的运行效率,还能有效预防内存泄漏和过度消耗,从而延长电池寿命并提升用户体验。本文从Android内存管理的基本原理出发,详细讨论了几种常见的内存管理技巧,包括内存泄漏的检测与修复、内存分配与回收的优化方法,以及如何通过合理的编程习惯减少内存开销。通过对这些内容的阐述,旨在为Android开发者提供一套系统化的内存优化指南,助力开发出更加流畅稳定的应用。
76 0