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

　　1。App性能如何量化
　　如何衡量一个APP性能好坏？直观感受就是：启动快、流畅、不闪退、耗电少等感官指标，反应到技术层面包装下就是：FPS（帧率）、界面渲染速度、Crash率、网络、CPU使用率、电量损耗速度等，一般挑其中几个关键指标作为APP质量的标尺。目前也有多种开源APM监控方案，但大部分偏向离线检测，对于线上监测而言显得太重，可能会适得其反，方案简单对比如下：
　　SDK
　　现状与问题
　　是否推荐直接线上使用
　　腾讯matrix
　　功能全，但是重，而且运行测试期间经常Crash
　　否
　　腾讯GT
　　2018年之后没更新，关注度低，本身功能挺多，也挺重性价比还不如matrix
　　否
　　网易Emmagee
　　2018年之后没更新，几乎没有关注度，重
　　否
　　听云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首帧可见点，这个点究竟在什么时候？经分析测试发现，不同版本表现不一，在Android10之前这个点与onWindowFocusChanged回调点基本吻合，在Android10之后，系统做了优化，将首帧可见的时机提前到onWindowFocusChanged之前，可以简单看做onResume（或者onAttachedToWindow）之后，对于一开始点击icon的点，可以约等于APP进程启动的点，拿到了上面两个时间点，就可以得到冷启动耗时。
　　APP进程启动的点可以通过加载一个空的ContentProvider来记录，因为ContentProvider的加载时机比较靠前，早于Application的onCreate之前，相对更准确一点，很多SDK的初始也采用这种方式，实现如下：publicclassLauncherHelpProviderextendsContentProvider｛用来记录启动时间publicstaticlongsStartUpTimeStampSystemClock。uptimeMillis（）；。。。｝
　　这样就得到了冷启动的开始时间，如何得到第一个Activity界面可见的时间呢？比较简单的做法是在SplashActivity中进行打点，对于Android10以前的，可以在onWindowFocusChanged中打点，在Android10以后，可以在onResume之后进行打点。不过，做SDK需要减少对业务的入侵，可以借助Applicattion监听ActivityLifecycle无入侵获取这个时间点。对于Android10之前系统，可以利用ViewTreeObserve监听nWindowFocusChange回调，达到无入侵获取onWindowFocusChanged调用点，示意代码如下：application。registerActivityLifecycleCallbacks（newApplication。ActivityLifecycleCallbacks（）｛。。。。OverridepublicvoidonActivityResumed（NonNullfinalActivityactivity）｛super。onActivityResumed（activity）；launcherFlagresumeFlag；！添加onWindowFocusChanged监听activity。getWindow（）。getDecorView（）。getViewTreeObserver（）。addOnWindowFocusChangeListener（newViewTreeObserver。OnWindowFocusChangeListener（）｛！onWindowFocusChanged回调OverridepublicvoidonWindowFocusChanged（booleanb）｛if（b（launcherFlagstartFlag）0）｛！判断是不是首个ActivityfinalbooleanisColdStarUpActivityStack。getInstance（）。getBottomActivity（）activity；！获取首帧可见距离启动的时间finallongcoldLauncherTimeSystemClock。uptimeMillis（）LauncherHelpProvider。sStartUpTimeStamp；finallongactivityLauncherTimeSystemClock。uptimeMillis（）mActivityLauncherTimeStamp；activity。getWindow（）。getDecorView（）。getViewTreeObserver（）。removeOnWindowFocusChangeListener（this）；！异步线程处理回调，减少UI线程负担mHandler。post（newRunnable（）｛Overridepublicvoidrun（）｛if（isColdStarUp）｛todo监听到冷启动耗时。。。
　　对于Android10以后的系统，可以在onActivityResumed回调时添加一UI线程Message来达到监听目的，代码如下：OverridepublicvoidonActivityResumed（NonNullfinalActivityactivity）｛super。onActivityResumed（activity）；if（launcherFlag！0（launcherFlagresumeFlag）0）｛launcherFlagresumeFlag；if（Build。VERSION。SDKINTBuild。VERSIONCODES。P）｛10之后有改动，第一帧可见提前了可认为onActivityResumed之后mUIHandler。post（newRunnable（）｛Overridepublicvoidrun（）｛！获取第一帧可见时间点｝｝）；｝
　　如此就可以检测到冷启动耗时。APP启动后，各Activity启动耗时计算逻辑类似，首帧可见点沿用上面方案即可，不过这里还缺少上一个界面暂停的点，经分析测试，锚在上一个Actiivtypause的时候比较合理，因此Activity启动耗时定义如下：Activity启动耗时当前Activity首帧可见上一个ActivityonPause被调用
　　同样为了减轻对业务入侵，也依赖registerActivityLifecycleCallbacks来实现：补全上方缺失：application。registerActivityLifecycleCallbacks（newApplication。ActivityLifecycleCallbacks（）｛OverridepublicvoidonActivityPaused（NonNullActivityactivity）｛super。onActivityPaused（activity）；！记录上一个Activitypause节点mActivityLauncherTimeStampSystemClock。uptimeMillis（）；launcherFlag0；｝。。。OverridepublicvoidonActivityResumed（NonNullfinalActivityactivity）｛super。onActivityResumed（activity）；launcherFlagresumeFlag；！参考上面获取首帧的点。。。
　　到这里就获取了两个比较关键的启动耗时，不过，实际使用中可能存在各种异常场景：比如闪屏页在onCreate或者onResume中调用了finish跳转首页，对于这种场景就需要额外处理，比如在onCreate中调用了finish，onResume可能不会被调用，这个时候就要在onCreate之后进行统计，同时利用用Activity。isFinishing（）标识这种场景，其次，启动耗时对于不同配置也是不一样的，不能用绝对时间衡量，只能横向对比，简单线上效果如下：
　　线上效果如下：
　　流畅度及FPS（FramesPerSecond）监测
　　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对动画及列表意义较大，监测开始的时机放在界面启动并展示第一帧之后，这样就能跟启动完美衔接起来。帧率不统计第一帧OverridepublicvoidonActivityResumed（NonNullfinalActivityactivity）｛super。onActivityResumed（activity）；activity。getWindow（）。getDecorView（）。getViewTreeObserver（）。addOnWindowFocusChangeListener（newViewTreeObserver。OnWindowFocusChangeListener（）｛OverridepublicvoidonWindowFocusChanged（booleanb）｛if（b）｛！界面可见后，开始侦测FPSresumeTrack（）；activity。getWindow（）。getDecorView（）。getViewTreeObserver（）。removeOnWindowFocusChangeListener（this）；。。。｝
　　侦测停止的时机也比较简单在onActivityPaused：界面失去焦点，无法与用户交互的时候。OverridepublicvoidonActivityPaused（NonNullActivityactivity）｛super。onActivityPaused（activity）；pauseTrack（activity。getApplication（））；｝
　　如何侦测瞬时FPS？有两种常用方式：
　　360ArgusAPM类实现方式：监测Choreographer两次Vsync时间差。
　　BlockCanary的实现方式：监测UI线程单条Message执行时间。
　　360的实现依赖ChoreographerVSYNC回调，具体实现如下：循环添加Choreographer。FrameCallback。Choreographer。getInstance（）。postFrameCallback（newChoreographer。FrameCallback（）｛OverridepublicvoiddoFrame（longframeTimeNanos）｛mFpsCount；mFrameTimeNanosframeTimeNanos；if（isCanWork（））｛注册下一帧回调Choreographer。getInstance（）。postFrameCallback（this）；｝else｛mCurrentCount0；｝｝｝）；
　　这种监听有个问题就是，监听过于频繁，因为在无需界面刷新的时候Choreographer。FrameCallback还是不断循环执行，浪费CPU资源，对线上运行采集并不友好，相比之下BlockCanary的监听单个Message执行要友善的多，而且同样能够涵盖UI绘制耗时、两帧之间的耗时，额外执行负担较低，也是本文采取的策略，核心实现参照Matrix：
　　监听Message执行耗时。
　　通过反射循环添加Choreographer。FrameCallback区分doFrame耗时。
　　为Looper设置一个LooperPrinter，根据回传信息头区分消息执行开始与结束，计算Message耗时：原理如下：publicstaticvoidloop（）｛。。。if（logging！null）｛logging。println（Dispatchingtomsg。targetmsg。callback：msg。what）；｝。。。if（logging！null）｛logging。println（Finishedtomsg。targetmsg。callback）；｝
　　自定义LooperPrinter如下：classLooperPrinterimplementsPrinter｛Overridepublicvoidprintln（Stringx）｛。。。if（isValid）｛！区分开始结束，计算消息耗时dispatch（x。charAt（0），x）；｝
　　利用回调参数与的区别即可诊断出Message执行耗时，从而确定是否导致掉帧。以上实现针对所有UIMessage，原则上UI线程所有的消息都应该保持轻量级，任何消息超时都应当算作异常行为，所以，直接拿来做掉帧监测没特大问题的。但是，有些特殊情况可能对FPS计算有一些误判，比如，在touch时间里往UI线程塞了很多消息，单条一般不会影响滚动，但多条聚合可能会带来影响，如果没跳消息执行时间很短，这种方式就可能统计不到，当然这种业务的写法本身就存在问题，所以先不考虑这种场景。
　　Choreographer有个方法addCallbackLocked，通过这个方法添加的任务会被加入到VSYNC回调，会跟Input、动画、UI绘制一起执行，因此可以用来作为鉴别是否是UI重绘的Message，看看是不是重绘或者触摸事件导致的卡顿掉帧。Choreographer源码如下：UnsupportedAppUsagepublicvoidaddCallbackLocked（longdueTime，Objectaction，Objecttoken）｛CallbackRecordcallbackobtainCallbackLocked（dueTime，action，token）；CallbackRecordentrymHead；if（entrynull）｛mHeadcallback；return；｝if（dueTimeentry。dueTime）｛callback。nextentry；mHeadcallback；return；｝while（entry。next！null）｛if（dueTimeentry。next。dueTime）｛callback。nextentry。next；break；｝entryentry。next；｝entry。nextcallback；｝
　　该方法不为外部可见，因此需要通过反射获取。privatesynchronizedvoidaddFrameCallback（inttype，Runnablecallback，booleanisAddHeader）｛try｛！反射获取方法addInputQueuereflectChoreographerMethod（0addCallbackLocked，long。class，Object。class，Object。class）；！添加回调if（null！method）｛method。invoke（callbackQueues〔type〕，！isAddHeader？SystemClock。uptimeMillis（）：1，callback，null）；｝
　　然后在每次执行结束后，重新将callback添加回Choreographer的Queue，监听下一次UI绘制。OverridepublicvoiddispatchEnd（）｛super。dispatchEnd（）；if（mStartTime0）｛longcostSystemClock。uptimeMillis（）mStartTime；！计算耗时collectInfoAndDispatch（ActivityStack。getInstance（）。getTopActivity（），cost，mInDoFrame）；if（mInDoFrame）｛！监听下一次UI绘制addFrameCallBack（）；mInDoFramefalse；｝｝｝
　　这样就能检测到每次Message执行的时间，它可以直接用来计算瞬时帧率。瞬时掉帧程度Message耗时161（不足1可看做1）
　　瞬时掉帧小于2次可以认为没有发生抖动，如果出现了单个Message执行过长，可认为发生了掉帧，流畅度与瞬时帧率监测大概就是这样。不过，同启动耗时类似，不同配置结果不同，不能用绝对时间衡量，只能横向对比，简单线上效果如下：
　　内存泄露及内存使用侦测
　　内存泄露有个比较出名的库LeakCanary，实现原理也比较清晰，就是利用弱引用ReferenceQueue，其实只用弱引用也可以做，ReferenceQueue只是个辅助作用，LeakCanary除了泄露检测还有个堆栈Dump的功能，虽然很好，但是这个功能并不适合线上，而且，只要能监听到Activity泄露，本地分析原因是比较快的，没必要将堆栈Dump出来。因此，本文只实现Activity泄露监测能力，不在线上分析原因。而且，参考LeakCanary，改用一个WeakHashMap实现上述功能，不在主动暴露ReferenceQueue这个对象。WeakHashMap最大的特点是其key对象被自动弱引用，可以被回收，利用这个特点，用其key监听Activity回收就能达到泄露监测的目的。核心实现如下：application。registerActivityLifecycleCallbacks（newApplication。ActivityLifecycleCallbacks（）｛OverridepublicvoidonActivityDestroyed（NonNullActivityactivity）｛super。onActivityDestroyed（activity）；！放入map，进行监听mActivityStringWeakHashMap。put（activity，activity。getClass（）。getSimpleName（））；｝OverridepublicvoidonActivityStopped（NonNullfinalActivityactivity）｛super。onActivityStopped（activity）；退后台，GC找LeakActivityif（！ActivityStack。getInstance（）。isInBackGround（））｛return；｝Runtime。getRuntime（）。gc（）；mHandler。postDelayed（newRunnable（）｛Overridepublicvoidrun（）｛try｛if（！ActivityStack。getInstance（）。isInBackGround（））｛return；｝try｛申请个稍微大的对象，促进GCbyte〔〕leakHelpBytesnewbyte〔410241024〕；for（inti0；ileakHelpBytes。length；i1024）｛leakHelpBytes〔i〕1；｝｝catch（Throwableignored）｛｝Runtime。getRuntime（）。gc（）；SystemClock。sleep（100）；System。runFinalization（）；HashMapString，IntegerhashMapnewHashMap（）；for（Map。EntryactivityStringEntry：mActivityStringWeakHashMap。entrySet（））｛StringnameactivityStringEntry。getKey（）。getClass（）。getName（）；IntegervaluehashMap。get（name）；if（valuenull）｛hashMap。put（name，1）；｝else｛hashMap。put（name，value1）；｝｝if（mMemoryListeners。size（）0）｛for（Map。EntryString，Integerentry：hashMap。entrySet（））｛for（ITrackMemoryListenerlistener：mMemoryListeners）｛listener。onLeakActivity（entry。getKey（），entry。getValue（））；｝｝｝｝catch（Exceptionignored）｛｝｝｝，10000）；｝
　　线上选择监测没必要实时，将其延后到APP进入后台的时候，在APP进入后台之后主动触发一次GC，然后延时10s，进行检查，之所以延时10s，是因为GC不是同步的，为了让GC操作能够顺利执行完，这里选择10s后检查。在检查前分配一个4M的大内存块，再次确保GC执行，之后就可以根据WeakHashMap的特性，查找有多少Activity还保留在其中，这些Activity就是泄露Activity。
　　关于内存检测
　　内存检测比较简单，弄清几个关键的指标就行，这些指标都能通过Debug。MemoryInfo获取。Debug。MemoryInfodebugMemoryInfonewDebug。MemoryInfo（）；Debug。getMemoryInfo（debugMemoryInfo）；appMemory。nativePssdebugMemoryInfo。nativePss10；appMemory。dalvikPssdebugMemoryInfo。dalvikPss10；appMemory。totalPssdebugMemoryInfo。getTotalPss（）10；
　　这里关心三个就行：
　　1。TotalPss（整体内存，nativedalvik共享）
　　2。nativePss（native内存）
　　3。dalvikPss（java内存OOM原因）
　　一般而言total是大于nativdalvik的，因为它包含了共享内存，理论上我们只关心native跟dalvik就行，以上就是关于内存的监测能力，不过内存泄露不是100正确，暴露明显问题即可，效果如下：
　　流量监测
　　流量监测的实现相对简单，利用系统提供的TrafficStats。getUidRxBytes方法，配合Actvity生命周期，即可获取每个Activity的流量消耗。具体做法：在Activitystart的时候记录起点，在pause的时候累加，最后在Destroyed的时候统计整个Activity的流量消耗，如果想要做到Fragment维度，就要具体业务具体分析了，简单实现如下：application。registerActivityLifecycleCallbacks（newApplication。ActivityLifecycleCallbacks（）｛OverridepublicvoidonActivityStarted（NonNullActivityactivity）｛super。onActivityStarted（activity）；！开始记录markActivityStart（activity）；｝OverridepublicvoidonActivityPaused（NonNullActivityactivity）｛super。onActivityPaused（activity）；！累加markActivityPause（activity）；｝OverridepublicvoidonActivityDestroyed（NonNullActivityactivity）｛super。onActivityDestroyed（activity）；！统计结果，并通知回调markActivityDestroy（activity）；｝｝；
　　电量检测Android电量状态能通过以下方法实时获取，只是对于分析来说有点麻烦，需要根据不同手机、不同配置做聚合，单处采集很简单。IntentFilterfilternewIntentFilter（Intent。ACTIONBATTERYCHANGED）；android。content。IntentbatteryStatusapplication。registerReceiver（null，filter）；intstatusbatteryStatus。getIntExtra（status，0）；booleanisChargingstatusBatteryManager。BATTERYSTATUSCHARGINGstatusBatteryManager。BATTERYSTATUSFULL；intscalebatteryStatus。getIntExtra（BatteryManager。EXTRASCALE，1）；
　　不过并不能获取绝对电量，只能看百分比，因为对单个Activity来做电量监测并不靠谱，往往都是0，可以在APP推到后台后，对这个在线时长的电池消耗做监测，这个可能还能看出一些电量变化。CPU使用监测
　　没想好怎么弄，显不出力。
　　3数据整合与基线制定
　　APP端只是完成的数据的采集，数据的整合及根系还是要依赖后台数据分析，根据不同配置，不同场景才能制定一套比较合理的基线，而且，这种基线肯定不是绝对的，只能是相对的，这套基线将来可以作为页面性能评估标准，对Android而言，挺难，机型太多。总结
　　启动有相对靠谱节点。
　　瞬时FPS（瞬时掉帧程度）意义更大。
　　内存泄露可以一个WeakHashMap简单搞定。
　　电量及CPU还不知道怎么用。
　　作者：看书的小蜗牛
　　转载地址：https：www。jianshu。comp978b7bce6290