概论：
移动APP有着⾃⼰独特的运⾏环境和使⽤场景，相⽐后端服务，移动APP质量同样需要做到可视、可控。移动APP是近⼏年刚刚出现的新产品形态，如何保障移动APP质量是⼀个新的挑战和话题。今天，我们重点介绍APP端问题如何发现、如何定位、如何⽌损，以及如何建⽴起⼀套有效的监控体系，为APP稳定应⽤保驾护航。分为“端问题概述、端质量监控⽅案、端监控能⼒建设”三个章节。 1端问题概述
app客户端产品上线前，会经过全⾯⽽且严谨的测试再发布到应⽤商店。但，发布后产品质量如何，以往更多地依赖于⽤户的反馈信息。对于较⼤规模的app产品，测试⼈员⽆法做到覆盖到全部的⼿机机型和ROM。在这种情况下，如何知道⼀款产品到⽤户⼿中的质量呢？此时，需要⼀套完善的质量监控⽅案，建⽴⼀套牢固的监控体系。这样，对线上产品的APP质量问题才能第⼀时间召回，并做到快速修复。 1.1常见问题国家燃烧
1.适配问题
客户端测试过程中，测试⼯程师会覆盖当前⽐较主流⼚商的机型和ROM，以及市⾯⽤户量⽐较⼤的android/ios版本。但，毕竟⽆法覆盖到市⾯上所有的机型和ROM，尤其是android系统的⼿机。所以，⽤户在下载⼀款app后经常反馈在⾃⼰的⼿机上页⾯很丑，甚⾄有的⽂字重叠，控件位置显⽰不正确等问题。
举⼀个实际遇的问题，当app上线后收到⽤户反馈，提到有些页⾯滑动⽐较卡顿，容易造成误点击，⽤户使⽤的机型是⼀款⽐较主流的⼿机。在获取到⽤户反馈后，测试⼯程师马上到同款⼿机进⾏复现，但未复现⽤户反馈的问题。后来从⽤户得知复现的⼿机和⽤户的⼿机虽然相同，但是⼚商⾃⼰定制的ROM版本不同，后来通过研究ROM代码发现⼚商在新版ROM中设计了⼀些新的逻辑处理，会直接导致app出现卡顿。研发⼈员对此做了适配解决了卡顿的问题。此类案例证明，务必对主流⼿机及ROM更新保持较⾼的质量敏感性，时刻关注⼚商升级。快速应变，及时适配到主流机型和ROM。
2.⽤户体验问题
通常，产品经理设计产品功能时，考虑得也不⼀定很全⾯，往往抱着试错的⼼态来设计产品，并希望通过⽤户反馈来得知产品的好坏，以及⽤户的进⼀步需求。⼀旦考虑不周，往往就是取悦⼀部分⽤户，同时伤害到⼀部分⽤户。举⼀个实际例⼦，某⼀搜索类产品，产品经理为让⽤户在夜间浏览时有更好的视觉体验，增加了夜间浏览模式的功能。考虑到让⽤户更⽅便的设置夜间模式，产品设定为晚
上20点以后⾃动弹出⼀个浮层，询问⽤户是否设置夜间模式，⽽且⼀键即可设定，⽅便了⽤户对夜间模式的启⽤。但，产品经理忽略了⼀个重要的问题，晚上⽤户启⽤夜间模式后，第⼆天早上如何便捷地切换回⽩天模式？⽽产品并没有在早上也设置⼀个浮层做⼀键切换。这样，很多⽤户在⽩天也开启了夜间模式，使⽤体验是很糟糕的。问题在于，切换回⽩天模式的功能虽然具备，但是⼊⼝隐蔽，⽤户很难到。从这个问题可以看出，产品体验是设计出来的，需要在⽤户的实际应⽤中得到检验。
江苏交广网
3.流量问题
当前，中国的4G资费相对欧美和⽇韩⽬前还是⽐较⾼的，同时免费的公共wifi覆盖也不⾼，⽤户对⾮wifi下的移动流量消费是很在意的。那么，⼀款移动app产品如何利⽤最少的流量下提供更多的功能？通过客户端缓存是⼀个常见的技术。举⼀个实际例⼦，以⼩说阅读为例，⼩说⽬录⼀般是罗列很多书籍供⽤户来选择，这些书籍⼀般都有书籍名，数据封⾯图及书籍简介组成。⼀个页⾯的数据有150kb，⽽且这个页⾯是⼩说书单的主⼊⼝，所有关于⼩说的操作都要由这个页⾯开始。如果⽤户反复请求这个页⾯，不仅造成流量的浪费也会给服务端带来很⼤的请求压⼒。为此，将这个页⾯的数据缓存到客户端本地，如果⽤户在⾮wifi的⽹络下就不发送请求，如果在wifi⽹络环境下每间隔⼀定时间去服务端请求⼀次数据，然后将⽼数据删除，并将新的数据写到本地，以便⽤户能够获取到最新内容。这样，不仅解决了流量问题，也解决了⼀些低配⼿机本地内存经常不⾜的问题。从这个问题来看，在产品设计时多从⽤户的⾓度出发考虑问题，⽤户不⼀定直观地感知到，但实实在在的增加了⽤
户体验，且减少不必要的流量消费，你说何乐⽽不为呢。
1.2 问题特征
上节介绍了三类常见问题。有些问题是⽐较容易复现和解决的，也有⼀些问题相对是有难度的。举⼏个例⼦：
场景⼀：⽤户反馈在WIFI⽹络下⽆法发起搜素，搜索结果异常。在WIFI环境下复现，⽆法复现⽤户反馈的问题，这时往往会归结为⽹络不稳定造成的。但⽤户可能当时确实是遇到了问题，这种⽆法稳定复现的问题，往往归结为偶发性的问题。
场景⼆：⽤户反馈离线下载的⼩说为什么有时候还需要⽹络。由于⽤户离线的⼩说是个连载的⼩说，当⽤户阅读完离线的内容后，假设这时候⼩说有更新了，产品经理为了让⽤户能够连续的阅读就将产品设计成联⽹发送在线请求才能继续阅读，这和⽤户的认知就⽐较相违背。但，如果⽤户阅读完已经离线的部分，⽤户看到书没写完，也会关⼼为何没有新的内容呢。类似的这种问题归结为长尾问题，需要从产品策略上持续优化来解决。
伊斯兰国APP运⾏在⽤户⼿机端，并且联⽹到后端服务，许多质量问题也有其⾃⼰的独特性。因此，需要通过不同⼿段，来实现问题的发现、定位和修复。
1.3 ⾯临挑战
对于上述提到的问题，⼤家可能会问：这些问题该如何发现，对于这些问题如何确定是否做马上修复，哪些问题才算长尾问题？这就是下⾯将要介绍的线上问题的召回⽅式和问题影响⾯的评估。⽤户反馈是召回问题的⼀种⽅式，但是这种被动的召回不⾜以满⾜快速召回线上问题的要求，所以搭建⼀整套完善的监控系统就⾮常必要了。
1.监控的挑战
对于客户端产品，⼀旦发布出去就很难有效的控制产品的质量。为此，产品经理和数据分析师往往在产品发布前提出的监控及统计需求，研发⼯程师开发设计⽤于监控统计⽬的的代码，将⽤户的⾏为、产品的crash等核⼼质量信息以⽇志的⽅式上传到服务端，这些⽤户所产⽣的数据就为后续分析产品及质量问题提供了原始的数据依据。
2.影响⾯的判断
利⽤客户端上传的⽤户⽇志及客户端崩溃信息，进⾏统计分析。结合线上问题，可进⾏影响⾯的评估。影响⾯评估主要有三类，包括严重问题，特定场景复现问题，不影响主要功能问题。
1) 严重问题⼀般是要发⼩版本来修复的问题
2) 特定场景复现问题⼀般不会发⼩版本修复，但⼀定会在下⼀个版本进⾏修复
3) 不影响主要功能问题视下⼀个版本的排期进⾏修复或删减掉
孟连经验
2端质量监控⽅案
由于APP载体多种多样，产品质量问题表现形式有很多种。我们以最通⽤的APP为例，总结为以下⼏种：
- 来⾃APP产品所依赖的后端服务的问题
- 来⾃APP产品⾃⾝的问题，包括稳定性问题，表现为：应⽤crash（崩溃）、ANR（APPlication Not Responding）、⽹络错误、请求响应时间长、⽤户交互不流畅、机型、ROM适配度不够引起的兼容性问题。
- 来⾃APP和后端服务之间的链路问题，通常有：⽹络问题造成的丢包、TCP重传等等。
对于APP质量监控，可以从三个⽅向去布局⼀套完善的监控体系：问题发现、问题定位、问题⽌损。
2.1 问题发现
由于APP受⽤户机型、⼿机ROM、⽹络环境、⽤户操作路径差异的影响较⼤，QA⽆法保证在测试阶段暴露所有问题，这就要求我们建⽴⼀套线上问题发现体系，及时召回已经交付到线上的移动产品。⼀套完善的线上问题发现体系，通常来说需要根据产品的核⼼业务，抽象出核⼼指标，实现指标量化；制定质量标准，提供实时监控报警。
根据我们的经验，APP应⽤的质量指标包括但不局限于：安装成功率，崩溃率，ANR⽐例，⽹络错误⽐例，请求响应时间等。质量指标与具体的应⽤功能紧密相关。理论上抽取指标后，如何量化是最关键也是最困难的⼀步。量化需要有效的问题信息获取途径，⽇志埋点是⼀种⾮常通⽤的⽅法，⽽另外⼀种途径，⽤户反馈，虽然常常被开发者忽略，却同样重要。
2.1.1 ⽤户反馈：海纳百川
⼀款应⽤想要在应⽤市场份额中分得⼀杯羹，长久地留住⽤户，需要依赖良好的应⽤功能和产品体验。⽤户反馈代表着市场对这款应⽤的满意度，能够直接反映⽤户的判断和诉求，也是这款应⽤迭代改进的第⼀⼿资料，前期我们可以通过市场调研等⽅式获取反馈，但是受限于⼈⼒和时间成本，我们很难在⽤户量巨⼤的时候复⽤此法，或者说市场调研始终只能采样⽽⽆法全量覆盖。
基于上述，只有提供⼀个⼊⼝，让所有⽤户的反馈可以如江河⼊海，汇于⼀处，我们才能获取到来⾃不同地域、不同⽹络、不同机型、不同场景下的⽤户反馈，进⽽聚类、分析、改进我们的产品。
⽤户反馈的通⽤⽅法并⽆太多新奇之处，市⾯上很多移动应⽤都会在应⽤设置页⾯中附上⼀个⽤户反馈的⼊⼝，如图2.1中百度云和爱奇艺视频的⽤户反馈界⾯。
我们必须要明⽩⼀点，如今快节奏的⽣活中，⽤户愿意提交⼀个反馈，那这个问题对他/她来说⼀定是⼀个很⼤的困扰，⽽且他/她⼜是⼀个⽐较忠实的⽤户，同时对这款应⽤抱有期待，希望开发者可以改进。所以⼀旦这个产品开始提供更稳定或者功能更多的收费服务来尝试变现，那么这部分⽤户会是最⼤的潜在体。
⼀个普通的⽤户反馈页，却是于细微处见真章的最好实例，这两个页⾯的设计告诉我们⽤户反馈的重要原则：
反馈⼊⼝路径尽可能短：上述的两个反馈⼊⼝都在应⽤的设备界⾯，进⼊反馈页⾯需要2步操作。这⼀复杂度刚刚好，如果⼀个反馈需要⽤户操作4、5步才能到，那么⽤户的热情会被这种来⾃技术的傲慢消磨殆尽。
反馈内容的提交成本尽可能低：左侧图⽚中爱奇艺的⽤户反馈，不仅事先列出了⽤户最可能遇到的⼏种问题，还在页⾯下⽅给出了常见问题的FAQ。不要⼩看了这⼀细节，我们可以通过这样的⽅式，在⽆形之中完成⼀次⽤户问题反馈+调查问卷。
对⽤户的答复应该尽可能的快：如果想要给⽤户反馈的过程提供更实时的体验，那就要求我们在⽤户反馈页⾯完成⼀个IM的功能，这对⼤多数处于创业阶段的开发者来说并不现实，所以我们建议采⽤集成插件的⽅式来达到这⼀⽬的。
下⾯推荐⼏款常⽤的⽤户反馈平台：
1) 美洽，基于HTML5开发，只需在IOS/Android⽀持H5的浏览器中打开即可，⽆需安装任何软件程序，代码植⼊，⼀步到位，简化沟通流程。
2) Udesk：⽀持Android、IOS以及APIcloud三⼤平台，可以对⽤户反馈的数据做统计分析，并展⽰结果。
3) Freshdesk，致⼒于中⼩企业⽹站技术⽀持的⽹站，提供中⼩企业⽹站的在线服务质量和⽤户体验度。
加拿大铝业除了在应⽤中直接反馈，也可以创建⽤户（QQ，或其他企业级IM），针对严重问题可以第⼀时间发现，直接与⽤户沟通，辅助复现、抓取问题现场信息等，这些对问题的定位和解决是⾄关重要的。
2.1.2 ⽇志埋点：秣马厉兵
在⼀个移动应⽤设计之初，开发者通常考虑的是功能、架构、开发周期等问题，这⼀类问题通常直接影响应⽤的发布周期，但是⼤家往往会忽略⼀个重要的过程，那就是⽇志埋点。
为何要埋点
通过⽤户反馈发现问题毕竟有⼀定的延时，甚⾄有⼀些线上问题会阻塞⽤户反馈，例如：连续频繁的崩溃，⽤户反馈模块⾃⾝的Bug等。要想更迅速及时的暴露问题，需要我们主动出击，获取⽤户操作的关键信息。
埋点于何处
⽇志埋点的原则：好的埋点可以达到⼀夫当关万夫莫开的效果，将所有我们需要的信息通过⽇志的形式打印出来，选择性或者全量的上传给应⽤的后端服务，⽤于⽀持问题发现或服务改进。
受限于APP应⽤的运⾏环境，我们不可能在所有的地⽅进⾏埋点，笔者在多年的软件开发维护过程中，也见过由于⽇志添加不当引起程序崩溃问题。
根据⾃⾝经验，我们总结出下列⽇志埋点的建议：
1）由⽬标驱动埋点：⼀个移动应⽤，开发者或者⽤户希望了解的服务指标，必须由⽇志埋点解决；
2）⽇志框架通⽤：应⽤的第⼀个版本在⽇志框架上⾯花的时间，直接影响后续版本的开发效率。通⽤和稳定是这个框架必须要考虑的问题。
反倾销论文3）⽇志上传：对于已经获取的埋点⽇志，我们必须考虑它对⽤户流量及交互流畅度⽅⾯的影响——
毕竟它的上传使⽤的是⽤户⽹络，尤其是在收费的移动⽹络下更要慎重。有如下⼿段可参考：⽇志压缩和私有协议、⽤抽样上传代替全量监控；如果⽇志对时效性的要求不⾼，可以考虑采⽤打包整体上传代替实时上传的⽅式，甚⾄可以每天上传⼀次。这些都需要在框架中提前做好部署⼯作。
4）⽇志安全：⽤户⽇志中可能包含⽤户个⼈信息、⽤户⾏为及隐私，⼀旦信息泄露，可能给⽤户造成经济、安全等⽅⾯的损失，严重影响⽤户对应⽤的信任。故⽇志安全是重中之重，⽬前⾏之有效的⽅法主要有加密和使⽤安全协议。相对于加密算法较容易被破解的风险，安全协议提供了更严密的保护。⽬前应⽤⽐较⼴泛的安全协议主要有https，spdy等。
2.问题定位
线上问题的快速定位和解决可以直接缩短⽤户体验受损的时间，通常有以下⼏种定位思路：
1）⽇志分析法
当遇到⼀个问题时，我们最先想到的可能就是查看⽇志，⽤户⽇志是定位问题的最直接的信息来源和⽅法。⽇志分析⼜可以分为两种⼿段：⼀是从统计学的⾓度分析⼤量的问题⽇志，总结聚类，通过其中共性的特征，发现潜在的问题；另⼀种是针对某个有明确问题反馈的⽤户，查询其⼀段时间内的所有操作流程及结果，通过上下⽂推测问题原因，也可以辅助线下复现。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议