移动应用中用户体验不流畅的20大问题

结合过去几年移动开发的经历，列举了20个导致用户体验的问题，希望大家看过后能吸取经验教训；

完美的产品只存在于虚化中，但这不影响我们追求完美；那些问题也许并不都是开发人员造成，但这不影响我们一起来思考做出极致产品。

(1)注册时，有时很难收到验证码；导致一批用户堵在了注册阶段。

a)  原因：短信通道不稳定；很多短信需要先通过第三方渠道公司审核，而后才能发出去。

b)  解决方案：

这个问题无法彻底解决，只能缓解。

一，这是个普遍存在的问题，任何平台都会遇到，原因是垃圾短信太多，导致监督部门会经常核查；除非跳过第三方渠道，直接对接运营商。

二，由于是个普遍存在的问题，所以产品中不能把短信当做一个可靠，及时的信息通道。

三，缓解方案：可以同时对接两家第三方平台，交替使用；

四，缓解方案：短信的到达是不能保证顺序。这会导致如果用户第一次获取验证码长时间没收到，他会再次获取验证码。过了会儿他收到短信验证码，但是不能保证这个短信是针对第一次的，还是第二次的。所以短时间间隔的生成验证码保证是一样。

 

(2)注册时在填写资料阶段，用户流失率很高；

a)  原因：填写信息太多；有的信息很敏感，用户不愿填写，如真实姓名，身法证号，银行卡号。

b)  解决方案：使用过程中，到必要时，引导客户逐步补全信息；在和用户建立信任关系后，才要求其填写敏感信息。

 

(3)刷新信息流，加载速度特别慢；

a)  原因：信息流中图片太大；

b)  解决方案：a,使用缩略图；b,图片懒加载；c,图片的缓存。

 

(4)一些问题在3G网络中暴露出来：

a)  原因：测试阶段只在内网中测试，而内网网络情况一定优于3G网络。

b)  解决方案：在外网搭建预发布环境；或直接将测试环境搭建在外网中。

 

(5)Android端特别耗电：

a)  原因：由于一些服务没有及时关闭，同时测试也漏过了该项测试。

b)  解决方案：测试需要关注性能测试，耗电测试作为其中的一项性能指标。

 

(6)使用中有些按钮需要多按一次才有效果：

a)  原因：按钮触控区域太小；

b)  解决方案：测试和开发人员不能轻易漏过交互上不顺畅的地方，发现后尽快改进；此外，此类问题需要设计师制定一套交互规范。

 

(7)长时间使用APP会导致闪退；

a)  原因：典型的内存耗尽的问题。

b)  解决方案：开发人员在最后需要做好内存检测工作；测试人员针对测试过程中的闪退问题要予以重视，不能因为不能重现而轻易放弃；开发人员提供异常日志记录功能，不能因为测试不能重现问题而轻易放弃。

 

(8)页面切换时感觉太慢；

a)  原因：在上个页面先从服务器获取数据，然后再跳转到下个页面。

b)  解决方案：先跳转到下个页面，渲染部分内容，同时获取全量数据；待获取所有数据后，再把剩余内容加载出来。

 

(9)上传头像太慢

a)  原因：没有对图片进行缩放，裁剪，和压缩。

b)  解决方案：产品和设计对图片的展示做个估算，定义好图片的最大尺寸，以及图片的质量。大多数时候并不需要质量太高的图片，上传大图片既浪费用户流量，也占用服务器带宽和服务器存储空间。

 

(10)    注册时，对于某些手机号码号段不支持；

a)  原因：新号段的手机号码不断出现，而客户端对手机号码检验没考虑到。

b)  解决方案：客户端做比较松的检验，更严格的检验交由服务器端进行。

(11)    表情符号导致某些输入导致服务端异常或客户端闪退；

a)  原因：数据库只支持3byte的utf-8；而表情符是4bytes。

b)  解决方案：考虑android和iphone对表情符号的解释不同，建议不容许上传表情符号。这个需要大家研究一下！

 

