啃书文库 > 生活 >
信息互联年代,在面向终端用户的移动App上,大家常常会收到用户反馈的各种问题,譬如启动崩溃,登录失败等等。每次遇见这类问题,最后会流转到开发手里,并且需要尽快给出回话。平时中,开发职员一般都需要结合日志才能定位问题,但现实的难题是,这种时候总是没日志提供,可能仅有一张问题截图。而当大家缺少如此的功能时,排查问题几乎不可能。因此,开发并上线如此的功能,就看上去尤为迫切,它可以很大地提高处置客诉问题的效率,进而提高顾客认可度。本文将从以下三个方面对App在线诊断模式进行全方位的介绍。
1、介绍
App在线诊断模式,顾名思义,它是App上辅助问题诊断的,这么说,可能还是不好理解。我举一个日常很形象且等价的例子,大伙都了解飞机的黑匣子,即实时记录飞机飞行时的一些重要信息,各种参数等。同理,延伸到App层面,也是类似的。大家会在App运行时,记录它的各种重要信息,譬如前后台切换信息、设施信息、互联网信息、接口调用信息、用户操作行为等等。这类记录默认是开启的,且实时记录在当地文件中,当然可以通过后端开关来控制此行为,而上传只在用户报问题,需要进一步剖析时,才会由后端下发上传指令。目的是能做到,当用户反馈问题时,当地大概率已经记录了问题发生时的日志,这个时候只须给此设施打开上传开关,拿到当地记录好的日志,便可进行下一步的剖析了。
2、系统构成
一个完整的诊断模式系统,一般应包括三个大的模块,下文将根据终端、后端、前端的顺序,依次介绍每个模块。
2.1 终端模块
终端部分是诊断模式的核心所在,包括了最重要的功能达成,其构造如下图所示:
图1 终端模块示意图
①启动检查:诊断模式可以包括两个开关,diagMode(实时log开关)和upload开关,前者默认打开,后面默认关闭。diagMode也表示大的功能开关,启动时第一检查功能是不是打开(通过读取当地存储的值,而非调用接口,主如果为了启动步骤的连贯性),打开的话,则进入诊断模式逻辑,即启动日志线程(整个诊断模式运行在单独的diagnose线程里,如此做是为了降低对UI线程的干扰,以免影响到客户体验);不然做一些日志文件清理后退出诊断模式。单线程方法是一种典型的做法,当然不排除其他的达成方法。
②配置接口请求:App启动后,紧接着会请求配置接口信息,拿到诊断模式的两个开关值,App会将最新的diagMode写入到当地存储中(下次启动时,会直接读取)。若是功能打开且需要上传,则立即实行上传操作,若是功能关闭,则清理并退出诊断模式即可。当触发上传操作后,整个日志功能暂时是关闭的,由于上传时需要读取日志文件内容,而记录日志时,又需要写入文件,这里为了防止读写冲突,选择的策略就是等上传结束后,再依据诊断的开关,重启诊断模式,简单而有效。
③业务打点:这一部分是跟业务紧密有关的,具体日志内容,完全由上层业务决定,也是后期诊断问题时判断的要紧依据。譬如你可以写入重要接口请求的入参和出参,设施的信息、互联网连接状况的信息,与用户操作行为等等。这类日志请求,可以在任意线程里触发,而诊断模式内部会据此架构一条日志,日志格式和系统adb logcat -v threadtime的输出维持一致,包括进程id、线程id、时间戳等信息,便捷后期定位问题。通过这类信息,可以轻松地分辨出日志来自什么线程,而可能不是主线程。具体要添加什么日志,需要结合业务场景来判断,也可以参考开发职员的经验决定。一般系统哪儿容易出问题,什么步骤比较重要,这类都是比较理想的添加日志的地方。当然,这里的日志也是可将来期慢慢健全的,刚开始的话,可以仅添加比较重要、要紧的日志即可。
④日志写入文件:诊断模式内部是通过一个独立的HandlerThread来达成的,而且尽量将所有有关操作都限定在本线程内部,如此做一方面是简单靠谱,其次更要紧的也是为了多线程安全。当业务层请求记录一条日志时,诊断模式内部会第一进行一些封装,生成一个Message对象,然后通过Handler将此消息发送到HandlerThread对应的消息队列中。可以看出这个达成是一个异步操作,好处就是业务层请求日志的速度不会受内部处置的影响,即上层可以1s内请求记录n条日志,而不需要担忧速度过快,致使日志丢失。HandlerThread内部从其消息队列中取出消息,逐一处置。而当遇见写入消息时,则打开日志文件(没有的话,则先创建),写入一行日志内容,接着处置下一条消息,这样循环往复。
⑤上传并清理:当HandlerThread内部遇见的是条上传消息时,则关闭日志文件,实行真的的上传逻辑。等上传成功后,则将当地的日志文件删除,最后再依据diagMode的取值,决定是不是重启诊断模式(上传的过程中,会短暂关闭,防止操作同一个文件产生冲突)。这里顺便提一下,日志文件可以不止一个,而是会依据一些方案生成不一样的文件,且为了安全起见,单个日志文件的大小,也都有上限限制(防止极端状况下,占用端上过多存储)。
2.2 后端模块
后端部分主要涉及到配置和上传两个接口的功能达成。其构造如下图所示:
图2 后端模块示意图
①配置接口:依据全局配置、单台设施配置,综合计算得到此设施最后的配置信息,包含diagMode开关和upload开关。前者表示端上是不是记录日志,后者表示是不是上传当地日志。
②上传接口:承载具体的上传逻辑,校验端上的日志内容,文件大小等,接收并调用日志存储模块。
③日志存储:负责将上传的日志永久保留在服务器上,以便后续排查问题时用。譬如通过前端页面来展示日志内容,或者提供下载功能。
2.3 前端模块
前端主如果搭配管理平台用。当遇见线上问题时,客服职员会在此页面进行配置,并且打开问题设施的上传开关,稍后就会有日志上传,接着开发职员就能介入进行下一步剖析了。其整体构造如下图所示:
图3 前端模块示意图
①添加设施:客服职员会依据用户的客诉反馈,拿到一些设施信息,譬如sn或者mac。在此页面,输入这类信息,添加排障设施。
②设施列表:这里展示了所有之前排障过的设施,可以参考sn、mac进一步过滤展示,便捷定位到单台设施。
③设施详细情况:当确定了具体的问题设施后,就能进入到详情介绍页面。在这里可以看到更多详细的信息,譬如设施型号、系统版本、App版本等,当然非常重要的还有日志上传按钮。点击按钮,等端上响应上传指令后,日志就能在页面下方看到了,且依据记录日志的时间倒序排列。这个时候,就能依据问题发生的时间找到有关日志,转交开发职员继续排查了。
3、将来展望
App在线诊断模式,上线后很大地提高了大家解决各种客诉问题的效率,但确实也存在一些技术上的点待优化。第一就是日志上传的时效性问题,以前面的介绍可以看出,上传还是依靠用户第三启动App,假设用户不配合,对时效的影响还是很大的,这个可以考虑使用退后台外加定时的方案来进行弥补。另一个问题是功能上不是特别通用,跟业务还有的耦合,将来是期望能进一步解耦、封装,通过统一SDK的形式来输出这个能力,可以让三方App迅速完成端上的对接。
单位:中国移动智慧家庭运营中心
- 上一篇:铁线莲冬季怎么样保养维护
- 下一篇:没有了
猜你喜欢
- 2024-03-28 2024赣州科技馆门票预约指南 2021年赣州科技馆开馆了吗
- 2024-03-27 2024大连科技革新平台补贴如何申请 大连科技奖励方法
- 2024-03-26 南阳科技职业学院2024年单招考试考试报名指南
- 2024-03-24 2024赣南师范大学科技学院专升本招生简章
- 2024-03-21 2024年绍兴城投应对科技公司招聘简章 绍兴城投集团公司招聘
- 2024-03-08 阅读的力量 | 向科技革新要答案:让产学研拧成一股绳
- 2024-03-07 今年两会,总书记再谈“新质生产力”
- 2024-03-01 2024桂林电子科技大学研究生考试成绩复核方法
- 热点排行
- 热门推荐
- 热门tag