转载

干货 | 透视宝Smart SDK实现原理与案例解析

透视宝是云智慧的新一代应用性能管理(APM)平台,面向业务提供全栈性能监控、分析与管理的云端解决方案。对于移动应用的性能问题,透视宝是通过嵌入SDK来实现真实用户体验跟踪的,支持Native、H5以及混合开发模式的应用监控,帮助开发人员实时发现与定位应用崩溃、加载缓慢等各种故障与性能问题。

干货 | 透视宝Smart SDK实现原理与案例解析

透视宝在移动端嵌入的SDK被称为Smart SDK,它是如何实现对不同移动应用用户行为与体验数据智能采集的呢,又有哪些实际应用呢,云智慧高级开发攻城狮Alvin将为您逐一解读。

Smart SDK能干嘛?

总结一句话就是Smart SDK能够解决开发者的痛点,给业务人员出决策参考意见。移动开发者的痛点就是各种Bug:卡顿、闪退、页面加载慢、网络连接超时,网络被劫持;而业务人员的正确决策需要关注真实用户的体验。把这些需求归结为技术实现,主要有3部分:网络监控、事务监控、Crash信息收集。

干货 | 透视宝Smart SDK实现原理与案例解析 详细功能图如下图所示:

干货 | 透视宝Smart SDK实现原理与案例解析 Smart SDK功能图

针对HTTP的网络数据收集主要分为以下指标:请求时间、网络吞吐量和网络错误,劫持分析等。

请求时间是指一个http请求从发起请求到接收到服务端的响应,这期间所经历的时间。这个指标可以跟踪后台接口的响应是否正常,网络环境是否正常。

网络吞吐量是指单位时间内某一个url请求的次数。这个指标可以跟踪后台接口是否能够响应大规模的请求。因为单位时间内某个接口的响应次数是100和10000,不管是技术层面还是业务层面,都会做出不同的响应。某个接口有大规模的请求,技术上就要做压力评估,业务上则应该加大跟踪和投入了。

网络错误主要是跟踪url请求过程中的错误,分为http本身的错误和因网络状况出现的错误。

针对Socket的网络数据收集,主要包括Socket建立连接的耗时、DNS解析耗时、连接异常、数据读写异常的。

事务监控里面的用户行为监控,能够将所有的性能数据串起来,就可以满足开发者和业务人员的需求,也就是我们常说的基于业务的性能监控。事务监控可以分为很多类,有用户的操作,页面的加载,图片的渲染,线程操作,数据解析等。

用户操作主要是监控APP里的点击事件;

页面加载要监控页面加载周期的各个接口,除了用户的操作外,APP的所有业务逻辑都是在页面的生命周期函数中做的;

图片加载也是影响APP性能的罪魁祸首之一,美工切的一张简单的图,在APP里渲染、显示出来,会消耗不少的资源,因此将它作为一个性能消耗点来监控;

线程操作是导致主线程卡顿的主因;

数据解析虽然可以在子线程里做,但都是同步的,会导致页面加载变慢。

APP崩溃一直是移动开发者最大的痛点,所以收集崩溃日志,快速定位问题根源,是最好的解决办法。

而用户信息收集可以将APP的性能数据和真实用户对应起来,在发现APP性能问题后,第一时间与真实用户建立联系,沟通解决。

上面这些就是Smart SDK所能实现的功能。

Smart SDK实现原理

下面先以iOS应用为例说一下透视宝Smart SDK是如何实现应用性能监控的。iOS平台的原生开发语言是Objective-C,具有动态运行时的特点,Cocoa框架提供了很多动态运行时接口可以对OC接口进行hook,也就是方法拦截。

通过方法拦截,就可以获取到方法的参数值,方法执行开始、结束的时间戳。。。方法执行的性能数据就出来。

干货 | 透视宝Smart SDK实现原理与案例解析 OC方法拦截原理图

OC有一个很好用的语法,叫Category。通过Category,可以给原有的类(系统类,自己的类)添加一个新的接口,OC中叫selector(方法选择器),每一个方法,对应一个实现体(IMP),类似函数入口地址。

通过Category新增一个SelectorN方法,使用动态运行时函数交换SelectorC与SelectorN的实现体,就实现了两个方法的交换。SelectorC与SelectorN除了名字不一样 ,其他的都一样(参数和返回值)。开发者在调用SelectorC时,就会调用到SelectorN。我们的目的就达到了。

APP启动,在类文件加载进内存时,系统会调用每一个类的load类函数(Swift工程里的Swift类没有load函数,就调用initialize函数),方法交换就是在这里面做的。

说完了iOS,再说说Android。Android的原生开发语言是Java,Java没有提供动态运行时的接口来hook方法,但提供了字节码改写的方法。

先来看看经典的Android APP打包流程图。

干货 | 透视宝Smart SDK实现原理与案例解析

Android APP打包流程图

所有资源文件(xml,png之类)、源代码文件等都会经过java编译器编译成 .class的字节码文件。再与其他库文件一起,由Android sdk提供的dex工具,转换成Android平台的.dex文件,再通过apk打包工具打成apk包等等。

这一打包流程图,翻译一下,就是下面这张图。

干货 | 透视宝Smart SDK实现原理与案例解析

我标出了关键部位,没有打马赛克,对,这就是Smart SDK,在.class 文件准备转换成.dex文件之前起的作用。

通过代理,在dex工具的接口中,使用ASM框架,把进入dex里面所有的.class文件读出来,找到我们感兴趣的方法,改写(加些数据收集代码),再让打包流程继续,最终生成的apk包里,就有了我们的收集性能数据的代码。

客户案例分析

目前我们接触次数最多的是百程旅行网,他们使用SDK已经有3个月时间了。下图是他们最新版APP的性能情况,从数据上来看,他们的APP的性能真有待提高。

干货 | 透视宝Smart SDK实现原理与案例解析 崩溃率确实有点高,优秀的APP崩溃率是千分之一到千分之二,所以他们亟需我们的SDK定位崩溃根源。通过抓取的崩溃信息,可以给他们进行初步参考,因为上传到APP Store的APP产生的崩溃日志,需要对应的解码文件才能查看具体崩溃在哪个文件的哪一行代码上。

这里发现他们另外一个问题是网络请求时间太长,在跟他们技术交流之后,初步判断网络请求时间长的有一部分原因,是因为线上数据混入了测试数据造成的结果。

一个杭州的用户在6分钟内发起了5800多次请求,请求错误率高达98%以上。当时他们不相信那是真实的,其实我也不太相信。后来再次跟开发人员交流,问那个网络请求接口是否循环调用了,他回答是:请求接口在请求成功之前会一直循环调用,直到请求成功或是断网。就是因为杭州这个用户在一个时间点访问的api有问题,导致循环请求。

还有一点,我们通过Smart SDK发现好些API报错是找不到主机,客户端的开发说是因为很多接口废弃了,但客户端还在调用,他们内部也明确说明要清理一遍废弃的API。

目前,百程旅行网用Smart SDK已经找出了应用崩溃的根源,以及API慢、不可用的原因,每周会根据我们统计的数据做一次性能优化。

点击“阅读原文”了解更多透视宝

干货 | 透视宝Smart SDK实现原理与案例解析

正文到此结束
Loading...