(12)    文字显示越位，覆盖到了其他区域；

a)  原因：文字内容比想象的要长。

b)  解决方案：产品和设计要对字符串的字数和长度进行交流，考虑极限情况下的布局。实际上，产品要对所有的输入内容规定长度和规则。

 

(13)    GPS定位不准，定位时间太长；

a)  原因：GPS定位精度在10米左右，且在有遮罩的下（阴天有云，车内，室内）定位非常困难，而且慢。

b)  解决方案：测试人员在接近用户使用环境的场景下进行外场测试。

 

(14)    应用经常闪退；

a)  原因：大多是开发的问题；比方访问无效地址，数组越界，没有变量初始化就开始使用。

b)  解决方案：

一，这类问题主要靠程序员自身习惯和素质，加强代码规范。

二，在时间充足的情况下，做好代码走查的工作。

三，在上线后遇到此类问题会更加棘手，所有对于闪退类问题要在应用里做好日志记录，以及自动发送日志的功能。

 

(15)    用户一直按“登录”，但就是登录不了。

a)  原因：当时是由于服务器端异常，无法处理导致。且客户端没有错误提示，导致用户非常困惑。

b)  解决方案：任何出错情况下，（预料到达，预料不到的）都有给用户一个提示。

 

(16)    在上线后，设计和产品说某些地方的交互不是和设计的有出入。

a)  原因：上线前，设计和产品并没认真使用APP的全部功能。

b)  解决方案：开发完成后，设计和产品首先要对产品进行全面试用，并签字画押，而后交由测试。

(17)    接口数据返回异常导致APP闪退。

a)  原因：数据结构的变化，数据范围的变化，服务器处理异常导致返回无意义数据。

b)  解决方案：客户端对异常处理；服务器端在数据结构或数值范围变化时，通知客户端开发人员。

(18)    APP检测更新。

a)  体验：由于协议或接口变化会导致早期版本不能使用，这种情况下只能要求用户在打开APP时强制更新。

b)  解决方案：检测更新提供选择升级和强制升级两种可能性。慎用强制更新，会导致用户直接卸载。

(19)    保持登录

a)  体验：网页上习惯是30分钟不操作就需要重新登录，对于客户端无需加这个限制，毕竟手机不会随便借给他人使用。

(20)    刷新信息的速度越来越慢

a)  原因：接口返回数据时间过长；这样的问题基本在测试环境或早期都不会出现，当使用人数越来越多的时候才会出现，具有隐蔽性。

b)  解决方案：（1）服务器端在接口调用时记录时间，及时发现慢调用的接口。（2）优化方法：加数据库索引，优化算法，不经常更新的数据放入缓存，提前计算数据，减少返回数据的量。

(21)    涉及支付的流程：下单后，除了在系统里可以完成支付，还可以在支付宝里完成支付。这个坑直接导致我们搞抢购活动的超卖货品。按活动规则，下单后15分钟没有支付成功，取消订单并归还库存；这个时候虽然订单在我们系统里取消了，但支付宝里的交易还在，用户可以直接在支付宝里继续完成交易。解决的方案是，在生成支付宝交易时，定义好交易的取消时间，保证支付宝交易和我们系统里的订单同时失效。

最后，在团队里我要求在产品上线前，务必核对以下要点：

1.    APP中是否装备了必备功能：统计，日志收集及发送，版本检测以及自动更新，用户反馈；
2.    确保产品经理和设计师体验过了APP，签字画押。确保APP体现了产品和设计的构想，没有理解上的差错。
3.    检查测试用客户端上是否有系统奔溃的异常记录。对频繁发生的异常，必须予以重视。
4.    去掉所有的调试代码。（注释为 //debug 的代码块）
5.    清除所有代码中warning；
6.    确定连接的是正式服务器。
7.    将日志等级改为，只记录严重问题。
8.    做一遍内存监测，特别关注列表页面和图片处理显示页面。操作多次，看看是否内存会收回还是在不断增长。
9.    估测一下应用的耗电量。