会展云技术解读 | 面对突发事故,APP 如何做好崩溃分析与性能监控?
云妹导读:
在《会展云技术解读》专题中,已先后推出了安全篇、设计篇与智能推荐篇,分别介绍了最严格 8 大安全保障方案、线上展览中基于服务设计的方法以及展会场景智能推荐搭建之路。本篇文章我们将继续深入解读会展云背后的技术,来看看会展云中最重要的线上平台如何做好性能监控与崩溃分析。
会展云解决方案覆盖了业务,技术,平台,应用四个层面,业务层面提供科技感十足的云上展厅、多种模式的论坛会议等;应用层面有多种解决方案,直播解决方案、视频会议解决方案、移动研发解决方案等;技术层面依托海量弹性云计算能力和充足可扩展的云存储及带宽资源,集成了多种京东中台平台的能力,有技术中台、数据中台、智能中台及业务中台能力,可快速响应前台应用的需求。
作为云上展会,最终呈现给广大参会者的对外窗口必然是网站、APP、H5、小程序等线上系统。在京东会展云中, 一站式 APP 解决方案 EMOP 平台也是其中重要一环,可为会展云举办方提供多种移动终端,包括 APP、H5、小程序等,提供全业务流程的规划、设计、研发、运营、运维等一条龙服务。
不久前成功举办的中国国际服务贸易交易会(简称服贸会)首次采取新模式——线上线下展会融合,就借助 EMOP 平台在运维层面的能力,为服贸会 APP 的稳定运行保驾护航。
服贸会参与展会的企业多达 17000 余家,而服贸会 APP 作为云上展会对外运维的重要窗口,为来自全球不同规模、不同行业的参展商、采购商提供展览展示、论坛会议、洽谈签约的数字平台。
在展会举办期间,服贸会 APP 如何扛住客流量的压力?如何保障线上 APP 的质量?如何高效地修复线上崩溃问题?如何提升客户留存和活跃?
在寻找问题答案前,不妨先来看一个京东的案例,2020 年京东 6.18 成交量超 2692 亿,创历史新高。618 大促期间,京东 APP 有成千上万的用户去浏览商品、抢购、下单等,不仅要扛住亿级流量的压力,还要提供良好的用户体验,毫无疑问,这离不开其背后支撑的技术。
在遭遇到大型会展较大客流量冲击,面对突发事故,研发人员是怎样快速定位问题和及时修复,那必须得谈谈背后的崩溃分析系统和移动性能监控系统。
崩溃系统定位于为移动 APP 提供崩溃监控及崩溃模块定位的服务平台,通过对 APP 崩溃数据的监控和分析,从而协助 APP 降低崩溃频率,提升用户满意度,具有支持 Android、iOS 极简接入、实时监控、信息全面、安全稳定、统计详细等特点。
崩溃分析系统为 APP 的稳定运行起着保驾护航的作用,目前已经通过京东万商、京东到家、七鲜等众多 APP 的验证,此次服贸会 APP 接入崩溃系统,一是随时监测 APP,保障展览展示、论坛会议、洽谈签约等功能的稳定运行;二是在短时间内定位崩溃模块所在,及时修复问题。
崩溃捕获:支持原生崩溃、OOM 崩溃、自定义错误或异常上报;
崩溃分析:基于崩溃模块维度的聚类分析,通过聚类数据分析快速发现问题主要特征;
跨端异常:支持跨端异常模块查询,跨端异常数据解析(RN、Flutter),快速定位跨端问题;
高级功能:针对各种异常信息进行详尽的搜索查询,支持原始数据导出,支持不同查询条件的对比查询。
移动性能监控系统旨在建立统一的应用性能接入框架,通过各种性能监控方案,对客户端数据进行采集,展示异常数据,辅助定位异常问题并输出性能报告,从而协助开发者快速发现产品性能问题,优化 APP 性能。
性能分析像是为 APP 把脉的老中医,各种疑难杂症都可快速揪出来。
在大会举办期间服贸会 APP 上线运行后,通过性能分析实时感知应用启动性能、页面加载性能、网络请求等状态,定位异常问题所在,保障参展商,采购商,媒体记者等良好的使用体验。
通过以下几个功能:启动监控、卡顿监控、网络监控、webview 监控,原生页面监控以及日志上报、安装包分析工具、内存分析工具可实现性能监控。
(一)启动监控
监控线上用户启动应用的耗时以及定位到时间消耗在了哪些阶段。
启动监控采用了无侵入式打点方式分为了三个阶段,记录了应用启动各个阶段的耗时情况:
√第一阶段 : 记录了 Application 的初始化阶段耗时;
√第二阶段 : 记录了 Application 初始化完成后到用户首页开始创建的耗时;
√第三阶段 : 记录了首页开始创建到完全展示过程的耗时;
√ 启动耗时 = 第一阶段耗时 + 第二阶段耗时 + 第三阶段耗时。
另外,对启动时期应用的主要生命周期的方法也做了方法执行时间上报,辅助用户通过直观的数据进行启动过程的拆解。
(二)卡顿监控
卡顿引发的原因有很多种,其中,主线程的卡顿带来的影响最为严重,可能会导致用户无法正常使用移动 APP 上的任何业务。
卡顿监控原理介绍:
① APP UI 线程消息机制
APP UI 线程是 Looper 线程,线程中维护一个消息队列,Looper 在循环消费消息队列中的任务,如果消息队列中存在耗时的操作,将会影响 UI 任务的绘制,导致界面出现卡顿。
② 采集 UI 线程消息的运行时长
移动端(Android/iOS)都是采用了 AOP 的思想,对整个 UI 线程的消息处理过程进行了监控,采集到了每个消息的执行时间。
③ 卡顿条件(消息执行时间 > 卡顿阈值)
在采集到每个消息的执行时间后,自动进行卡顿阈值比较,超过阈值的消息被认为该消息执行时间过长,会引发主线程卡顿。
④ 采样
在执行主线程的同时,采样线程对主线程的堆栈、cpu 等信息进行周期采样。但是采样线程要先休眠一段时间,这样做的最主要原因就是为了不对主线程大部分的短消息进行打扰,抢夺 cpu 资源,造成性能降低。
(三) 网络监控
网络监控的数据包含了两大类:原生网络监控和图片监控。
原生网络监控主要监控了接口的性能及异常数据;图片监控是在网络监控的基础上新增了 CDN 节点数据上报。
网络监控技术方案介绍:
① 采用 ASM 字节码编辑技术 Hook 到了 App 底层的基础网络组件的网络行为;
② 采集 UI 线程消息的运行时长
移动端(Android/iOS)都是采用了 AOP 的思想,对整个 UI 线程的消息处理过程进行了监控,采集到了每个消息的执行时间。
③ 整个网络监控包含了性能数据及异常数据这两类,既满足基本的异常告警监控,也具备分析聚合线上性能数据的功能;
(四)原生页面性能监控
原生页面监控采用较为轻量级的数据采集策略,主要通过运行期间,采集设备的帧率,CPU, 内存,线程数,流量这几种数据,来反应当前页面运行时性能情况。
技术方案介绍:
① 帧率采集
帧率采集方案是通过系统的回调监听页面的刷新事件,监听到页面开始刷新时便计算页面每帧绘制耗时,通过帧数/总耗时来计算出真实的帧率。
② CPU、内存、线程数据采集
CPU,内存使用情况及线程数量能够反映出原生页面的资源消耗情况,性能监控系统采用了等时间间隔采样的方式来实现样本采集。
CPU 监控能够反馈当前页面的 CPU 使用情况,可以侧面反馈出电量消耗问题;
内存使用能够标明当前页面消耗内存情况及 JVM 中可用内存大小,从而计算出内存触顶率及页面内存抖动情况;
线程数可以监控到原生页面中是否线程数超标,监控线程数超标 OOM 问题。
(五)webview 监控技术方案介绍
京东性能监控系统支持 Webview 与腾讯 X5 内核性能监控,监控的核心指标为 window.perfromance.timing 参数,该参数记录了整个 webview 加载过程中的阶段性耗时,详见下图:
通过浏览器内核返回的数据,可以计算出页面加载总时间、网络请求耗时、DOM 加载时间、白屏时间即用户等待时间等性能指标。
以上两个系统在监控层面赋能服贸会 APP 的原理和实现,都来源于京东 EMOP 平台,该平台是企业级移动研发平台,结合“京东系”APP 研发的经验积累与最佳实践,为移动开发提供一站式解决方案,可以帮助企业构建强大的移动中台,快速创建高质量的 APP、各类小程序等移动终端产品,支持企业新业务开展,助力企业移动化转型顺利实施。
EMOP 支持私有云和公有云部署,有四大稳定的开发框架,7 种移动开发技术与组件能力,源于“手机京东”APP 研发的最佳实践,在实现多业务闭环的前提下,解决成本、质量、效率、标准问题,助力多团队 APP 研发的质量提升、成本节约,详情请见:https://emop.jd.com/home/。
推荐阅读:
欢迎点击【京东智联云】,了解开发者社区
更多精彩技术实践与独家干货解析
欢迎关注【京东智联云开发者】公众号
版权声明: 本文为 InfoQ 作者【京东科技开发者】的原创文章。
原文链接:【http://xie.infoq.cn/article/6e273735c0acba4b7b8d8a2d1】。文章转载请联系作者。
评论