信息互联年代，在面向终端用户的移动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迅速完成端上的对接。

单位：中国移动智慧家庭运营中心

Tags：科技