阿里百川码力APP监控 来了！

阿里百川码力APP监控  来了！
这个APP监控 和手淘一块儿成长
历经千锤百炼 走过千BUG万坑
现在百川起产品   为了让你的APP更好 用户更爽！

 

在移动互联网时代，一款应用是否成功，用户体验是一个关键的因素。APM的发展使得用户体验愈来愈完善，本文经过90年代互联产品性能优化的发展过程到今天移动互联网时代下的APM可用性监控体系，如何去解决日渐复杂的业务致使功能不断迭代所突发的致命bug，以及日益增加的用户和膨胀的数据致使流量过大所出现的一些问题。

 

 

在《黑客帝国》电影中较为经典的一幕是让Neo在红药丸和蓝药丸中作出选择。红药丸做为一个跟踪程序，帮助Neo定位物理身体位置，不管在哪里，出现任何问题都可以第一时间定位并解决。而开发者基本都知道，想解决大部分的功能性问题的难点基本就在定位上，而电影里面出现的一些人工智能、机器学习、虚拟现实的技术，也只可以在科幻电影中才能看到。

季度活跃设备增加趋势

今天，在移动终端爆发以及用户需求的推进下，移动应用的“数量”和“体量”急速扩大，APP性能数据在优化产品上变得愈来愈重要，国内大批APM厂商仿佛一晚上间遍地开花，整个监控体系也从服务端到APP端再到H5端不断的增强和改变策略来适应不一样的场景需求，使得监控和优化的本质上已经发生了变化。

APM的雏形发展

在1996年时，Tivo与HP公司就从应用程序层面出发，他们认为网络无疑就是应用的速度。直至1998年，面向以组件为中心基础建设监控的APM产品出现，直到2011年，移动设备的普及和APP应用市场的爆发，让你们对移动端的性能体验要求也愈来愈苛刻。

在这个时候，国外的APM行业New Relic和AppDynamics已经在APM领域拔得头筹，国内一些APM厂商看准移动的这个趋势，APM仿佛一晚上之间遍地开花，直至今日，做为国内比较具备表明性的APM厂商有：听云、OneAPM、云智慧、博睿等，当前BAT领域也跻身这一领域，阿里百川码力APM（简称“码力APM”）也在云栖大会中发布公测。开发者无需从零开始构建性能探针、数据平台和控制台，就能够经过可视化、可运维的方式长期监控应用性能、及时解决应用中存在的问题。 

▲ APM 业务与 IT 发展关系变迁

APM可用性度量体系

现在，国内APM业务竞争愈来愈激烈，你们纷纷在可用性、用户体验上发力。好比，你们用手机淘宝，明显感受稳定性和流畅度比国内其余电商APP好不少，这不只仅是由于他们有一堆优秀的开发工程师，更关键是其背后那一套完善的性能监控度量体系。

经过性能监控体系，app上发生的性能指标都会被实时上报，而码力APM服务端会基于这些指标进行聚类和分析，聚合出问题和性能瓶颈，同时完善的日志信息也将支持开发工程师及时修复和优化。

阿里技术专家陈武认为，在性能优化方面，以往的度量是经过APP的打开率来进行对比，不少都是很是主观。而度量体系里面面临的一个很大的问题是常态化。那么，应该如何创建起这一套可视化的性能度量的体系呢？

阿里百川将影响用户使用的性能指标分为可用性度量和体验度量。

一、 可用性度量

可用性包含app可用性和服务可用性。app可用性问题中最多见的就是crash，而用户遇到crash以后，大部分会选择直接卸载app；服务可用性问题则包含网络链接和服务端错误，这类问题每每可能形成用户购买、订阅等关键操做不可用，从而致使资损，而这类问题若长期未能解决，也会致使用户流失。

这类问题须要第一时间被修复，越早修复，止损的效果就越好。

这须要客户端探针具备强大的采集能力。探针SDK将负责采集用户因为线程异常、内存溢出、手机杀进程等各类缘由致使的崩溃，并捕获到尽可能全面的环境信息，和用户操做轨迹来帮助开发者还原用户操做，定位问题。同时，对网络请求部分也是一样，探针SDK须要支持自动采集网络性能指标，并捕获错误网络请求的日志，来辅助开发工程师解决问题。

可是探针在用户app端采集的均是单一的事件，如有1000个用户出现可用性问题，那么服务端接收到的可能就是1000份日志。让开发工程师在海量的日志中排查问题，显然可行性不高。这就须要APM服务端实时对这些日志进行语义分析以及高效的聚类，好比，将1000条用户日志聚合为3个问题，经过控制台反馈给开发者。这将大大提高开发工程师排查和解决问题的效率。

二、 APP体验度量

