一朝入坑深似海，自此故障是路人，记一次真正怀疑人生的BUG排查。
二十一、�卖家反馈我们的买家拼命的发送重复消息
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。一般通常的代码写法如下：
常见的选择文件操作代码
-
错误原因：
- Android平台的适配问题是一直是个大问题，再加上各家rom的实现，以及各版本的问题，导致返回的路径非常不稳定。详见文章：android-display-selected-image-and-its-real-path
-
解决方案：
- 既然用原生的选择图片不靠谱，那就索性直接自己写一个图片选择组件吧，比如：PhotoPicker，用自己的东西，心里才踏实。
网友评论