Android线上轻量级APM性能监测方案

本文涉及的产品
应用实时监控服务ARMS - 应用监控,每月50GB免费额度
简介: Android线上轻量级APM性能监测方案

App性能如何量化


如何衡量一个APP性能好坏?直观感受就是:启动快、流畅、不闪退、耗电少等感官指标,反应到技术层面包装下就是:FPS(帧率)、界面渲染速度、Crash率、网络、CPU使用率、电量损耗速度等,一般挑其中几个关键指标作为APP质量的标尺。目前也有多种开源APM监控方案,但大部分偏向离线检测,对于线上监测而言显得太重,可能会适得其反,方案简单对比如下:

SDK 现状与问题 是否推荐直接线上使用
腾讯matrix 功能全,但是重,而且运行测试期间经常Crash
腾讯GT 2018年之后没更新,关注度低,本身功能挺多,也挺重性价比还不如matrix
网易Emmagee 2018年之后没更新,几乎没有关注度,重
听云App 适合监测网络跟启动,场景受限

还有其他多种APM检测工具,功能复杂多样,但其实很多指标并不是特别重要,实现越复杂,线上风险越大,因此,并不建议直接使用。而且,分析多家APP的实现原理,其核心思路基本相同,且门槛也并不是特别高,建议自研一套,在灵活性、安全性上更有保障,更容易做到轻量级。本文主旨就是围绕几个关键指标:FPS、内存(内存泄漏)、界面启动、流量等,实现轻量级的线上监测。


核心性能指标拆解


  • 稳定性:Crash统计

Crash统计与聚合有比较通用的策略,比如Firebase、Bugly等,不在本文讨论范围


  • 网络请求

每个APP的网络请求一般都存在统一的Hook点,门槛很低,且各家请求协议与SDK有别,很难实现统一的网络请求监测,其次,想要真正定位网络请求问题,可能牵扯整个请求的链路,更适合做一套网络全链路监控APM,也不在讨论范围。


  • 冷启动时间及各个Activity页面启动时间 (存在统一方案)
  • 页面FPS、卡顿、ANR    (存在统一方案)
  • 内存统计及内存泄露侦测 (存在统一方案)
  • 流量消耗   (存在统一方案)
  • 电量   (存在统一方案)
  • CPU使用率(CPU):还没想好咋么用,7.0之后实现机制也变了,先不考虑


线上监测的重点就聚焦后面几个,下面逐个拆解如何实现。


启动耗时


直观上说界面启动就是:从点击一个图标到看到下一个界面首帧,如果这个过程耗时较长,用户会会感受到顿挫,影响体验。从场景上说,启动耗时间简单分两种:


  • 冷启动耗时:在APP未启动的情况从,从点击桌面icon 到看到闪屏Activity的首帧(非默认背景)
  • 界面启动耗:APP启动后,从上一个界面pause,到下一个界面首帧可见,


本文粒度较粗,主要聚焦Activity,这里有个比较核心的时机:Activity首帧可见点,这个点究竟在什么时候?经分析测试发现,不同版本表现不一,在Android 10 之前这个点与onWindowFocusChanged回调点基本吻合,在Android  10 之后,系统做了优化,将首帧可见的时机提前到onWindowFocusChanged之前,可以简单看做onResume(或者onAttachedToWindow)之后,对于一开始点击icon的点,可以约等于APP进程启动的点,拿到了上面两个时间点,就可以得到冷启动耗时。


APP进程启动的点可以通过加载一个空的ContentProvider来记录,因为ContentProvider的加载时机比较靠前,早于Application的onCreate之前,相对更准确一点,很多SDK的初始也采用这种方式,实现如下:

public class LauncherHelpProvider extends ContentProvider {
    // 用来记录启动时间
    public static long sStartUpTimeStamp = SystemClock.uptimeMillis();
    ...
    }

这样就得到了冷启动的开始时间,如何得到第一个Activity界面可见的时间呢?大概回执流程如下


image.png

网上有一些认为可以监听onAttachedToWindow或者OnWindowFocusChange,onAttachedToWindow的问题是可能太过靠前,还没有Draw, OnWindowFocusChange的缺点可能是太过滞后。其实可以简单认为在view draw以后,View的绘制就算完成,虽然到展示还可能相差一个VSYNC等待图层合成,但是对于性能监测的评定,误差一个固定值可以接受:


