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

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

　　Smart SDK能干嘛?

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

　　详细功能图如下图所示：

　　Smart SDK功能图

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　Smart SDK实现原理

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

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

　　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打包流程图。

　　Android APP打包流程图

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

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

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

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

　　客户案例分析

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

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

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

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

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

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