客户端性能监控方案

2018-08-16  本文已影响0人  CHEN_JC

Application Performance Management(APM),应用程序性能管理, 主要指对企业的关键业务应用进行监测、优化,提高企业应用的可靠性和质量,保证用户得到良好的服务。一个企业的关键业务应用的性能强大,可以提高竞争力,并取得商业成功。

概述

性能监控需要关注的指标主要有以下几类
1、网络请求:成功率、状态码、流量、网络响应时间、HTTP与HTTPS的 DNS 解析、TCP握手、SSL握手(HTTP除外)、首包时间等时间

Network方面:(按时间-版本:+域名,+地区,+运营商, +连接网络类型)

  • 平均相应时间
  • rpm(一分钟请求次数)
  • 总耗时
  • 传输数据大小
  • 再具体到某个API接口:
    (1) 平均http响应时间 (区分web Application(webview) 和 network);
    (2) rpm;
    (3) 平均数据传输大小(区分send和receive);

2、界面卡顿(FPS)、卡顿堆栈
3、崩溃率、崩溃堆栈
4、Abort 率:也就是由于内存过高的等原因,被系统杀死的情况
5、交互监控:页面加载时间、页面的交互痕迹

APP启动次数、APP启动平均时间;
Controller display次数、平均display时间;
Controller display过程中各个method(包括UI thread、worker thread中的method)的平均执行时间;

6、维度信息:接入网络、运营商、设备、系统版本、地区、app版本、统计时间
7、其他:内存、帧率、CPU使用率、启动时间、电量等

CPU和当前页面信息结合,可以评测每个页面的运算复杂度;
内存和App运行时间结合,可以观察内存和使用时长的关系进而分析是否发生内存泄漏;
FPS和卡顿信息结合,可以评估这次卡顿发生时App的性能究竟下降到什么程度。

网络请求

界面卡顿、卡顿堆栈
iOS:

Runloop,对于事件的处理主要就是在kCFRunLoopBeforeSources和kCFRunLoopBeforeWaiting状态之间,还有kCFRunLoopAfterWaiting之后。那我们就可以对两个状态进行监控,如果消耗时间太久,就代表着卡顿的发生。


image.jpeg
崩溃率、崩溃堆栈

iOS:对于崩溃的情况,一般是由 Mach异常或 Objective-C 异常(NSException)引起的。我们可以针对这两种情况抓取对应的 Crash 事件。


Abort 率

目前对于内存过高被杀死的情况是没有办法直接统计的,一般通过排除法来做百分比的统计,原理如下


交互监控
iOS

对于页面的加载时间,直接通过Runtime hook对应的生命周期方法即可,比如 viewDidLoad、viewWillAppear等
对于用户的交互痕迹,比如点击了那个按钮、跳转到了那个页面,这些信息偏于用户行为的收集,可以研发一个无埋点的SDK,专门来做用户行为数据的收集与分析,核心也是基于 hook AOP的思想。


网络监控
iOS

对于成功率、状态码、流量,以及网络的响应时间之类的,我们可以主要可以通过两种方式来做

Android

基于AspectJ的AOP方式拦截网络请求API实现流量统计


SDK设计
image.png
数据上传策略
编号 策略名称 说明
1 MTA_STRATEGY_INSTANT 实时发送,app每产生一条消息都会发送到服务器。
2 MTA_STRATEGY_ONLY_WIFI 只在wifi状态下发送,非wifi情况缓存到本地。
3 MTA_STRATEGY_BATCH 批量发送,默认当消息数量达到30条时发送一次。
4 MTA_STRATEGY_APP_LAUNCH 只在启动时发送,本次产生的所有数据在下次启动时发送。
5 MTA_STRATEGY_DEVELOPER 开发者模式,只在app调用void commitEvents(Context)时发送,否则缓存消息到本地。
6 MTA_STRATEGY_PERIOD 间隔一段时间发送,每隔一段时间一次性发送到服务器。

SDK默认为MTA_STRATEGY_APP_LAUNCH + wifi下实时上报,对于响应要求比较高的应用,比如竞技类游戏,可关闭wifi实时上报,并选择MTA_STRATEGY_APP_LAUNCH或MTA_STRATEGY_PERIOD上报策略。

上一篇 下一篇

猜你喜欢

热点阅读