APP体验是影响用户留存和活跃的关键，你们对APP使用过程当中“如丝般顺滑”都具备自然的好感。可是目前市场大部分APP的体验依旧很是差，用户常会面对卡顿、图片加载失败、页面长时间等待等各类不良体验。这个时候，很是须要有一个系统体系化的去陈列和度量这些体验类问题。

APM控制台对卡顿的处理方式和崩溃相似，同类型的卡顿将被聚类在一块儿，发生该卡顿的用户详细日志也聚合在一块儿能够翻页查阅。而对图片加载失败等，页面元素没法正常显示的问题，则能够关注该图片所在静态资源的服务主机是否异常（单分钟请求量过多、图片过大等）。若该静态资源服务正常，则能够关注请求该图片的URL的错误率，能够反推是否为图片自己的问题。

在性能优化的量化方面，如何帮助企业去作定制？陈武认为，应该串联关键路径所须要的所有URL，从关键路径总体来看服务的健康度指标，而非关注所有的URL。好比经过网络性能监控，开发者无需对全部的URL进行关注，不一样的开发者关注的核心业务不一样，你们关注的URL也不同。好比，在电商的场景，一个关键的路径是用户经过登陆，打开商品，进入详情，而后下单到支付，经过把对应的关键路径全部的URL整合在一块儿，保障这条关键链路的性能，才可以强化核心业务的服务以及稳定性。

APM的可用性检测方式

▲ 阿里百川码力APM的监控体系

对于增强应用的可用性，APM通常都采起应用监控结合服务监控的形式，使得开发者实现端到端的全链路性能管理。在码力APM监控体系中，阿里巴巴技术专家熊奇介绍了码力APM在监控体系里面的应用监控、服务监控、数据库以及消息推送等性能监控，主要经过如下方式来完成：

★ 在应用监控上，采集了iOS、Android应用的内存、CPU、崩溃、网络等方面的性能数据；

★ 在服务监控上，支持Tomcat、Jetty、JBoss容器和Spring、Struts等框架的性能检测；

★ 支持MySQL等SQL数据库和Redis、Mem cache等NoSQL数据库的性能检测；

★ 码力APM还提供了支持淘宝消息服务TMC、分布式框架Dubbo、淘宝API调用的性能检测。

对于数据采集以后会统一进入能够承载海量数据的存储系统和日志系统，统计系统会利用落地的数据完成数据的计算处理、生成报表，帮助开发者长期跟踪应用和服务的性能，而告警系统则会根据规则在问题发生时发出短信、邮件等即时告警，从而帮助开发者及时解决问题，下降损失。

可用性的度量检测方式-性能

在应用开发时，程序错误、主线程卡顿和资源使用超过系统限制致使的崩溃，是最严重、也是须要首先解决的问题。

一般开发者会借助模拟器、Instrument或者自动化测试发现一部分问题，可是测试每每难以覆盖用户使用场景下的设备、网络等环境。若是借助于社交媒体或者邮件反馈渠道，虽然能够有限地拿到真实的用户反馈，可是用户每每不能清楚的描述出复现问题所需的信息，往复沟通成本极高。因此，在客户端上，码力APM经过如下检测方式来收集应用崩溃信息。

码力APM在信号捕获方式中，经过sigaction设置信号中断时的回调，这样，就能够在回调中根据程序运行状态生成对应的崩溃日志。此外，对于SIGARBT(abnormal termination)，咱们还须要经过NSSetUncaughtExceptionHandler来获取未捕获异常的堆栈，来补全崩溃信息。

然后，把崩溃日志上报到码力APM，会依据崩溃日志的堆栈信息，聚合同一类型的崩溃后写入数据存储。同时，告警系统能够依据崩溃次数、崩溃率等规则，即时发出告警。

此外，码力Apm提供了dSYM上报脚本，在Xcode的build phrase中添加脚本，就能够在编译成功后自动上报dSYM文件。经过对dSYM文件的解析，从新聚合后写入数据存储，聚合能够减小高达90%数据库行数；同时，也实现了崩溃日志符号化。不依赖mac环境符号化，更好地利用云计算平台服务更多开发者。

第二种技术是卡顿检测，卡顿检测的基础是RunLoop，经过RunLoop Observer监听主线程RunLoop状态的变动。在这里，把RunLoop看成在操场上跑圈的运动员，把Before Sources当作每圈的起点，同时另外开启一条线程做为计时员，每5秒判断一次RunLoop是否跑过一圈。若是5秒内RunLoop没有完成一次RunLoop，则视为主线程卡顿。在发现主线程卡顿后，会生成卡顿日志，若是是复现的卡顿，能够选择不重复上报。

此外，针对设备不一样的运行时期，如启动阶段、后台阶段、空闲阶段，咱们会动态调整阈值，下降检测的开销。

