移动端监控体系之技术原理剖析

在这样一个注重用户体验的时代,APM 技术快速发展,国内更是百花齐放,最近对各个公司的 APM 产品有一个调研,并在此基础上进行了自己的实践。这里就从 iOS 的角度出发,谈谈自己对移动端 APM 的技术上的理解,并提供相对应的实例。

何为 APM

APM 的全称是Application performance management,即应用性能管理,通过对应用的可靠性、稳定性等方面的监控,进而达到可以快速修复问题、提高用户体验的目的。

国内各大公司都有自己的一套监控体系,这个系统可能是自己研发,也可能是第三方提供,当然对于这个数据为王的时代,很多有实力的公司倾向于自主研发,掌握核心数据。比较有代表性的 APM 产品有:听云、阿里百川、腾讯 bugly、NewRelic、OneAPM、网易云捕等

说到监控,那么指标是我们所关注的呢?如下所示

  • 网络请求:成功率、状态码、流量、网络响应时间、HTTP与HTTPS的 DNS 解析、TCP握手、SSL握手(HTTP除外)、首包时间等时间
  • 界面卡顿、卡顿堆栈
  • 崩溃率、崩溃堆栈
  • Abort 率:也就是由于内存过高的等原因,被系统杀死的情况
  • 交互监控:页面加载时间、页面的交互痕迹
  • 维度信息:地域、运营商、网络接入方式、操作系统、应用版本等
  • 其他:内存、帧率、CPU使用率、启动时间、电量等

聊聊原理

卡顿检测

当应用发生卡顿的时候,一般会伴随着掉帧,所以帧率是最容易想到的指标来判断卡顿。对于线下的测试环境,我们可以使用帧率来对开发做一些提示,告诉他们可能发生了卡顿。但是帧率不稳定性较高,所以一般会采取另一种方式来做卡顿检测。那就是Runloop,对于细节可以查看 Runloop 源码,会发现对于事件的处理主要就是在kCFRunLoopBeforeSources和kCFRunLoopBeforeWaiting状态之间,还有kCFRunLoopAfterWaiting之后。那我们就可以对两个状态进行监控,如果消耗时间太久,就代表着卡顿的发生。

阿里百川

上图摘自阿里百川,如图所示,我们会对卡顿次数做一个判断,如果次数为1,但时间超时,则为单次耗时较长的卡顿,如果次数到达阀值,则证明是连续短时间卡顿。

