评论

有赞移动性能监控平台(一)

本文主要介绍有赞移动性能监控平台搭建原理与后续规划。

作者:洪恩涛

部门:零售移动


前言

随着移动端业务复杂度的提升,开发同学在编写业务的时候往往容易忽略性能问题,虽然有赞移动端自研了 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条数据,同样算出阶段耗时平均值,与当前版本阶段耗时平均值进行对比,算出涨跌幅度,如果超出阈值就会当成有效问题,进行分配与告警。

四、线下AWACS工具

在 QA 与开发过程中, App 上会悬浮告警 ICON ,开发者可以点击告警 ICON 打开性能监控中心进行数据查看。性能监控中心会展示阶段、 ANR 、慢方法、流量、 FPS 等性能数据,便于开发对问题进行排查。

五、问题管理与分配平台

后台对问题进行分析后,如果是有效问题会落到后台 db 中,前台在 mPaaS 搭建一套问题查看与分配 UI 看板,方便业务方对问题进行处理与状态跟进。

5.1 问题列表

APM 监控的所有性能指标都可以在性能面板中进行切换筛选, tab 选中后再结合应用、状态、环境筛选器列出问题列表。

5.2 问题详情

点击问题列表后跳转到问题详情,问题详情中包含问题发生次数、进度、详细信息、设备基本信息等,协助开发定位问题。

点击问题详情右上角“变更状态”按钮,可以变更问题状态,并可选择负责人对问题进行分配与跟进。

六、未来规划

1:监控更多维度的数据,包括 cpu 、线程、子线程更新 UI 等。

2:增加更多的自动化测试用例,针对特定的性能场景进行独立测试(现在测试用例基本上都是主流程,覆盖度还不太够)。

3:补齐自动化设备的数量与型号,通过多机型综合分析性能问题。

4:推广到公司内部使用,协助解决有赞其他应用端性能问题。



最后一次编辑于  02-26  
点赞 1
收藏
评论
登录 后发表内容