背景

IM功能开发过程中，有这么一个需求，在打开会话详情页时Intent内可以携带一些消息，用于用户从商品详情页点击联系维护人时可以携带该商品的信息。Intent内可以携带多条消息，用于跳转到会话详情页时自动发送消息。

后续做了一个提醒功能，客户发来消息，B端用户端会弹出一个持续震动响铃的提醒页面，提醒页面有固定几条话术，点击后可以快速进入会话并自动发送该消息。

问题一：代码Bug引起的消息重复发送

有B端用户反馈，系统会自动发送消息，当时还觉得是服务端触发的，因为客户端不会触发自动发送消息逻辑，而且代码已经跑了很久没有修改，没有问题反馈了。但是排查消息发送源后发现确实是客户端发送的。通过日志定位客户端操作链路后发现是代码Bug引起。

这里的问题主要是未清空初始化会话详情页时携带的消息内容引起。

问题二：Activity重启引起的重复发送

解决完问题一有一段时间内没有上报该问题，但是这两天又有上报重复消息发送的触发，让人一头雾水。确认了用户已经使用了修复问题后的版本后，开始从日志排查。排查过程中发现，出现触发发送日志的地方有全局的进入后台，回到前台的日志打印，再发现有页面创建的日志，但是携带的参数还是第一次发送消息时的内容，猜测到可能是切入后台，页面被回收，重新打开系统又传递了第一次携带的内容，触发了bug。

activity的销毁分为正常销毁和非正常销毁：

• 正常销毁：被销毁之后不会被自动重建。比如我们主动调用了finish()、杀死了进程、用户通过点击返回键退出了activity等。它的生命周期：

onCreate
onStart
onResume

onPause
onStop
onDestroy

• 非正常销毁：被销毁之后会被自动重建。比如，当系统内存紧张时，不可见的activity可能被销毁以节省内存，当activity被重新展现时就会被自动重建。当手机屏幕旋转时，activity(如果没有锁定方向的话)也会被销毁并自动重建。它的生命周期：

onPause
onSaveInstanceState*
onStop
onDestroy

onCreate
onStart
onRestoreInstanceState*
onResume

这里跟onSaveInstanceState没有关系了，非正常销毁时，系统再次传递了之前打开的Intent内容，导致触发了重新发送。

总结

遇到的问题都不是什么高深的技术，但是要排查还是有一定的难度，对开发过程的一些反思：