有赞移动性能监控平台（一）-技术圈

前言

随着移动端业务复杂度的提升，开发同学在编写业务的时候往往容易忽略性能问题，虽然有赞移动端自研了 APM ，但是 APM 采集的都是线上的数据，无法在 QA 与开发阶段提前发现问题，为了保障软件的稳定性，需要补齐线下监控能力，避免性能问题上线对商家经营过程造成影响。

一、架构设计

整体基于 APM 现有框架迭代线下监控能力，并在端上开发 AWACS 可视化工具，通过全局悬浮窗，并结合提醒能力（弹窗与 Toast 提示）实时通知测试人员进行问题查看，同时后台也会定时分析测试环境采集的性能数据，进行管理与分配。

QA 同学基于 Appium 补齐了 UI 主流程 case ，通过自动化测试最大程度确保每次应用发版的稳定。而设备自动化回归流程可以与线下监控完美的结合起来，首先每个版本可以确保运行在同一款设备上，其次每个版本运行的主流程用例基本上保持一致，这样就为应用“前后”版本性能数据分析对比提供了两个参照条件。性能问题上报后，除了微信Robot通知相关干系人解决问题外，还基于移动端 mPaaS 搭建了问题管理与分配平台，便于跟进与追踪。

二、监控指标分析

性能监控目前对阶段、流量、页面耗时、 ANR 、慢方法、 fps 等数据做了实时监控，本篇文章只会对阶段、流量、页面耗时进行归纳分析，后面“有赞移动性能监控平台系列文章“会对 ANR 、慢方法、 fps 等监控数据进行总结。

2.1 阶段数据

移动端每个业务流程都可以统称为“阶段”，比如 App 启动、商品加购、商品查询等，业务方可以对自身需要关心的业务阶段进行监控，结合“数据分析”与“告警能力”快速协助业务方排查问题。阶段分析包括“方法耗时分析”与“网络状况分析”两个部分，下面会具体介绍。

2.1.1 方法耗时分析

在 App 编译期会对每个方法进行前后打点，确保运行过程中每个阶段方法耗时都可以被自动统计出来，节省手动打点统计成本。

原理

开发 Gradle Plugin 插件，在 App 编译 Transform 阶段（ .class 转换为 .dex 过程），对字节码进行操作，在方法的开始执行（ methodEnter ）与结束执行（ methodExit ）通过 ASM 工具分别插入 MethodBeat 的 i 与 o 方法，对每个方法进行首尾打点，运行时自动统计方法耗时。

分析详情

应用所有版本产生的阶段数据都会上传到后端，后端会通过定式任务对阶段数据进行分析，分析角度分为新增、新减、陡增、陡降4个维度，协助开发综合对问题进行排查。启动阶段举例：

2.1.2 网络状况分析

业务方可以定义是否需要监控阶段的网络状况，比如启动阶段，除了要监控启动方法耗时之外，网络状态也需要进行监控（ App 启动时，硬件负载比较高，过多的网络 IO 请求会拖累启动速度）。

原理

有赞零售 App 网络通过 OkHttp 进行请求，通过自定义拦截器对网络进行统一拦截，统计每个阶段网络链接数量与请求耗时， intercept 方法实现如下：

public Response intercept(Chain chain) throws IOException {        Request request = chain.request();        Response response = null;        String url = getRequestUrl(request.url());        if (!TextUtils.isEmpty(url)) {            AppSegmentCache.INSTANCE.setRequestStart(url);            long startNs = System.nanoTime();            try {                response = chain.proceed(request);            } catch (Exception e) {                throw e;            }            long tookMs = TimeUnit.NANOSECONDS.toMillis(System.nanoTime() - startNs);            AppSegmentCache.INSTANCE.setRequestEnd(url, tookMs);        }        return chain.proceed(request);    }

分析详情

分为“全部调用”与"重复调用"两个统计维度，“全部调用”会统计当前版本该阶段网络请求总数，且会与上个版本请求总数进行比较，计算出升降趋势（提升/下降了 x%），且列出“新增”与“新减”两个数据维度，协助对网络状况进行分析。“重复调用”会统计所有重复调用的接口状况，包括网络重复请求的总数，还会全部列出重复调用链接内容，方便业务方进行排查优化。

2.2 流量

App 运行过程中主要涉及到接口、文本、视频、图片等各种流量请求，往往在开发过程中不太会注意流量消耗这个指标，最近也经常有商家反馈 App 流量消耗比较大，但目前并不能准确的定位流量消耗主因。

2.2.1 原理

分别对 HttpUrlConnection 和 OkHttp 做 Hook （ .class -> .dex transform 流程插桩），所有的请求都得经过 Hook 层，这样就能统计每个请求的流量大小与 response 内容，便于业务方进行分析。

OkHttpHook

App 编译期往 OkHttp 中配置 GlobalNetworkInterceptor 拦截器，统计 response length（流量大小）、response content（请求返回内容，如果是 gzip 需要解压），然后将流量内容写入文件中（非线上包才会采集），便于分析。