对于没法经过信号捕获、卡顿检测的崩溃，码力APM引入了应用停止检测，停止检测虽然不能还原崩溃现场，可是能够揭示问题的存在。在应用进入active状态时，码力APM在持久存储上设立一个标志位，表示程序在正常运行。在应用退出active状态或检测到崩溃时，码力APM就清除持久存储上的标志位，表示程序在已知的状况下退出。这样，在下一次应用启动时，若是持久存储上的标志位为真，则说明应用上一次运行在未知状况下退出，这种状况码力APM就计为应用非正常停止上报。

同时，为了过滤由于电量耗尽致使的关机，码力APM还增长了电量检测，在低电量时，清除标志位，避免停止误报。

可用性的度量检测方式-网络

请求错误、流量开销高、被运营商劫持等网络问题是应用开发时另外一类棘手的问题。固然咱们也能够借助模拟器、Instrument或者自动化测试发现简单的网络问题，可是测试难以覆盖复杂的用户网络环境，也难以导出网络性能数据进行长期比对监控。若是使用手工埋点的方式记录网络性能，一方面，咱们须要应对多种系统网络接口，另外一方面，咱们须要同步应用网络代码和埋点代码，维护成本将会居高不下。

为了监控应用在真实网络环境中的性能，码力APM中引入了无痕埋点的网络性能监控，在网络检测中引入三种注入技术，帮助开发者长期监控应用的网络性能，优化产品用户体验。

第一种是Method Swizzling。每个NSObject类都包含一个isa指针，指向objc_class结构体，而每个objc_class结构体又包含一个methodLists指针，指向objc_method_list结构体数组，在objc_method_list里又包含一个objc_method结构体成员，且每个objc_method包含一个method_imp指针，指向方法实现。

所以，只要能修改method_imp的值，咱们就能替换原有的实现。在<objc/runtime>中，经过class_getClassMethod和class_getInstanceMethod取得objc_method结构体指针，然后经过method_getImplementation取得方法的原始实现地址originIMP，以后在imp_implementationWithBlock生成新实现imp的参数block里，调用原始实现，就能够原有行为先后加入网络性能埋点行为。最后调用method_setImplementation替换方法实现。这样，任何调用都将使用新的实现。

第二种技术是Proxy。在Objective-C里，NSProxy是除NSObject外惟一的根类。NSProxy是一个实现了NSObject协议的抽象类，它的正常运做须要子类override -methodSignatureForSelector:方法为sel提供方法签名，以及-forwardInvocation:方法来完成调用的转发。

使用Proxy来注入NSURLConnection、NSURLSession等对delegate的回调。具体来讲，在delegate proxy收到消息时，若是不是目标协议方法，则经过消息转发机制，转发给原delegate；若是是目标协议方法，则直接调用proxy实现，在proxy实现中委托调用原delegate；此外，多数协议和协议方法都是可选的，所以，在proxy的实现中须要实现-conformsToProtocol:和-respondsToSelector:方法来声明proxy额外加入的协议和方法。这样，咱们就能在不影响原有回调的同时，增长网络性能埋点逻辑。

第三种技术是fishhook。使用fishhook来替换动态连接库中的C函数实现，具体来讲是CFNetwork和CoreFoundation中的相关函数。这里，以开车的模型来解释动态连接。设想一名新手司机开车从巴黎到罗马，由于他不知道路线，因而他先去咨询老司机；老司机告诉他正确的线路，这一次他可能还会绕点路，但下一次，他就会按照老司机的建议直接开到罗马。

相应的，在程序运行时，动态连接的C函数dynamic(...)地址记录在__DATA segment下的__la_symbol_ptr中；初始时，程序只知道dynamic函数的符号名而不知道函数的实现地址；首次调用时，程序经过__TEXT segment中的__stub_helper取得绑定信息，经过dyld_stub_binder来更新__la_symbol_ptr中的符号实现地址；这样，再次调用时，就能够经过__la_symbol_ptr直接找到dynamic函数的实现；若是咱们须要替换dynamic函数的实现，只须要修改__la_symbol_ptr便可。具体的实现方式，能够参阅Facebook的开源框架fishhook。

增强可用性的优化手段

经过以上两种检测方式，基本可以大部分的性能和网络需求，使得开发者可以知足现在移动互联网下用户的苛刻的需求，那么，创建起来的度量体系后，了解的具体的问题后，咱们应该如何去解决这些问题来提高可用性呢？

一、网络安全

运营商、DNS被劫持问题是应用开发时一类棘手的问题， 解决方案也比较多。51信用卡技术总监汪睿认为，51信用卡做为金融属性的产品，基于安全考虑会放在第一位。解决方案主要是基于全栈HTTPS的方案来处理，但会带来一些成本和性能上的损耗。甚至能够像FaceBook、google等一些解决方案，使用HTTP2.0方式，这取决于公司和开发者自身去评估实现的成本。汪睿还介绍了早起的一个过渡方案，那就是HTTP的DNS方式，经过获取一个IP表经过IP来直接链接，能够避免HTTP劫持的问题。

