移动APP监控方案

移动APP监控方案

监控总览

移动APP有着自己独特的运行环境和使用场景，相比后端服务，移动APP质量同样需要做到可视、可控。移动APP是近几年刚刚出现的新产品形态，如何保障移动APP质量是一个新的挑战和话题。本章，重点介绍APP端问题如何发现、如何定位、如何止损，以及如何建立起一套有效的监控体系，为APP稳定应用保驾护航。

6.1端问题概述

APP产品需要经过全面而且严谨的测试，才能发布到应用商店。但，APP发布后产品质量如何，以往更多地依赖于用户反馈信息，因为测试人员无法做到覆盖到全部的手机机型和ROM。这种情况下，如何知道一款APP产品在用户手中的实际质量呢？此时，需要一套完善的质量监控方案，建立一套牢固的监控体系。这样，对APP线上质量问题才能第一时间召回，并做到快速修复。

6.1.1常见问题

1.适配问题

APP测试过程中，测试能够基本覆盖比较主流厂商的机型和ROM，以及市面用户量比较大的android/ios版本。也就是说，的确无法覆盖到市面上所有的机型和ROM，尤其是android系统的手机。所以，用户安装一款APP后经常反馈在自己的手机上页面很丑，甚至有的文字重叠，控件位置显示不正确等问题。

举一个实际例子，某APP上线后收到用户反馈，有些页面滑动比较卡，容易造成误点击，用户使用的机型是一款比较主流的手机。之后，测试工程师马上找到同款手机进行复现，可是未能复现用户反馈的问题。后来得知复现的手机和用户的手机虽然相同，厂商自己定制的ROM版本却是不同的，通过研究ROM代码发现厂商在新版ROM 中增加了新的处理逻辑，直接导致APP出现卡顿。开发人员对此做了适配解决了卡顿问题。

2.用户体验问题

通常，产品经理设计产品功能时，考虑得也不一定很全面，往往抱着试错的心态来设计产品，并希望通过用户反馈来得知产品的好坏，并决定下一步的需求。举一个实际例子，某搜索类产品，产品经理为让用户在夜间浏览时有更好的视觉体验，增加了夜间浏览模式的功能。为了用户方便地设置夜间模式，该产品在晚上20点以后自动弹出一个浮层，询问用户是否设置夜间模式，并且可一键设定。但是，产品经理忽略了一个重要的问题，晚上用户启用夜间模式后，第二天早上如何便捷地切换回白天模式呢？而产品并没有在早上也设置一个浮层做一键切换。导致了很多用户在白天也使用着夜间模式，用户体验糟糕。实际情况是，切换回白天模式的功能虽入口太隐蔽了，用户很难找到。

3.流量问题

目前，手机的上网资费相对欧美是比较高的，加上免费的公共wifi覆盖不高，用户对非wifi下的移动流量消费很在意。那么，一款移动APP产品如何利用最少的流量下提供更多的功能？通过APP缓存是一个常见的技术。举一个实际例子，以小说阅读为例，小说目录一般是罗列很多书籍供用户来选择，这些书籍一般都有书籍名，数据封面图及书籍简介组成。一个页面的数据有150kb，而且这个页面是小说书单的主入口，所有关于小说的操作都要由这个页面开始。如果用户反复请求这个页面，不仅造成流量的浪费也会给服务端带来很大的请求压力。为此，将这个页面的数据缓存到APP本地，如果用户

在非wifi的网络下就不发送请求，如果在wifi网络环境下每间隔一定时间去服务端请求一次数据，然后将老数据删除，并将新的数据写到本地，以便用户能够获取到最新内容。这样，不仅解决了流量问题，也解决了一些低配手机本地内存经常不足的问题。产品设计时从用户角度出发考虑问题，用户不一定能直观地感知到，但实实在在提升了用户体验，减少不必要流量消费，你说何乐而不为呢。

6.1.2 问题特征

