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