Android开发错误姿式100手-21-22

二十一、卖家反馈我们的买家拼命的发送重复消息

1. 现象

  • 近期,有用户在外网反馈:外网链接 说总是发送重复的消息。

2. 排查思路和过程

  • 根据用户的反馈和截图,发现统一都是Android用户,无一例iOS用户,然后按照常理,就去排查Android端的问题。
  • 查看Android端代码,只是简单http post请求,底层就算有网络重试,但那也是秒级别的,而不可能用户退出登录了还发送!
  • 然后就去怀疑客户端发送出去后,网络上有什么操作呢?有动态加速,可参照:动态加速网络DSA,但大厂作品,就直接放过,不怀疑了。
  • 那是不是用户有真实的发送网络请求到我们的服务器呢?经过排查日志,结果是:有。
  • 那到底是谁发的请求呢?通过日志排查,发现 182 请求的都带上了 test=true 的标识,而这个标识是测试在做压测时网络请求回放的标识。
  • 什么?压测?是的,为了保障服务稳定,会抓取真实的用户网络请求,进行回放压测。那为什么压测要测试线上写接口?原来测试整理了写接口列表,比如:aaa,bbb,ccc,ddd,eee,fff,然后不在这个列表中的,就都认为是只读接口。而发消息的接口,hhh,没有在测试的写接口中,然后就被拿去做请求回放了,揉虐个千百遍了,难怪用户卸载了,退出登陆了,还会发重复的消息。

3. 反思

  • 为什么只有Android用户?iOS没有?`这明显是错的,iOS有,只不过Android积极活跃人群多,所以总是可以最早暴露问题!所以后面不要再轻信:`只有Android端有问题!
  • 为什么业务层不做脏数据处理?前期客户端没有传递唯一标识到业务端,所以业务端没办法去做去重处理,但最一开始上线时,就应该考虑到传递唯一标识,然后根据唯一标识进行去重的设计。现客户端已完成传递唯一标准的功能,供后期业务层去增加健壮性。

4. 感悟

  • DT在线时代,我们要求:不仅仅是上线一个需求,更应该把数据,问题排查,功能降级,代码健壮性等一套方案发布上线。才不至于在出现问题的时候,手忙脚乱,毫无头绪,浪费大量的时间精力来排查问题!提升自己的效率。Come on, Guys!

二十二、用户选择相册中图片后App Crash

  • 错误姿式:
    • 新版本为了新活动,上线了一个好玩的小游戏,其中用到了从用户像册去选择照片。用户选择相册文件后,返回后直接Crash。一般通常的代码写法如下:

选择文件操作代码

  • 错误原因:

  • 解决方案:

    • 既然用原生的选择图片不靠谱,那就索性直接自己写一个图片选择组件吧,比如:PhotoPicker,用自己的东西,心里才踏实。

赛文市场营销

发表评论

您的电子邮箱地址不会被公开。 必填项已用 * 标注