image.png

在onResume函数中插入一条消息可以吗,理论上来说,太过靠前,这条消息在执行的时候,还没Draw,因为请求VSYNC的同步栅栏是在是在Onresume结束后才插入的,无法拦截之前的Message,但是由于VSYNC可能存在复用,Onresume中插入的消息也有可能会在绘制之后执行,这个不是完全一定的,比如点击MaterialButton启动一个Activity,第二个Activity的setView触发的VSYNC就可能复用MaterialButton的波纹触发的VSYNC,从而导致第二个Activity的performTraval复用第一个VSYNC执行,从而发生在onResume插入消息之前,如下

栅栏消息


image.png

重绘CallBack包含多个Activity的重绘

image.png

综上所述,将指标定义在第一次View的Draw执行可能比较靠谱。具体可以再DecorView上插入一个透明View,监听器onDraw回调即可,如果觉得不够优雅,就退一步,监听OnWindowFocusChange的回调,也勉强可以接受, OnWindowFocusChange一定是在Draw之后的。如此就可以检测到冷启动耗时。APP启动后,各Activity启动耗时计算逻辑类似,首帧可见点沿用上面方案即可,不过这里还缺少上一个界面暂停的点,经分析测试,锚在上一个Actiivty pause的时候比较合理,因此Activity启动耗时定义如下:


Activity启动耗时 = 当前Activity 首帧可见 - 上一个Activity onPause被调用