而网络是一个端到端的技术，阿里高级技术专家陈武认为，从电商的场景看，首先要保证服务端的稳定性，服务端能够有反刷，限流，单元化，异地容灾，服务降级等策略保证链接的稳定性。另外，客户端的角度主要看链接链路和数据量。链路里面资源能够作多CDN的备份，经过HTTP DNS或者HTTPS，HTTP2.0来反劫持。在链路稳定的基础上，接着去保证传输的效率，这里面能够经过就近接入，链接复用，提高压缩率，使用二进制协议等技术来减小包大小。固然，这里面最重要的是端到端的网络监控体系，这样在网络服务治理上会更有抓手。

二、系统降级

降级的解决方案，是系统性能保障的最后一道防线，从性能优化的角度上说，没有100%完善的设计，总会有一些意料突发的状况致使性能恶化。因此，在系统设计时，必须作好降级设计。

饿了么移动首席架构师王朝成认为，在饿了么517大促活动上，服务器端承受很是大的压力，这个时候会经过降级部分服务的方式，来确保大促秒杀这种场景得以正常运行。可是，在用户端上，以及APP，还在不断积极的发送用户请求和数据，反而增长服务器集群的压力。这个时候，王朝成表示，他们会考虑把一部分的SDK或者APP上的服务也进行降级，来减小服务端在分析数据上的压力。

降级分为手动降级和智能降级，在策略上分为流量降级、效果降级、功能性降级。流量降级主要表如今经过主动拒绝处理部分流量早餐部分用户服务不可用。而效果降级和功能性降级都表现为服务质量的降级，一个是经过在流量高峰时期用相对低质量、低延时的服务来保障全部用户的服务可用性，另一个是经过减小功能的方式来提升用户的服务可用性。

三、网络性能

从数据结构上，须要根据不一样的业务场景来选择合适的数据结构，在数据流量较少的状况可能客户端上表现不出什么区别，当在数据流量过大，且数据结构复杂的时候极可能就是直接影响到APP的性能。

相似餐饮领域“饿了么”这样的应用，数据发送的频率使得据量会很是大，对用户来讲可能没有什么感知，可是商家接收大量的订单，数据量影响很大，感知比较明显。王朝成认为，能够考虑一些新的协议（Protobuf, Flatbuf）来优化数据量，好比HTTP2.0能够压缩http协议的header，使用encoder来减小须要传输的header大小，经过通信双方各自cache一份header fields表，对于相同的数据再也不经过每次请求和响应发送，又减小了须要传输的大小。再一个是采起二进制的协议，只认0和1的组合，经过把原来http1.x的header和body部分用frame从新封装，实现方便且健壮。经过内容压缩与并发传输机制，在低速、不稳定的无线条件下，较少其http body的发送大小，改善用户体验和资源效率。

▲ http1.x和http2.0协议关系

同时，阿里高级技术专家陈武也表示，若是在链路没有问题的状况下，那么必须在整个网络传输层要尽可能快，否则很容易出现timeout。因此，第一要从协议层，在协议层里面经过http2.0来减小包头的压缩，同时支持服务端push消息，且经过双统统道，对通道复用更快。第二是从数据层，数据能够经过二进制压缩。在整个网络连通率较低的时候，将打包拆成小包，达到很好的传输效果。

四、动态热修复

所谓热修复，就是使用热补丁动态修复技术，经过向用户发送Patch，在用户无感知的状况下完成一些致命bug的修复。51信用卡客户端负责人汪睿认为，在移动客户端上最大的一个问题是发版，对于iOS的用户来讲，整个修复流程比较漫长。须要提交审核，可是在这段时间有可能已经错过不少用户。他认为，热修复技术可以很快并及时的在线进行修复，一般在使用的过程当中就完成的修复过程。

在热修复技术上，Android经常使用的是基于Android dex分包方案，而iOS能够利用JSPatch，它可使得你用JavaScript书写原生iOS APP，只须要在项目中引入极小的引擎，就能够用JavaScript调用任何的Objective-C的原生接口。

总结

以上所谈到的性能优化手段基本是为了解决三种状况所形成的问题：1. 日渐复杂的业务致使功能不断迭代所突发的致命bug修复方式，2. 日益增加的用户和膨胀的数据致使流量过大，3.网络安全和内存开销的问题。

本文经过不一样的场景来分析移动性能优化的模式，能够经过肯定场景下解决某一类型的问题。固然，咱们不能仅仅经过了解性能优化所解决的问题以及手段，更重要的是须要清楚该问题所发生的场景、缘由须要的成本。

做者 51CTO 林师授