记一篇工作中遇到的问题及解决问题的经验感受.

在平时工作中或多或少都会遇到一些难缠的问题，在遇到问题时我们总是习惯性的先看日志，然后定位问题，排查问题，debug，log一套走,可是有些问题往往超出自己的认知范围,知道有问题但是不知道从哪里入手，在这里我总结了最近遇到的问题:

1.项目集成了环信,然后启动一个后台服务，在service登录，注册，监听环信消息了,并且注册了一个evnetbus,然后习惯性的在ondestory()方法中取消注册.

问题:环信sdk监听消息回调方法偶尔会走两次，导致收到两条一模一样的消息(包括环信消息id)。这个问题之前一直不知道怎么复现,但是自己在平时测试的时候确实遇到了，线上用户也有反馈过类似问题，排查了很久没找到个所以然，最后使用了一个最笨最不可行的方法，就是在显示消息的时候根据消息id去重。这个去重方法还是在网上找的，压根看不懂。这样就解决了收到两条一模一样的消息后显示问题，但是问题依然存在。

解决过程:这个问题其实已经差不多一年左右了，心里知道有这个问题，但是渐渐地就放弃排查了，巧合的是最近公司在用Netty自研IM系统，在调试过程中遇到了类似的问题，大概背景就是在接收到服务器发送的消息后用eventbus发送一个事件携带了消息对象，在service中接收。突然出现服务器有消息发送过来但是service里面一直收不到事件。很难受.........eventbus流程再确认了一篇。确认没问题。于是我在service的ondestory方法里面打印了日志，然后继续调试，结果发现程序在后台运行一段时间后就自动调用ondestory了，而这个方法里面取消注册了eventbus，收不到事件就解释得通了。
思考：回到环信问题上，我看了一下ondestory里面也有取消注册eventbus代码，这样也会收不到eventbus事件，但是环信消息能正常监听???就是说我在service里面注册的环信消息监听回调还是正常走，这时候有点不相信，有点懵逼...于是我就尝试把ondestory方法里面的取消注册eventbus代码注释了，我看了下应用在后台运行一段时间后并且执行了ondestory后，eventbus也能正常接收事件。我这时候确定的是，service在程序后台运行一段时间自动执行了ondestory后，但是里面的监听消息，注册的eventbus都能正常调用。

既然这样我就对环信消息监听回调两次的问题进一步验证,原本我退出登录的时候会发送一个eventbus消息,在这里面接收到消息后会去释放资源，然后再次登录后重新启动service。难道说之前执行了ondestory的service和重新登录后的service里面的环信消息监听方法都走了？我按照这个思路验证了很多次，确实是。
 

最终解决方案:在ondestory方法中注释掉取消eventbus代码,因为程序在后台运行一段时间后会导致退出登录后service收不到evnetbus事件，导致无法释放资源，重新登录后再启动service，就会出现消息回调两次。
 

存在的疑问:为什么service在执行了ondestory方法后里面的消息监听以及eventbus事件接收还是能正常走?

 

2.在老项目中优化页面,然后页面功能引用了一个自定义view，一直提示自定义view有问题.(这个项目是接受的项目,很多老代码)

针对上述这个问题我检查了使用方法，xml文件引用的包,布局都没问题，最后我把这个自定义view类都重新替换了下，因为前段时间刚好把项目迁移到androidx担心是迁移的问题，结果还是不行。奇怪的是项目中其他页面也有引用这个自定义view，而且使用方法一模一样。排查了,纠结了很久....我就换了种方式，暂时放弃使用这个自定义view了。后面突然不知怎么地突然看了下manifest，发现调用这个自定义view的页面配置的主题加了一个style，因为优化页面我都是重新建的activity，主题也换了。于是我就再换的主题中把这个style也加上了。然后再代码中再次使用自定义view,果然问题得到解决。

得到的感触:我们在排查问题的时候，遇到一些自己认为没问题，然后排查了很久的时候，可以对比之前的或者说其他正常使用地方的不同之处，另外遇到问题不要忽略manifest这个文件，我至少遇到好几次因为这个文件配置有瑕疵导致的问题。

3.在自研Netty的时候遇到了一些问题,可能因为对这块是0基础。
 

前言：这个问题主要是联调以及排查问题处理方式

前期我们在调试的时候心跳机制一直有问题，我们有三个端,android ，ios, 后台(服务器)。调试期间连接的地址端口时不时会变，然后调试到心跳机制的时候android与后台一直有问题，就是发送了心跳消息后台收不到，但是ios那边发送心跳消息后台能正常接收。这使我立马觉得android端也就是我这边有问题，但是死活找不到是哪里的问题，后台那边他自己搞了个客户端，然后给我说心跳消息也有问题，这下我就奇了怪了，为什么ios可以....结果对比了下ios连接netty的地址端口没换成最新的，当时特么的............................................................
 

另外就是最近在测试我们用netty自研的IM，我就在本地写了个定时器，连接成功后就定时5分钟发送一个netty消息给服务器。结果发现每次一发送消息我这边就会自动断开，但是消息又是发送成功了的，开始我还以为是我们的IM服务器性能问题，我就反馈给后台了，然后我继续验证，我发现每次断开都是我发送netty消息给客户端后。于是我就把发消息代码注释了，观察不会自动断开。我就把这个现象反馈给后台了，后台就查了日志，接收到我发送的消息了，但是接收到我的消息后里面把我踢了，于是我当时就想通了，不是服务器性能问题，也不是我这边有什么Bug，是服务器那边集群方式暂不支持直接接收netty消息，这个问题后面需要都可以适配的。
 

感受：我们平时在联调的时候，不要一口咬定是android端问题，要留一份心有没有可能是ios，或者后台问题，或者说是环境问题，参数地址等没统一问题，总之在联调时我们要及时沟通，保持信息同步。这样可以避免很多不必要的排查问题时间。



总结：在经历了这几次问题排查后，感触比较深的是，不要小瞧任何一个基础知识，要重视，要花更多的时间精力去理解。不要一条路走不通还是一根筋，要全方面考虑问题，学会多种排查问题的方法，可以减少我们平时解决问题的时间，提高效率, 不要遇到问题自己闷着干，特别是联调的时候，及时沟通，保证信息同步，也可以提高处理问题效率。