同样为了减轻对业务入侵,也依赖registerActivityLifecycleCallbacks来实现:补全上方缺失

   application.registerActivityLifecycleCallbacks(new Application.ActivityLifecycleCallbacks() {
       @Override
        public void onActivityPaused(@NonNull Activity activity) {
            super.onActivityPaused(activity);
            <!--记录上一个Activity pause节点-->
            mActivityLauncherTimeStamp = SystemClock.uptimeMillis();
            launcherFlag = 0;
        }
        ...
    @Override
    public void onActivityResumed(@NonNull final Activity activity) {
        super.onActivityResumed(activity);
        launcherFlag |= resumeFlag;
       <!--参考上面获取首帧的点-->
             ...

到这里就获取了两个比较关键的启动耗时,不过,时机使用中可能存在各种异常场景:比如闪屏页在onCreate或者onResume中调用了finish跳转首页,对于这种场景就需要额外处理,比如在onCreate中调用了finish,onResume可能不会被调用,这个时候就要在 onCreate之后进行统计,同时利用用Activity.isFinishing()标识这种场景,其次,启动耗时对于不同配置也是不一样的,不能用绝对时间衡量,只能横向对比,简单线上效果如下:


image.png

image.png

image.png


流畅度及FPS(Frames Per Second)监测


FPS是图像领域中的定义,指画面每秒传输帧数,每秒帧数越多,显示的动作就越流畅。FPS可以作为衡量流畅度的一个指标,但是,从各厂商的报告来看,仅用FPS来衡量是否流畅并不科学。电影或视频的FPS并不高,30的FPS即可满足人眼需求,稳定在30FPS的动画,并不会让人感到卡顿,但如果FPS 很不稳定的话,就很容易感知到卡顿,注意,这里有个词叫稳定。举个极端例子:前500ms刷新了59帧,后500ms只绘制一帧,即使达到了60FPS,仍会感知卡顿,这里就突出稳定的重要性。不过FPS也并不是完全没用,可以用其上限定义流畅,用其下限可以定义卡顿,对于中间阶段的感知,FPS无能为力,如下示意:

image.png

上面那个是极端例子,Android 系统中,VSYNC会杜绝16ms内刷新两次,那么在中间的情况下怎么定义流畅?比如,FPS降低到50会卡吗?答案是不一定。50的FPS如果是均分到各个节点,用户是感知不到掉帧的,但,如果丢失的10帧全部在一次绘制点,那就能明显感知卡顿,这个时候,瞬时帧率的意义更大,如下


image.png

Matrix给的卡顿标准:

image.png


总之,相比1s平均FPS,瞬时掉帧程度的严重性更能反应界面流畅程度,因此FPS监测的重点是侦测瞬时掉帧程度。

image.png

在应用中,FPS对动画及列表意义较大,监测开始的时机放在界面启动并展示第一帧之后,这样就能跟启动完美衔接起来,


// 帧率不统计第一帧
    @Override
    public void onActivityResumed(@NonNull final Activity activity) {
        super.onActivityResumed(activity);
        activity.getWindow().getDecorView().getViewTreeObserver().addOnWindowFocusChangeListener(new ViewTreeObserver.OnWindowFocusChangeListener() {
            @Override
            public void onWindowFocusChanged(boolean b) {
                if (b) {
                <!--界面可见后,开始侦测FPS-->
                    resumeTrack();
                    activity.getWindow().getDecorView().getViewTreeObserver().removeOnWindowFocusChangeListener(this);
    ...
  }

侦测停止的时机也比较简单在onActivityPaused:界面失去焦点,无法与用户交互的时候

@Override
    public void onActivityPaused(@NonNull Activity activity) {
        super.onActivityPaused(activity);
        pauseTrack(activity.getApplication());
    }

如何侦测瞬时FPS?有两种常用方式


  • 360 ArgusAPM类实现方式:  监测Choreographer两次Vsync时间差
  • BlockCanary的实现方式:监测UI线程单条Message执行时间


360的实现依赖Choreographer VSYNC回调,具体实现如下:循环添加Choreographer.FrameCallback

Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
    @Override
        public void doFrame(long frameTimeNanos) {
            mFpsCount++;
            mFrameTimeNanos = frameTimeNanos;
            if (isCanWork()) {
                //注册下一帧回调
                Choreographer.getInstance().postFrameCallback(this);
            } else {
                mCurrentCount = 0;
            }
        }
});

这种监听有个问题就是,监听过于频繁,因为在无需界面刷新的时候Choreographer.FrameCallback还是不断循环执行,浪费CPU资源,对线上运行采集并不友好,相比之下BlockCanary的监听单个Message执行要友善的多,而且同样能够涵盖UI绘制耗时、两帧之间的耗时,额外执行负担较低,也是本文采取的策略,核心实现参照Matrix:


  • 监听Message执行耗时
  • 通过反射循环添加Choreographer.FrameCallback区分doFrame耗时


为Looper设置一个LooperPrinter,根据回传信息头区分消息执行开始于结束,计算Message耗时:原理如下

      public static void loop() {
                ...
                if (logging != null) {
                    logging.println(">>>>> Dispatching to " + msg.target + " " +
                            msg.callback + ": " + msg.what);
                }
                 ...
                if (logging != null) {
                    logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
                }

自定义LooperPrinter如下:

        class LooperPrinter implements Printer {
        @Override
        public void println(String x) {
           ...
            if (isValid) {
            <!--区分开始结束,计算消息耗时-->
                dispatch(x.charAt(0) == '>', x);
        }

利用回调参数">>>>"与"<<<"的 区别即可诊断出Message执行耗时,从而确定是否导致掉帧。以上实现针对所有UI Message,原则上UI线程所有的消息都应该保持轻量级,任何消息超时都应当算作异常行为,所以,直接拿来做掉帧监测没特大问题的。但是,有些特殊情况可能对FPS计算有一些误判,比如,在touch时间里往UI线程塞了很多消息,单条一般不会影响滚动,但多条聚合可能会带来影响,如果没跳消息执行时间很短,这种方式就可能统计不到,当然这种业务的写法本身就存在问题,所以先不考虑这种场景。


Choreographer有个方法addCallbackLocked,通过这个方法添加的任务会被加入到VSYNC回调,会跟Input、动画、UI绘制一起执行,因此可以用来作为鉴别是否是UI重绘的Message,看看是不是重绘或者触摸事件导致的卡顿掉帧。Choreographer源码如下:

    @UnsupportedAppUsage
    public void addCallbackLocked(long dueTime, Object action, Object token) {
        CallbackRecord callback = obtainCallbackLocked(dueTime, action, token);
        CallbackRecord entry = mHead;
        if (entry == null) {
            mHead = callback;
            return;
        }
        if (dueTime < entry.dueTime) {
            callback.next = entry;
            mHead = callback;
            return;
        }
        while (entry.next != null) {
            if (dueTime < entry.next.dueTime) {
                callback.next = entry.next;
                break;
            }
            entry = entry.next;
        }
        entry.next = callback;
    }

该方法不为外部可见,因此需要通过反射获取,

private synchronized void addFrameCallback(int type, Runnable callback, boolean isAddHeader) {
    try {
         <!--反射获取方法-->
            addInputQueue = reflectChoreographerMethod(0 “addCallbackLocked”, long.class, Object.class, Object.class);
          <!--添加回调-->
            if (null != method) {
                method.invoke(callbackQueues[type], !isAddHeader ? SystemClock.uptimeMillis() : -1, callback, null);
            }

然后在每次执行结束后,重新将callback添加回Choreographer的Queue,监听下一次UI绘制。


@Override
public void dispatchEnd() {
    super.dispatchEnd();
    if (mStartTime > 0) {
        long cost = SystemClock.uptimeMillis() - mStartTime;
        <!--计算耗时-->
        collectInfoAndDispatch(ActivityStack.getInstance().getTopActivity(), cost, mInDoFrame);
        if (mInDoFrame) {
        <!--监听下一次UI绘制-->
            addFrameCallBack();
            mInDoFrame = false;
        }
    }
}

这样就能检测到每次Message执行的时间,它可以直接用来计算瞬时帧率


瞬时掉帧程度 = Message耗时/16 -1 (不足1 可看做1)

瞬时掉帧小于2次可以认为没有发生抖动,如果出现了单个Message执行过长,可认为发生了掉帧,流畅度与瞬时帧率监测大概就是这样。不过,同启动耗时类似,不同配置结果不同,不能用绝对时间衡量,只能横向对比,简单线上效果如下:


image.png

image.png


内存泄露及内存使用侦测


内存泄露有个比较出名的库LeakCanary,实现原理也比较清晰,就是利用弱引用+ReferenceQueue,其实只用弱引用也可以做,ReferenceQueue只是个辅助作用,LeakCanary除了泄露检测还有个堆栈Dump的功能,虽然很好,但是这个功能并不适合线上,而且,只要能监听到Activity泄露,本地分析原因是比较快的,没必要将堆栈Dump出来。因此,本文只实现Activity泄露监测能力,不在线上分析原因。而且,参考LeakCanary,改用一个WeakHashMap实现上述功能,不在主动暴露ReferenceQueue这个对象。WeakHashMap最大的特点是其key对象被自动弱引用,可以被回收,利用这个特点,用其key监听Activity回收就能达到泄露监测的目的。核心实现如下:

   application.registerActivityLifecycleCallbacks(new Application.ActivityLifecycleCallbacks() {
        @Override
        public void onActivityDestroyed(@NonNull Activity activity) {
            super.onActivityDestroyed(activity);
            <!--放入map,进行监听-->
            mActivityStringWeakHashMap.put(activity, activity.getClass().getSimpleName());
        }
        @Override
        public void onActivityStopped(@NonNull final Activity activity) {
            super.onActivityStopped(activity);
            //  退后台,GC 找LeakActivity
            if (!ActivityStack.getInstance().isInBackGround()) {
                return;
            }
            Runtime.getRuntime().gc();
            mHandler.postDelayed(new Runnable() {
                @Override
                public void run() {
                    try {
                        if (!ActivityStack.getInstance().isInBackGround()) {
                            return;
                        }
                        try {
                            //   申请个稍微大的对象,促进GC
                            byte[] leakHelpBytes = new byte[4 * 1024 * 1024];
                            for (int i = 0; i < leakHelpBytes.length; i += 1024) {
                                leakHelpBytes[i] = 1;
                            }
                        } catch (Throwable ignored) {
                        }
                        Runtime.getRuntime().gc();
                        SystemClock.sleep(100);
                        System.runFinalization();
                        HashMap<String, Integer> hashMap = new HashMap<>();
                        for (Map.Entry<Activity, String> activityStringEntry : mActivityStringWeakHashMap.entrySet()) {
                            String name = activityStringEntry.getKey().getClass().getName();
                            Integer value = hashMap.get(name);
                            if (value == null) {
                                hashMap.put(name, 1);
                            } else {
                                hashMap.put(name, value + 1);
                            }
                        }
                        if (mMemoryListeners.size() > 0) {
                            for (Map.Entry<String, Integer> entry : hashMap.entrySet()) {
                                for (ITrackMemoryListener listener : mMemoryListeners) {
                                    listener.onLeakActivity(entry.getKey(), entry.getValue());
                                }
                            }
                        }
                    } catch (Exception ignored) {
                    }
                }
            }, 10000);
        }

线上选择监测没必要实时,将其延后到APP进入后台的时候,在APP进入后台之后主动触发一次GC,然后延时10s,进行检查,之所以延时10s,是因为GC不是同步的,为了让GC操作能够顺利执行完,这里选择10s后检查。在检查前分配一个4M的大内存块,再次确保GC执行,之后就可以根据WeakHashMap的特性,查找有多少Activity还保留在其中,这些Activity就是泄露Activity。

关于内存检测

内存检测比较简单,弄清几个关键的指标就行,这些指标都能通过 Debug.MemoryInfo获取


Debug.MemoryInfo debugMemoryInfo = new Debug.MemoryInfo();
        Debug.getMemoryInfo(debugMemoryInfo);
        appMemory.nativePss = debugMemoryInfo.nativePss >> 10;
        appMemory.dalvikPss = debugMemoryInfo.dalvikPss >> 10;
        appMemory.totalPss = debugMemoryInfo.getTotalPss() >> 10;

这里关心三个就行,


  • TotalPss(整体内存,native+dalvik+共享)
  • nativePss (native内存)
  • dalvikPss (java内存 OOM原因)


一般而言total是大于nativ+dalvik的,因为它包含了共享内存,理论上我们只关心native跟dalvik就行,以上就是关于内存的监测能力,不过内存泄露不是100%正确,暴露明显问题即可,效果如下:


image.png


流量监测


流量监测的实现相对简单,利用系统提供的TrafficStats.getUidRxBytes方法,配合Actvity生命周期,即可获取每个Activity的流量消耗。具体做法:在Activity start的时候记录起点,在pause的时候累加,最后在Destroyed的时候统计整个Activity的流量消耗,如果想要做到Fragment维度,就要具体业务具体分析了,简单实现如下

   application.registerActivityLifecycleCallbacks(new Application.ActivityLifecycleCallbacks() {
        @Override
        public void onActivityStarted(@NonNull Activity activity) {
            super.onActivityStarted(activity);
            <!--开始记录-->
            markActivityStart(activity);
        }
        @Override
        public void onActivityPaused(@NonNull Activity activity) {
            super.onActivityPaused(activity);
            <!--累加-->
            markActivityPause(activity);
        }
        @Override
        public void onActivityDestroyed(@NonNull Activity activity) {
            super.onActivityDestroyed(activity);
            <!--统计结果,并通知回调-->
            markActivityDestroy(activity);
        }
    };

image.png

image.png


电量检测


Android电量状态能通过一下方法实时获取,只是对于分析来说有点麻烦,需要根据不同手机、不同配置做聚合,单处采集很简单

IntentFilter filter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
            android.content.Intent batteryStatus = application.registerReceiver(null, filter);
            int status = batteryStatus.getIntExtra("status", 0);
            boolean isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING ||
                    status == BatteryManager.BATTERY_STATUS_FULL;
            int scale = batteryStatus.getIntExtra(BatteryManager.EXTRA_SCALE, -1);

不过并不能获取绝对电量,只能看百分比,因为对单个Activity来做电量监测并不靠谱,往往都是0,可以在APP推到后台后,对真个在线时长的电池消耗做监测,这个可能还能看出一些电量变化。


CPU使用监测


没想好怎么弄,显不出力


数据整合与基线制定


APP端只是完成的数据的采集,数据的整合及根系还是要依赖后台数据分析,根据不同配置,不同场景才能制定一套比较合理的基线,而且,这种基线肯定不是绝对的,只能是相对的,这套基线将来可以作为页面性能评估标准,对Android而言,挺难,机型太多。


总结


  • 启动有相对靠谱节点
  • 瞬时FPS(瞬时掉帧程度)意义更大
  • 内存泄露可以一个WeakHashMap简单搞定
  • 电量及CPU还不知道怎么用


相关实践学习
通过云拨测对指定服务器进行Ping/DNS监测
本实验将通过云拨测对指定服务器进行Ping/DNS监测,评估网站服务质量和用户体验。
目录
相关文章
|
3月前
|
移动开发 监控 前端开发
构建高效Android应用:从优化布局到提升性能
【7月更文挑战第60天】在移动开发领域,一个流畅且响应迅速的应用程序是用户留存的关键。针对Android平台,开发者面临的挑战包括多样化的设备兼容性和性能优化。本文将深入探讨如何通过改进布局设计、内存管理和多线程处理来构建高效的Android应用。我们将剖析布局优化的细节,并讨论最新的Android性能提升策略,以帮助开发者创建更快速、更流畅的用户体验。
62 10
|
2月前
|
Android开发 开发者 索引
Android实战经验之如何使用DiffUtil提升RecyclerView的刷新性能
本文介绍如何使用 `DiffUtil` 实现 `RecyclerView` 数据集的高效更新,避免不必要的全局刷新,尤其适用于处理大量数据场景。通过定义 `DiffUtil.Callback`、计算差异并应用到适配器,可以显著提升性能。同时,文章还列举了常见错误及原因,帮助开发者避免陷阱。
102 9
|
2月前
|
开发框架 Dart 前端开发
Android 跨平台方案对比之Flutter 和 React Native
本文对比了 Flutter 和 React Native 这两个跨平台移动应用开发框架。Flutter 使用 Dart 语言,提供接近原生的性能和丰富的组件库;React Native 则基于 JavaScript,具备庞大的社区支持和灵活性。两者各有优势,选择时需考虑团队技能和项目需求。
289 8
|
2月前
|
安全 Android开发 数据安全/隐私保护
安卓与iOS的对决:移动操作系统的性能与创新
在当今智能手机市场,安卓和iOS两大操作系统一直处于竞争状态。本文将深入探讨它们在性能、安全性和用户体验方面的不同,并分析这些差异如何影响用户的选择。
51 3
|
2月前
|
Web App开发 网络协议 Android开发
Android平台一对一音视频通话方案大比拼:WebRTC VS RTMP VS RTSP,谁才是王者?
【9月更文挑战第4天】本文详细对比了在Android平台上实现一对一音视频通话时常用的WebRTC、RTMP及RTSP三种技术方案。从技术原理、性能表现与开发难度等方面进行了深入分析,并提供了示例代码。WebRTC适合追求低延迟和高质量的场景,但开发成本较高;RTMP和RTSP则在简化开发流程的同时仍能保持较好的传输效果,适用于不同需求的应用场景。
128 1
|
2月前
|
安全 API 开发工具
Android平台RTMP推送|轻量级RTSP服务如何实现麦克风|扬声器声音采集切换
Android平台扬声器播放声音的采集,在无纸化同屏等场景下,意义很大,早期低版本的Android设备,是没法直接采集扬声器audio的(从Android 10开始支持),所以,如果需要采集扬声器audio,需要先做系统版本判断,添加相应的权限。
|
2月前
|
编解码 开发工具 Android开发
Android平台实现屏幕录制(屏幕投影)|音频播放采集|麦克风采集并推送RTMP或轻量级RTSP服务
Android平台屏幕采集、音频播放声音采集、麦克风采集编码打包推送到RTMP和轻量级RTSP服务的相关技术实现,做成高稳定低延迟的同屏系统,还需要有配套好的RTMP、RTSP直播播放器
|
3月前
|
存储 安全 API
Android经典实战之存储方案对比:SharedPreferences vs MMKV vs DataStore
本文介绍了 Android 开发中常用的键值对存储方案,包括 SharedPreferences、MMKV 和 DataStore,并对比了它们在性能、并发处理、易用性和稳定性上的特点。通过实际代码示例,帮助开发者根据项目需求选择最适合的存储方案,提升应用性能和用户体验。
79 1
|
3月前
|
Android开发 C++ 开发者
Android经典实战之跨平台开发方案:Kotlin Multiplatform vs Flutter
本文对比了Kotlin Multiplatform与Flutter两大跨平台开发框架,从技术特性、性能、开发效率、UI体验、可扩展性及适用场景等维度进行了详尽分析,帮助开发者根据项目需求和技术背景选择最优方案。
99 2