internal object OkHttpHook {    @JvmField    public val globalNetworkInterceptor = Interceptor { chain ->    ... ...    // 计算repsonse length（流量大小）    // 读取response content（如果是gzip需要解压）    // 流量内容写入文件中    val fileUrl = File(file, URLEncoder.encode(SimpleDateFormat("yyyy-MM-dd-HH:mm:ss-SSS").format(Date()) + "-" + netPackInfo.url))    fileUrl.writeText(netPackInfo.toString())    ... ...}

HttpUrlConnectHook

编译期对 HttpUrlConnection 进行 Hook ，底层网络请求其实是代理到 OkhttpClient 上，这样就能保证 HttpUrlConnection 所有网络请求也能通过 OkHttp 进行处理，这样流量拦截器（ GlobalNetworkInterceptor ）就可以进行复用了。

public object HttpUrlConnectHook {    @JvmStatic    fun proxy(httpUrlConnection: URLConnection): URLConnection {        try {            return hookOkHttpURLConnection(httpUrlConnection)        } catch (e: Exception) {            e.printStackTrace()        }        return urlConnection    }}
@Throws(Exception::class)private fun hookOkHttpURLConnection(httpUrlConnection: URLConnection): URLConnection {    val builder = OkHttpClient.Builder()    val mClient = builder            .retryOnConnectionFailure(true）            ... ...            .build()    val strUrl = httpUrlConnection.url.toString()    val url = URL(strUrl)    val protocol = url.protocol.toLowerCase(Locale.ROOT)    if (protocol.startWith("http", ignoreCase = true)) {        return HttpUrlFactory.OkHttpURLConnection(url, mClient)    } else urlConnection}

2.2.2 分析详情

通过展示网络各个统计指标数据详情，包括每个接口的请求流量大小、请求次数、请求内容，便于技术人员对流量问题进行分析。

2.3 页面耗时

有赞零售面向B端的产品，适配了很多低端收银机，在页面流畅性有严格要求，通过页面耗时监控，统计每个页面（ Activity ｜ Fragment ）的耗时，当页面耗时超过阈值时，会生成问题，分配给相应的处理人进行修复。

2.3.1 原理

监控 Activity 与 Fragment onCreate() 方法开始执行作为页面绘制开始时机，页面 onDraw() 方法第一次回调时机作为页面绘制结束时机，两个时机做减法，算出页面渲染耗时。

页面监控开始时机

在 ActivityLifecycleCallbacks 全局监听 Activity 生命周期，在 onActivityCreated() 方法中调用 watchActivity() 方法，watchActivity 除了统一对 Activity 页面预埋开始时机外，还会区分 Activity 类型，对 Activity 内嵌的 Fragment 注册 FragmentLifecycleCallbacks 监听，同样在 onFragmentViewCreate() 回调中对Fragment页面开始时机进行预埋。

public void watchActivity(Activity activity) {    watchWithMonitorView(activity.getClass().getName(), activity.getWindow().getDecorView());     ... ...    if (activity instanceof android.support.v4.app.FragmentActivity) {            ((FragmentActivity) activity).getSupportFragmentManager().registerFragmentLifecycleCallbacks(new FragmentLifecycleCallbacks() {                    public void onFragmentViewCreated(android.support.v4.app.FragmentManager fm, final android.support.v4.app.Fragment f, View v,                                                      Bundle savedInstanceState) {                        watchWithMonitorView(f.getClass().getName(), v);                    }
                }), true);    }    ... ...}

页面监控结束时机

监控页面根布局 onDraw() 第一次回调，定为页面绘制结束时机。

public void watchWithMonitorView(final String className, final View view) {        final long startTime = System.currentTimeMillis();        final WeakReference viewWeakReference = new WeakReference<>(view);        final ViewTreeObserver.OnDrawListener onDrawListener = new ViewTreeObserver.OnDrawListener() {            Boolean first = true;            @Override            public void onDraw() {                if (startTime != 0 && first && viewWeakReference.get() != null) {                ... ...            }        };        view.getViewTreeObserver().addOnDrawListener(onDrawListener);    }

2.3.2 分析详情

在设备自动化回归过程中一个页面会被多次调用，在线下监控环境中，只有一个页面3次超过耗时阈值（ 200ms ）才会算成有效的页面卡顿问题，防止硬件不稳定造成问题误报。

三、后台问题分析

设备自动化回归过程中产生的性能数据存在一定的波动性，后台需要对批量性能数据进行算法校验，评估出合理的有效问题，减少问题误报。

分析工作流程（阶段数据分析举例）：

设备自动化回归过程采集到阶段数据后，上传到移动网关，晚上7点启动定时任务，在后台拉取当前应用版本各个阶段最近n条数据，进行数据聚合分析，计算出合理的阶段耗时平均值，再同样拉取当前应用上个版本各个阶段的最近n条数据，同样算出阶段耗时平均值，与当前版本阶段耗时平均值进行对比，算出涨跌幅度，如果超出阈值就会当成有效问题，进行分配与告警。