爆种写了个Android性能监测工具（支持Fps/流量/内存/启动...）

1.App性能如何量化

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

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

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

2.核心性能指标拆解

• 稳定性：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界面可见的时间呢？比较简单的做法是在SplashActivity中进行打点，对于Android 10 以前的，可以在onWindowFocusChanged中打点，在Android 10以后，可以在onResume之后进行打点。不过，做SDK需要减少对业务的入侵，可以借助Applicattion监听Activity Lifecycle无入侵获取这个时间点。对于Android 10之前系统， 可以利用ViewTreeObserve监听nWindowFocusChange回调，达到无入侵获取onWindowFocusChanged调用点，示意代码如下:

application.registerActivityLifecycleCallbacks(new Application.ActivityLifecycleCallbacks() {
   ....
   @Override
public void onActivityResumed(@NonNull final Activity activity) {
    super.onActivityResumed(activity);
    launcherFlag |= resumeFlag;

      
        activity.getWindow().getDecorView().getViewTreeObserver().addOnWindowFocusChangeListener(new ViewTreeObserver.OnWindowFocusChangeListener() {
        
        @Override
        public void onWindowFocusChanged(boolean b) {
            if (b && (launcherFlag ^ startFlag) == 0) {
               
                final boolean isColdStarUp = ActivityStack.getInstance().getBottomActivity() == activity;
                
                final long coldLauncherTime = SystemClock.uptimeMillis() - LauncherHelpProvider.sStartUpTimeStamp;
                final long activityLauncherTime = SystemClock.uptimeMillis() - mActivityLauncherTimeStamp;
                activity.getWindow().getDecorView().getViewTreeObserver().removeOnWindowFocusChangeListener(this);
                
                mHandler.post(new Runnable() {
                    @Override
                    public void run() {
                        if (isColdStarUp) {
                        //todo 监听到冷启动耗时
                        ...

对于Android 10以后的系统，可以在onActivityResumed回调时添加一UI线程Message来达到监听目的，代码如下：

@Override
public void onActivityResumed(@NonNull final Activity activity) {
    super.onActivityResumed(activity);
    if (launcherFlag != 0 && (launcherFlag & resumeFlag) == 0) {
        launcherFlag |= resumeFlag;
        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.P) {
            //  10 之后有改动，第一帧可见提前了 可认为onActivityResumed之后
            mUIHandler.post(new Runnable() {
                @Override
                public void run() {
                                            }
            });
        }

如此就可以检测到冷启动耗时。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);
        
        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()标识这种场景，其次，启动耗时对于不同配置也是不一样的，不能用绝对时间衡量，只能横向对比，简单线上效果如下：

线上效果如下：

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

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

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

Matrix给的卡顿标准：

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

在应用中，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) {
            
                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("