上节介绍了三类常见问题，是比较容易复现和解决的，也有一些问题相对是有难度的。例如：

问题1：用户反馈在WIFI网络下无法发起搜素，搜索结果异常。在WIFI环境下复现，无法复现用户反馈的问题，这时往往会归结为网络不稳定造成的。但用户可能当时确实是遇到了问题，这种无法稳定复现的问题，往往归结为偶发性的问题。

问题2：用户反馈离线下载的小说为什么有时候还需要网络。由于用户离线的小说是一部连载的小说，当用户阅读完离线的内容后，假设这时候小说有更新了，产品经理满足用户连续阅读的需求，将产品设计成联网发送在线请求，然后可以继续阅读。这种问题需要从产品策略上持续优化来得到解决。

APP运行在用户手机端，同时联网到后端的服务，许多质量问题是比较复杂的，因此，需要通过不同手段来实现问题的发现、定位和修复。

6.1.3 面临挑战

对于上述介绍，大家可能要问这些问题该如何发现，哪些问题需要马上修复，哪些问题又算长尾问题？下面，将介绍线上问题的召回方式和问题影响面的评估。

1.监控的挑战

APP产品，一旦发布出去就很难有效地控制产品质量。为此，产品经理和数据分析师往往在产品发布前，就要提出监控及统计需求，研发工程师开发设计用于监控统计目的的代码，将用户的行为、产品的crash等核心质量信息以日志的方式上传到服务端，这些用户所产生的数据就为后续分析产品及质量问题提供了原始的数据依据。

2.影响面的判断

利用APP上传的用户日志及APP崩溃信息，进行统计分析。结合线上问题，可进行影响面的评估。影响面评估主要有三类，包括严重问题，特定场景复现问题，不影响主要功能问题。

1)严重问题一般是要发小版本来修复的问题

2)特定场景复现问题一般不会发小版本修复，但一定会在下

一个版本进行修复

3)不影响主要功能的问题，将视下一个版本排期进行修复或

延期修改

6.2 端质量监控方案

由于APP载体多种多样，产品质量问题表现形式有很多种。我们以最通用的APP为例，总结为以下几种：

1.来自APP产品所依赖的后端服务的问题

2.来自APP产品自身的问题，包括稳定性问题，表现为：

a)应用crash（崩溃）

b)ANR（APPlication Not Responding）

c)网络错误

d)请求响应时间长

e)用户交互不流畅

f)机型、ROM适配度不够引起的兼容性问题

3.来自APP和后端服务之间的链路问题，通常有：网络问题造

成的丢包、TCP重传等等

对于APP质量监控，可以从三个方向去布局一套完善的监控体系：问题发现、问题定位、问题止损。

6.2.1问题发现

由于APP受用户机型、手机ROM、网络环境、用户操作路径差异的影响较大，QA无法保证在测试阶段暴露所有问题，这就要求我们建立一套线上问题发现体系，及时召回已经交付到线上的移动产品。一套完善的线上问题发现体系，通常来说需要根据产品的核心业

务，抽象出核心指标，实现指标量化；制定质量标准，提供实时监控报警。

根据我们的经验，APP应用的质量指标包括但不局限于：安装成功率，崩溃率，ANR比例，网络错误比例，请求响应时间等。质量指标与具体的应用功能紧密相关。理论上抽取指标后，如何量化是最关键也是最困难的一步。量化需要有效的问题信息获取途径，日志埋点是一种非常通用的方法，而另外一种途径，用户反馈，虽然常常被开发者忽略，却同样重要。

6.2.1.1 用户反馈：海纳百川

一款应用想要在应用市场份额中分得一杯羹，长久地留住用户，需要依赖良好的应用功能和产品体验。用户反馈代表着市场对这款应用的满意度，能够直接反映用户的判断和诉求，也是这款应用迭代改进的第一手资料，前期我们可以通过市场调研等方式获取反馈，但是受限于人力和时间成本，我们很难在用户量巨大的时候复用此法，或者说市场调研始终只能采样而无法全量覆盖。

