二十一、卖家反馈我们的买家拼命的发送重复消息
1. 现象
- 近期，有用户在外网反馈:外网链接 说总是发送重复的消息。
2. 排查思路和过程
- 根据用户的反馈和截图，发现统一都是Android用户，无一例iOS用户，然后按照常理，就去排查Android端的问题。
- 查看Android端代码，只是简单http post请求，底层就算有网络重试，但那也是秒级别的，而不可能用户退出登录了还发送！
- 然后就去怀疑客户端发送出去后，网络上有什么操作呢？有动态加速，可参照：动态加速网络DSA，但大厂作品，就直接放过，不怀疑了。
- 那是不是用户有真实的发送网络请求到我们的服务器呢？经过排查日志，结果是：有。
- 那到底是谁发的请求呢？通过日志排查，发现 182 请求的都带上了
test=true - 什么？压测？是的，为了保障服务稳定，会抓取真实的用户网络请求，进行回放压测。那为什么压测要测试线上写接口？原来测试整理了写接口列表，比如：
aaa,bbb,ccc,ddd,eee,fff
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，用自己的东西，心里才踏实。
赛文市场营销