当卡顿发生之后,我们为了定位,会收集当时的一个堆栈情况,在此你可以使用 PLCrashReporter 来做,也可以自己研发一个堆栈收集库(可参考http://www.jianshu.com/p/7e4c7b94ca36来做)

对于实例,网上已经有很多开源的项目,你可以参考https://github.com/suifengqjn/PerformanceMonitor

崩溃检测

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

Mach 异常捕获

如果想要做mach 异常捕获,需要注册一个异常端口,这个异常端口会对当前任务的所有线程有效,如果想要针对单个线程,可以通过 thread_set_exception_ports注册自己的异常端口,发生异常时,首先会将异常抛给线程的异常端口,然后尝试抛给任务的异常端口,当我们捕获异常时,就可以做一些自己的工作,比如,当前堆栈收集等。

对于如何注册一个异常端口,这里有示意图和 PLCrashReporter https://github.com/plausiblelabs/plcrashreporter可以参考

Unix 信号捕获

对于Mach 异常,操作系统会将其转换为对应的 Unix信号,所以如果你对Mach不熟悉的话,也可以通过注册signalHandler的方式来做信号异常。对于实例,你可以参考https://github.com/xcysuccess/iOSCrashUncaught


  1. signal(SIGHUP, signalHandler); 
  2.  
  3. signal(SIGINT, signalHandler); 
  4.  
  5. signal(SIGQUIT, signalHandler); 
  6.  
  7.   
  8.  
  9. signal(SIGABRT, signalHandler); 
  10.  
  11. signal(SIGILL, signalHandler); 
  12.  
  13. signal(SIGSEGV, signalHandler); 
  14.  
  15. signal(SIGFPE, signalHandler); 
  16.  
  17. signal(SIGBUS, signalHandler); 
  18.  
  19. signal(SIGPIPE, signalHandler);  

NSException 捕获

对于NSException异常,也比较容易处理,通过注册NSUncaughtExceptionHandler捕获异常信息即可,将拿到的NSException细节写入Crash日志,上传到后台做数据分析


  1. // register the uncaught exception handler 
  2.  
  3. SetUncaughtExceptionHandler(&handler);  

Abort 率检测

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

  • 程序启动,设置标志位
  • 程序正常退出,清楚标志
  • 程序Crash,清楚标志
  • 程序电量过低导致关机,这个也没办法直接监控,可以加入电量检测来辅助判断
  • 第二次启动,标志位如果存在,则代表Abort一次,上传后台做统计 

阿里百川

交互监控

对于页面的加载时间,这个比较容易实现,直接通过Runtime hook对应的生命周期方法即可,比如 viewDidLoad、viewWillAppear等

对于用户的交互痕迹,比如点击了那个按钮、跳转到了那个页面,这些信息偏于用户行为的收集,我们也独立研发了一个无埋点的SDK,专门来做用户行为数据的收集与分析,核心也是基于 hook AOP的思想。细节可以参考我同事的作品

网络监控

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

  • 针对URLConnection、CFNetwork、NSURLSession三种网络做Hook,hook的具体技术可以是method swizzle 也可以是Proxy、Fishhook之类的
  • 也可以使用 NSURLProtocol 对网络请求的拦截,进而得到流量、响应时间等信息,但是NSURLProtocol有自己的局限,比如NSURLProtocol只能拦截NSURLSession,NSURLConnection以及UIWebView,但是对于CFNetwork则无能为力

对于第一种方式可以Hook哪些方法的,可以参考这个图

对于 HTTP与HTTPS 的 DNS 解析、TCP握手、SSL握手(HTTP除外)、首包时间等时间的统计,稍有难度

但是,因为我们所使用的URLConnection、CFNetwork、NSURLSession底层都是 BSDSocket,所以可以尝试在socket上动手脚来实现效果,类似于通过ViewController的生命周期方法来统计页面加载时间的做法,我们Hook socket相关的方法来做,比如通过hook socket连接时的 connect方法,拿到tcp握手的起始时间,通过hook SSLHandshake方法,在SSLHandshake执行的时候拿到 SSL握手的起始时间等。目前听云已经提供了 HTTP 的分段时间查询功能,大家去体验下


  1. int connect(int, const struct sockaddr *, socklen_t) __DARWIN_ALIAS_C(connect); 
  2.  
  3. OSStatus SSLHandshake(SSLContextRef ctx)  

但是对于 iOS 9 Apple 加入 ATS 新特性,并要求开发者使用 HTTPS,我在 iOS9、10上对 HTTPS 网络请求Hook socket方法时候,有一些方法hook 失效,猜想应该是Apple 进行了加固、加密,导致一些系统方法没办法hook,所以在 iOS9、10 上无法通过socket来取得HTTPS网络的分段时间

不过apple在 iOS 10 推出一个API,可以在 iOS10 版本以上进行网络信息的收集


  1. - (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didFinishCollectingMetrics:(NSURLSessionTaskMetrics *)metrics 

打印结果如下


  1. (Fetch Start) 2017-02-24 09:03:06 +0000 
  2.  
  3. (Domain Lookup Start) 2017-02-24 09:03:06 +0000 
  4.  
  5. (Domain Lookup End) 2017-02-24 09:03:06 +0000 
  6.  
  7. (Connect Start) 2017-02-24 09:03:14 +0000 
  8.  
  9. (Secure Connection Start) 2017-02-24 09:03:14 +0000 
  10.  
  11. (Secure Connection End) 2017-02-24 09:03:16 +0000 
  12.  
  13. (Connect End) 2017-02-24 09:03:16 +0000 
  14.  
  15. (Request Start) 2017-02-24 09:03:16 +0000 
  16.  
  17. (Request End) 2017-02-24 09:03:16 +0000 
  18.  
  19. (Response Start) 2017-02-24 09:03:16 +0000 
  20.  
  21. (Response End) 2017-02-24 09:03:16 +0000  

当然,对于网络各层次的时间获取,如果你有好的方案,希望您可以留言告知。同时对于一些维度信息和内存等基础指标,很容易获取,这里就不细谈了

大礼包

在调研和学习APM技术的过程中,发现了很多优秀的博客,所以在此推荐给大家,有需要的可以自取

  • 蘑菇街移动端全链路跟踪保障体系

http://t.cn/R5whClL

  • 美团外卖移动端性能监测体系实现

http://t.cn/RIUcX0o

  • 微信读书 iOS 质量保证及性能监控

http://t.cn/RibKdFW

  • 网易NeteaseAPM iOS SDK技术实现分享

http://t.cn/R5ZyWVt

  • 阿里百川码力APP监控来了 重量级选手进入APM市场

http://t.cn/RfjDrvt

  • APM最佳实践系列文章专题合辑

http://t.cn/RxZQOto

  • 手机淘宝:亿级用户APP的快速运维交付实践

http://t.cn/RibFFYO

作者:伯乐专栏/佳乐

来源:51CTO

时间: 2024-08-29 07:13:39

移动端监控体系之技术原理剖析的相关文章

图片病毒技术原理剖析

一.被诅咒的油画 在网络上流传着一幅诡异的油画,据说很多人看后会产生幻觉,有人解释为油画的构图色彩导致的视觉刺激,也有人认为是心理作用,众说纷纭,却没有令人信服的答案.在网络公司上班的秘书小王也从一个网友那里得知了这幅画,她马上迫不及待的点击了网友给的图片连接. 图片出来了,小王终于见识到了传说中诡异的油画,面对着屏幕上那两个看似正常的孩子,她却觉得背后凉飕飕的.那网友也很热心的和她聊这幅画的来源,小王入神的听着,丝毫没有注意到IE浏览器左下角的状态栏打开页面的进度条一直没停止过. 如果说小王刚

Docker监控技术原理和阿里云容器监控服务实践

在组织的云栖计算之旅第2期-Docker在云平台上的最佳实践专场中,阿里云晨末做了题为Docker监控原理和阿里云容器监控服务实践的分享.在本次分享中,他谈到了监控的重要性并且针对于Docker容器的监控技术进行了精彩分享.   本次分享的内容看起来非常高大上,但其实原理却非常简单.本次主要将分享两个部分,一部分将会分享Docker相关的监控原理,另外一部分就是介绍一下阿里云容器服务.在国内而言,阿里云的Docker产品是比较先进的,因为我们进行了大量的用户调研,所以很多用户想将业务迁移到Doc

听云廖雄杰:全栈APM,打造端到云的全方位监控体系

 [51CTO.com原创稿件]2017年4月14日-15日,由51CTO主办的WOTA全球架构与运维技术峰会在北京富力万丽酒店隆重召开.本次WOTA设置了15大前沿热点技术论坛,60+来自Google.LinkedIn.Airbnb.百度.阿里巴巴.腾讯等海内外一线互联网公司的技术大咖将带来超过50个历经沉淀的架构实战心得与成功经验分享案例,携手打造历时2天的行业顶级技术盛会. 在4月14日上午WOTA2017主会场,听云研发副总裁廖雄杰进行了主题为<全栈APM,打造端到云的全方位监控体系>

秋色园QBlog技术原理解析:UrlRewrite之URL重定向体系(四)

文章回顾: 1: 秋色园QBlog技术原理解析:开篇:整体认识(一) --介绍整体文件夹和文件的作用 2: 秋色园QBlog技术原理解析:认识整站处理流程(二) --介绍秋色园业务处理流程 3: 秋色园QBlog技术原理解析:UrlRewrite之无后缀URL原理(三) --介绍如何实现无后缀URL   附说: 为了加快 秋色园 和 CYQ.Data 数据框架 的开源速度及更好的发展, 目前正在寻找开源团队成员,有意向创业加入者, 欢迎点击看此贴:秋色园[CYQ.Data]开源团队寻人   OK

【Xamarin 跨平台机制原理剖析】

原文:[Xamarin 跨平台机制原理剖析] [看了请推荐,推荐满100后,将发补丁地址]   Xamarin项目从喊口号到现在,好几个年头了,在内地没有火起来,原因无非有三,1.授权费贵 2.贵 3.原生态Java开发Android的越来越多,人工费用成本降低. 上面说的3条,都跟钱相关,不占技术边,看起来跟本文的标题严重不符.但是,细细看来,如果这个产品的圈子打不开,再牛的技术,也是枉然.因为技术是在不断推进的, 性能问题,技术问题,实现问题,等等都可以随着时间的推动去解决,但是,Xamar

【Xamain 跨平台机制原理剖析】

原文:[Xamain 跨平台机制原理剖析] [看了请推荐,推荐满100后,将发补丁地址]   Xamarin项目从喊口号到现在,好几个年头了,在内地没有火起来,原因无非有三,1.授权费贵 2.贵 3.原生态Java开发Android的越来越多,人工费用成本降低. 上面说的3条,都跟钱相关,不占技术边,看起来跟本文的标题严重不符.但是,细细看来,如果这个产品的圈子打不开,再牛的技术,也是枉然.因为技术是在不断推进的, 性能问题,技术问题,实现问题,等等都可以随着时间的推动去解决,但是,Xamari

打造立体化监控体系的最佳实践——分布式调用跟踪和监控实践

摘要: 本文将从分布式系统调用的复杂现状说起,具体分析调用链的三大使用场景,以及调用链的最佳实践,简述如何将调用链作为排查问题的核心,通过其可以将各类数据关联在一起,提高问题排查能力. [最新快讯]EDAS上线方法追踪新特性,打通应用诊断的"最后一公里". 1. 分布式调用系统的现状 当前,随着互联网架构的扩张,分布式系统变得日趋复杂,越来越多的组件开始走向分布式化,如微服务.消息收发.分布式数据库.分布式缓存.分布式对象存储.跨域调用,这些组件共同构成了繁杂的分布式网络. 如上图右侧

打造立体化监控体系的最佳实践

1. 分布式调用系统的现状 当前,随着互联网架构的扩张,分布式系统变得日趋复杂,越来越多的组件开始走向分布式化,如微服务.消息收发.分布式数据库.分布式缓存.分布式对象存储.跨域调用,这些组件共同构成了繁杂的分布式网络. 如上图右侧所示,当应用A发出某个请求时,其背后可能有数十个甚至更多的服务被调用,可谓是"牵一发而动全身". 如果将分布式系统比作高速公路网,每个前端的请求就相当于高速上行驶的车辆,而处理请求的应用就是高速上的收费站,在收费站上将车辆通行信息记录成日志,包括时间.车牌.

《工业控制网络安全技术与实践》一一2.5 PLC设备的技术原理

2.5 PLC设备的技术原理 前面简单介绍了PLC的基本概念.应用领域和特点,本节将详细介绍PLC设备的产生与特点.基本组成.工作原理及其使用的指令系统.通信技术和接口技术.2.5.1 PLC的产生与特点 在可编程逻辑控制器问世之前,继电器控制在工业控制领域占主导地位.继电器控制系统采用固定接线的硬件实现控制逻辑.如果生产任务或工艺发生变化,就必须重新设计和改变硬件结构,这样就会造成时间和资金的浪费.另外,大型控制系统用继电器.接触器控制,使用的继电器数量多.体积大.耗电多,且继电器触点为机械触