基于上述，只有提供一个入口，让所有用户的反馈可以如江河入海，汇于一处，我们才能获取到来自不同地域、不同网络、不同机型、不同场景下的用户反馈，进而聚类、分析、改进我们的产品。

用户反馈的通用方法并无太多新奇之处，市面上很多移动应用都会在应用设置页面中附上一个用户反馈的入口，如图2.1中百度云和爱奇艺视频的用户反馈界面

图2.1

我们必须要明白一点，如今快节奏的生活中，用户愿意提交一个反馈，那这个问题对他/她来说一定是一个很大的困扰，而且他/她又是一个比较忠实的用户，同时对这款应用抱有期待，希望开发者可以改进。所以一旦这个产品开始提供更稳定或者功能更多的收费服务来尝试变现，那么这部分用户会是最大的潜在群体。

一个普通的用户反馈页，却是于细微处见真章的最好实例，这两个页面的设计告诉我们用户反馈的重要原则：

反馈入口路径尽可能短：上述的两个反馈入口都在应用的设备界面，进入反馈页面需要2步操作。这一复杂度刚刚好，如果

一个反馈需要用户操作4、5步才能找到，那么用户的热情会

被这种来自技术的傲慢消磨殆尽。

●反馈内容的提交成本尽可能低：左侧图片中爱奇艺的用户反

馈，不仅事先列出了用户最可能遇到的几种问题，还在页面下

方给出了常见问题的FAQ。不要小看了这一细节，我们可以

通过这样的方式，在无形之中完成一次用户问题反馈+调查问

卷。

●对用户的答复应该尽可能的快：如果想要给用户反馈的过程提

供更实时的体验，那就要求我们在用户反馈页面完成一个IM

的功能，这对大多数处于创业阶段的开发者来说并不现实，所

以我们建议采用集成插件的方式来达到这一目的。下面推荐几

款常用的用户反馈平台：

1)美洽，基于HTML5开发，只需在IOS/Android支持

H5的浏览器中打开即可，无需安装任何软件程序，代

码植入，一步到位，简化沟通流程。

2)Udesk：支持Android、IOS以及APIcloud三大平台，

可以对用户反馈的数据做统计分析，并展示结果。

3)Freshdesk，致力于中小企业网站在线客服技术支持的

网站，提供中小企业网站的在线服务质量和用户体验

度。

除了在应用中直接反馈，也可以创建用户群（QQ，微信或其他企业级IM），针对严重问题可以第一时间发现，直接与用户沟通，辅助复现、抓取问题现场信息等，这些对问题的定位和解决是至关重要的。

6.2.1.2日志埋点：秣马厉兵

在一个移动应用设计之初，开发者通常考虑的是功能、架构、开发周期等问题，这一类问题通常直接影响应用的发布周期，但是大家往往会忽略一个重要的过程，那就是日志埋点。

为何要埋点

通过用户反馈发现问题毕竟有一定的延时，甚至有一些线上问题会阻塞用户反馈，例如：连续频繁的崩溃，用户反馈模块自身的Bug 等。要想更迅速及时的暴露问题，需要我们主动出击，获取用户操作的关键信息。

埋点于何处

日志埋点的原则：好的埋点可以达到一夫当关万夫莫开的效果，将所有我们需要的信息通过日志的形式打印出来，选择性或者全量的上传给应用的后端服务，用于支持问题发现或服务改进。

受限于APP应用的运行环境，我们不可能在所有的地方进行埋点，笔者在多年的软件开发维护过程中，也见过由于日志添加不当引起程序崩溃问题.

根据自身经验，我们总结出下列日志埋点的建议：

1.由目标驱动埋点：一个移动应用，开发者或者用户希望了解的

服务指标，必须由日志埋点解决；

2.日志框架通用：应用的第一个版本在日志框架上面花的时间，

直接影响后续版本的开发效率。通用和稳定是这个框架必须要

