移动App有着自己独特的运行环境和应用场景，线上的移动互联产品质量做到可视、可控，是一个非常重要的质量诉求。移动App是最新几年才出现的新产品形态，因此，如何保障移动App质量也是一个新的挑战和话题。近期，百度质量部会为大家带来系列文章，重点介绍App端问题如何发现、如何定位、如何止损，以及如何建立起一套有效的监控体系，为App稳定应用保驾护航。

上周，我们跟大家分享了端问题的概述，今天我们来分解问题，告诉大家如何去去布局一套完善的监控体系。

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

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

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

   a)    应用crash（崩溃）

   b)    Android应用的ANR（ApplicationNot Responding）

   c)    网络错误

   d)    请求响应时间长

   e)    用户交互不流畅

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

3. 来自移动端和后端服务之间的链路问题，通常有：网络问题造成的丢包、TCP重传等等

如上文所述，不同于服务端的产品，移动端APP的监控有自己的特点，但是对于一个产品的质量监控，我们仍然可以从通用的三个方向去布局一套完善的监控体系：问题发现、问题定位、问题止损。

移动端应用受用户机型、Rom、复杂的网络环境、多变的用户操作路径影响，无法保证在测试阶段可以暴露所有的问题，这就要求我们建立一套完善的线上问题发现体系。根据产品的核心业务，抽取核心质量指标，实现指标量化，制定质量标准，实时监控报警。

通常移动端应用的质量指标包括但不局限于：安装成功率，崩溃率，网络错误比例，请求响应时间等。质量指标与具体的应用功能紧密相关。理论上抽取指标后，如何量化是最困难也是最关键的一步。量化需要有效的问题信息获取途径，经验证，用户反馈和日志埋点是两种行之有效的方法。

一款应用想要在应用市场份额中分得一杯羹，长久地留住用户，需要依赖良好的应用功能和产品体验。用户反馈代表着市场对这款应用的质量信号，也是这款应用的口碑和第一手资料，前期我们可以通过市场调研等方式获取，但是受限于人力和时间成本，我们很难在用户众多的时候复用此法，或者说这样的市场调研始终只能做采样而无法全量。

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

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

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

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

• 反馈入口路径尽可能短：上述的两个反馈入口都在应用的设备界面，进入反馈页面需要2步。这一复杂度刚刚好，如果一个反馈需要用户操作4、5步才能找到，那么用户的热情会被这种来自技术的傲慢消磨殆尽。

• 反馈内容的提交成本尽可能低：左侧图片中爱奇艺的用户反馈，不仅事先列出了用户最可能用到的几种问题，还在页面下方给出了常见问题的FAQ。不要小看了这一细节，我们可以通过这样的方式，在无形之中完成一次用户问题反馈+调查问卷。

• 对用户的答复应该尽可能的快：用户反馈是一个C2B的模式，也就是client反馈给business，如果想要给用户更实时的体验，那就要求我们在用户反馈页面完成一个IM的功能，这对大多数处于创业阶段的开发者来说并不现实，所以我们建议采用集成插件的方式来达到这一个目的。下面推荐几款常用的用户反馈平台：

1）美洽，基于HTML5开发，只需在IOS/Android支持H5的浏览器中打开即可，无需安装任何软件程序，代码植入，一步到位，简化沟通流程。

2）Udesk：支持Android、iOS以及APIcloud三大平台，可以对用户反馈的数据做统计分析，并展示结果。

3）Freshdesk，致力于中小企业网站在线客服技术支持的网站，提供中小企业网站的在线服务质量和用户体验度，目前FreshDesk客户人数达到了1万家，证明Freshdesk的发展还是很稳定的。

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

目前市场上也兴起了很多调研的平台或工具，可以推荐给大家快速大规模的收集到目标用户的使用反馈情况。百度移动云测试中心（MTC）所提供的问卷调研服务，就是特别针对移动互联网用户所提供的调研服务。

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

为何要埋点

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

埋点于何处

好的埋点可以达到一夫当关万夫莫开的效果，将所有我们需要的信息通过日志的形式打印出来，从而上传到后端，供我们分析问题、刻画用户，从而获得移动产品的改进方向，以及产品变现的数据支撑。受限于移动端应用的运行环境，我们不可能在所有的地方进行埋点，笔者在多年的软件开发维护过程中，也见过由于日志添加不当引起程序崩溃的问题。

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

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

1. 由目标驱动埋点：一个移动应用，开发者或者用户希望了解的服务指标，必须由日志埋点解决；

2. 框架通用：应用的第一个版本在日志框架上面花的时间，直接影响后续版本的开发效率，所谓磨刀不误砍柴工，世事大多如此；

3. 日志上传：对于已经获取的埋点日志，我们必须考虑它对用户流量及交互流畅度方面的影响——毕竟它的上传使用的是用户网络，尤其是在收费的移动网络下。有如下一下手段可参考借鉴：日志压缩和私有协议；用抽样上传代替全量监控；如果日志对时效性的要求不高，可以考虑采用打包整体上传代替实时上传的方式，甚至可以每天上传一次，而不是每次使用都做上传。这些都需要在框架中提前做好部署工作。

4. 日志安全：用户日志中可能包含用户个人信息、用户行为及隐私，一旦信息泄露，可能给用户造成经济，人身安全等方面的损失，严重影响用户对应用的信任。故日志安全是重中之重，目前行之有效的方法主要有加密和使用安全协议。相对于加密算法较容易被破解的风险，安全协议提供了更严密的保护。目前应用比较广泛的安全协议主要有https，spdy等。

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

1.    日志分析法

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

当然并不是所有的问题都可以通过用户日志定位，比如日志不全或日志提供的信息并不足以精确定位问题，怎么办呢？

2.    问题复现法

通过用户对问题的现象描述，以及已有的用户日志，尝试线下复现。复现时可能需要关注用户的机型，平台，网络类型，是否设置了代理，甚至是用户所处的地理位置等，以及通过对业务原理的了解，推测可能出现该问题的原因，尽量增加复现的可能性。

3.    推测验证法

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

4.    上下游合作分析

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

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

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

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

一个简单的例子：我们可以把功能开关置于一个独立的WebServer中，App采用轮询或者更加精准的动态策略去访问这个静态文件，服务某个环节出现问题，只需要修改WebServer中的开关文件，关闭相关功能或者将相应的服务导向备用地址。可以用于止损的功能开关，模块配置等均可以通过此方式实现。

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

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

2. 如果云端控制只用于事故止损，那么就要求所有受影响的App必须保持在线或者说是前台运行的状态。不过具体到当前市场份额最大的几个手机/移动操作系统，我们可以通过推送通知的方式的，尽可能由用户主动唤起应用App，借此来获得下发云端命令的机会；

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

同时，目前业界也涌现出一些成熟的解决方案，如iOS平台的App动态更新服务JSPatch(http://jspatch.com)就是一个专注于此领域的平台。

如果你看的意犹未尽，如果你想随时随地充实自己，请扫描以下二维码，关注我们的公众账号，可以获取更多技术类干货，还有精彩活动与你分享~