移动端WAPM性能监控原理浅析

背景

58内部在兼容性测试、稳定性测试、H5、资源检查和安全测试等测试方向已经覆盖，对于移动端性能测试却较少涉及。性能数据大多数依赖于测试人员手工测试收集，性能数据分散，有效性能数据难以提取，研发难以定位问题所在，而且依赖测试人员手工收集性能数据，效率低下，覆盖率低，人力成本比较高。通过注入SDK的方式，可以获取更多更全的性能数据，一次接入，无感收集，APP在手工测试、自动化测试、回归测试中产生的性能数据都可以持久化存储到web后端数据库，于是WAPM性能监控平台诞生了。

业务结构

WAPM性能监控业务结构大致可以分为四个部分，用户层、接入层、应用层和数据层，如图1。用户层负责产生交互数据，接入层负责收集性能数据并简单处理发送给后端，应用层负责数据接收、数据清洗、数据聚类、性能评测和bug自动提交，数据层负责数据持久化存储。数据获取是WAPM监控平台的基石，本文主要介绍接入层实现原理。

图1. WAPM性能监控业务结构

WAPM SDK 性能专项原理

WAPM检测内存泄漏是通过集成LeakCanary的方式，其原理是通过application.registerActivityLifecycleCallbacks来绑定Activity生命周期的监听，从而监控所有Activity; 在Activity执行onDestroy时，开始检测当前页面是否存在内存泄漏，并分析结果。那判断被检测对象的确存在内存泄漏的依据又是什么？KeyedWeakReference与ReferenceQueue联合使用，在弱引用关联的对象被回收后，会将引用添加到ReferenceQueue；清空后，可以根据是否继续含有该引用来判定是否被回收；判定回收， 手动GC, 再次判定回收，采用双重判定来确保当前引用是否被回收的状态正确性；如果两次都未回收，则确定为泄漏对象。内存泄漏检测上报流程图如下：

图2、内存泄漏上报流程图

Android中界面刷新都在主线程中进行，主线程阻塞则会丢帧，丢帧过多则会出现卡顿现象。UI的更新都是通过消息机制来处理的，在主线程中，系统为我们初始化了Looper 。查看Looper.java源码，可以知道系统api提供了Printer对象，当Printer不为空时，可以在dispatchMessage执行前后回调，如此便可以获得下图中的T1和T2，其差值的绝对值越大，丢帧就越多，丢帧30以上人眼就会被人眼识别。当耗时时间超过阀值时，可以获取栈信息，定位到具体耗时代码块。

图3. UI卡顿检测流程图

WAPM网络监控是通过Hook的网络框架的方式获取网络请求数据。APP接入sdk后，当APP进行网络请求时，就会触发hook回调函数，将Request信息和Response信息存在本地数据库，定时上传。对于获取到的网络请求信息，我们对其分析处理，归类出网络大图片和错误url，提醒开发者优化或者修复。

图4. 网络框架hook流程图

页面加载太慢往往给人不好的体验，在Android中，Android 4.0以上的版本可以利用ActivityLifecycleCallbacks来实现对生命周期的监听，但是没有Fragment生命周期监听，View绘制和Layout加载也没有测速api，于是我们采用hook的方式来监控Activity、Fragment的生命周期以及ViewGroup的dispatchDraw方法，通过维护一个页面pageList，然后通过对象hashCode和生命周期函数的执行时间来归类数据。如将页面对象数据存成一个pageList,当一次绘制完成后，我们先检查此绘制是否为前一个页面的绘制信息，是则将此绘制数据add到之前页面对象中，否则该绘制信息是新页面的绘制信息，如图5。

图5. 页面耗时数据组合分析流程图

总结

本文主要介绍了WAPM业务架构、WAPM性能专项原理和WAPM在业务线的实践，WAPM实现了Android移动端部分性能数据监控，能够自动化发现性能问题，提交性能bug，问题严重程度分级，让研发专注解决较为严重的性能问题，帮助研发复现和定位问题瓶颈所在。目前WAPM已有9款APP接入使用, 已经取得不错成效。在实际使用中，我们发现WAPM在有些方面有些不足，比如场景化性能数据，需要后续不断探索和优化，欢迎感兴趣的同学和我们一块交流。