考虑的问题。

3.日志上传：对于已经获取的埋点日志，我们必须考虑它对用户

流量及交互流畅度方面的影响——毕竟它的上传使用的是用

户网络，尤其是在收费的移动网络下更要慎重。有如下手段可

参考：日志压缩和私有协议、用抽样上传代替全量监控；如果

日志对时效性的要求不高，可以考虑采用打包整体上传代替实

时上传的方式，甚至可以每天上传一次。这些都需要在框架中

提前做好部署工作。

4.日志安全：用户日志中可能包含用户个人信息、用户行为及隐

私，一旦信息泄露，可能给用户造成经济、安全等方面的损失，

严重影响用户对应用的信任。故日志安全是重中之重，目前行

之有效的方法主要有加密和使用安全协议。相对于加密算法较

容易被破解的风险，安全协议提供了更严密的保护。目前应用

比较广泛的安全协议主要有https，spdy等。

6.2.2问题定位

线上问题的快速定位和解决可以直接缩短用户体验受损的时间，通常有以下几种定位思路：

1.日志分析法

当遇到一个问题时，我们最先想到的可能就是查看日志，用户日志是定位问题的最直接的信息来源和方法。日志分析又可以分为两种手段：一是从统计学的角度分析大量的问题日志，总结聚类，通过其中共性的特征，发现潜在的问题；另一种是针对某个有明确问题反馈的用户，查询其一段时间内的所有操作流程及结果，通过上下文推测问题原因，也可以辅助线下复现。

当然并不是所有的问题都可以通过用户日志定位，比如日志不全或日志提供的信息并不足以精确定位问题，怎么办呢？那就要求我们能够复现这一问题。

2.问题复现法

通过用户对问题的现象描述，以及已有的用户日志，尝试线下复现。复现时需要关注用户的机型，平台，网络类型，是否设置了代理，甚至是用户所处的地理位置（不同地域的运营商网络可能有较大差异）等，结合应用所提供服务的逻辑，推测可能出现该问题的原因，尽量增加复现的可能性。

3.推测验证法

当然，APP的问题很大程度上依赖于当时的问题环境，包括机型，平台，网络情况，手机安装的应用等，都给线下复现带来了巨大的困难。而现有的问题日志又不足以精准定位。在这种情况下，可以通过问题的现象描述和以有的日志，推测可能的问题原因，埋点监控，通过分级发布的模式，当问题再次发生时，验证哪个推测是root cause。

4.上下游合作分析

有些功能需要多方合作实现，当这些模块出现问题时，大家通力合作，可能就会离问题的解决更近一步。

7.2.3 问题止损

线上问题时时刻刻影响着用户体验，及时止损很有必要。问题止损不仅仅是指定位到了问题的root cause从而实现彻底解决，也包括在问题彻底解决之前，如何将对用户的不良影响降到最低。

对于APP产品，不能像后端服务那样通过紧急下线/上线补丁解决问题，只能依赖于应用发版，而用户的升级转化也是一个比较漫长的过程。在这种困境中，云端控制和热修复为我们带来了曙光。下面主要阐述云端开关控制的思路。

针对APP上影响/风险比较大的功能模块，预先设置好开关，发生问题时，可以通过云端下发关闭指令，及时止损。云端控制是一个概念，实现方式因业务和功能而异。受限于自身经验，我们无法提供通用的多平台解决方案，但是大道至简，我们希望提醒开发者的是：从代码设计开始，考虑应用、系统、服务三个维度的容灾性。

一个简单的例子：我们可以把功能开关置于一个独立的Web Server中，APP采用轮询或者更加精准的动态策略去访问这个静态文件，当服务某个环节出现问题时，只需要修改WebServer中的开关文件，关闭相关功能或者将相应的服务导向备用地址，即可快速的止损。

另外一种方式和上述方案类似，只不过实现的时候不使用访问云端文件，而是由服务端直接向所有APP应用下发指令，用于启停某些功能甚至调整某些内部模块的逻辑。这种方式更直接，但是对APP 的代码的开发提出了相当高的要求：

1.模块间代码耦合度要极低，从而能够做到动态调整逻辑；

2.如果云端控制只用于事故止损，那么就要求所有受影响的应用

必须保持后台在线或者前台运行的状态。不过具体到当前市场

份额最大的几个手机/移动操作系统，我们可以通过推送通知

的方式的，尽可能由用户主动唤起应用，借此来获得下发云端

命令的机会；

我们建议开发者可以综合考虑应用的代码风格、业务类型、风险类型，来选择某一止损的方案。上述两种方案并非最优解，实际的开发过程中可能需要综合多种方案来达到高可用服务的标准。

同时，目前业界也涌现出一些成熟的解决方案，如iOS平台的APP动态更新服务JSPatch(https://www.wendangku.net/doc/a83632955.html,)就是一个专注于此领域的平台，开发者可以试用、借鉴。

6.3监控体系建设

6.3.1质量标准

1.什么是质量标准：

质量标准是产品生产、检验和评定质量的技术依据。产品质量特性一般以定量表示，例如强度、硬度、化学成分等；所谓标准，指的

是衡量某一事物或某项工作应该达到的水平、尺度和必须遵守的规定。而规定产品质量特性应达到的技术要求，称为“产品质量标准”。（定义来源：百度百科）

APP作为与用户直接与用户打交道的产品，其用户体验是衡量一个APP的重要部分。用户体验包含了视觉、友好性、易用性等等方面。但是其视觉等方面很难通过量化的方式进行度量。但是产品的核心功能等却是通过一些数据的度量来衡量产品的易用性等。因此，产品的质量标准就应运而生。

在服务类产品中，常用SLA（Service-Level Agreement）作为衡量产品服务等级的量化指标。按照业务的需求对业务的，对业务的服务指标制定量化的标准，通过量化的标准来衡量和驱动产品的服务越来越好。例如作为APP产品中的crash率，是衡量一个APP稳定性的数据指标，通过对crash率的统计数据衡量分析，来保证每个发版的APP健壮性得到保障。

2.质量标准应如何制定：

质量标准的目的是通过对业务数据的量化与衡量来保证服务的质量，通过质量标准的衡量来推动业务质量变得越来越好。那么应该如何来制定质量标准呢？

质量标准的建立大致总结为：一个核心、三个阶段：

一个核心：时刻以产品线的业务发展为核心

三个阶段：初期阶段、中期阶段和进阶阶段

为什么质量标准的建立要围绕业务发展来制定？举个例子，比如百度钱包，钱包在初始阶段，其核心的业务指标为发展用户，那么用

户的登录，日活等指标为钱包的最核心的指标；在钱包发展到一定阶段，绑卡用户变成了钱包的另一个核心指标。那么绑卡率变成了业务的核心发展指标。相应的核心质量标准也应该变为绑卡成功率。因此，质量标准制定一定是随着业务发展来演进。

在业务发展的不同阶段所设定和采纳的质量标准也是不尽相同的，按照标准由粗到细，量化难度由易到难的阶段一步一步发展而来的。

初期阶段：业务发展的初期或者业务发展到一定的阶段，通过需求或者用户反馈来收集到产品线在发展过程中需要核心保证的top功能，这个核心的功能是一个产品生存的支柱，也就是我们需要通过质量标准来衡量我们核心业务提供的服务好坏程度。举个例子，APP 的崩溃情况，是每个产品线所要保证的最基本的质量防线，崩溃率的高低，决定了用户的留存情况，因此，所有产品线都应将崩溃率作为最基本质量标准。而对于不同的产品线，则有各自自身的核心业务指标，比如手机百度，死链的情况则是关系到用户体验的最核心指标；下载的成功率是百度云用户体验的最核心指标；定位和路线的准确性是地图最核心的用户体验指标。

中期阶段：中期阶段是在初期阶段的质量指标建立完之后，并且在指标的数据获取，指标的计算公式都得到检验之后（尤其是得到peer角色的认可），进入到成熟阶段。中期阶段的目标是建立多个完整的子业务质量闭环。APP的呈现在用户面前的服务能力和用户体验，是每个业务的综合能力体验，对于APP自身的业务、服务端

的服务能力、中间网络抖动情况都密不可分。因此，想要达到一个服务单元的完整质量闭环，必须能cover到整个业务链条中的每个质量节点。比如百度云的下载业务，一个完整的下载，从层级上面看，大致分为三个层级：1.APP自身下载逻辑，主要涉及到下载的重试、并发、容错等2. 中间业务层，主要是在下载过程中的下载分发、防盗链、PASS校验、CDN回源等等。3. 底层数据拉取，主要是分片数据的重组文件、跨机房的文件拉取等等。所以要完成一个整个下载的质量闭环，必须cover整个质量闭环的关键节点，每个关键节点都会指定相应节点的标准，每个节点的质量好坏的变化，都会在端的质量数据中有所体现。

进阶阶段：进阶阶段是在中期阶段相对成熟之后，针对于业务复杂的每个子业务都能通过服务单元中的核心节点数据来对质量做出评价。进阶阶段，对于每个细节的标准都很全面。任何影响到产品体验，和APP的运行质量的，都能通过数据分析得到。在中期阶段，

有了各个垂类业务的数据，以及在垂类的链条上面的关键节点的数据，能够清晰的知道垂类业务的质量。对于比较复杂的业务，其每个质量节点影响的不单单是一个垂类的业务。在进阶阶段，通过对详细子业务以及子业务之间的关系进行联系与刻画，形成了一张联动的质联网。

3.质量标准的用处：

质量标准的设定主要的目的是通过质量标准驱动质量提升。质量标准按照覆盖范围来分主要分为两大类：一是通用型，比如crash 率；二是与自身业务紧密相关的。

1)质量标准最初级的用处：衡量业务的好与坏。通过量化的手段，

对于业务的服务，APP的运营质量，进行度量。

2)发现业务中的缺陷：通过对服务单元中的质量数据度量，发现

业务质量中的薄弱环节，对于问题的发现和业务的优化提供数

据支撑。

3)业务贡献：通过对质量数据的分析与整合，对于产品策略提供

数据支撑和评判。

6.3.2能力指标

1.数据获取的能力：

基础数据是质量标准建立的基石，数据获取是一个产品线成熟度的一个标识。一般APP的数据获取途径主要有两大类：

(1)通用第三方统计平台：例如https://www.wendangku.net/doc/a83632955.html,以及一些第三方的

数据统计平台，通过提供SDK的方式，对APP的运行状态等

指标进行统计上报，并给出图形化的分析报告。

(2)自身业务的数据上报：通过业务埋点或者自己编写的SDK捕

捉上报。针对自身埋点或者自己编写SDK的方式，更加灵活。

2.数据分析的能力：

在数据获取的基础之上，数据分析是数据转化成质量数据、质量标准的必经之路。按照对业务梳理的方面进行划分、统计聚合，变为对业务有用的数据。业务数据的分析的能力集中体现如下方面：

(1) 数据计算能力，对于离散数据的计算，需要大量的数据计算才能完成，一套高效、运行流畅的计算框架是对于大数据计算的前提。

(2)业务梳理能力，需要对业务的理解和上下游串联有比较细粒度

的认识

(3)业务数据分析的能力，对于统计后的数据，能够对应到业务的

表现，并能通过数据的变化来预测或者评价业务好坏。

3.质量数据的闭环：

质量数据的闭环是一个比较长期的过程，通过对数据的获取、数据的分析后，得出业务中不合理或者比较薄弱的地方，通过制定合理的优化方案，对业务进行调整优化。然后循环往复来达到质量数据的闭环。