调试网络断线工作心得

在最近的工作中,遇到一个因为网络断线导致界面显示异常的问题,与这个问题纠缠两三天,最后终于解决了。解决这个问题的过程,非常有必要记录下,算是调试经验心得吧。

问题背景

当软件所处的网络状态不好导致软件断线,上层界面显示异常。

思考方法

我一开始打算是从代码入手,一步步往上看。由于现有软件有断线重连的逻辑,这块功能不是我负责的,刚开始有点蒙圈,花了些时间搞清楚断线重连的逻辑,然后就这问题发生的背景开始思索是哪个步骤出了问题,沿着这个路径,把网络断开的后续流程画成时序图,再结合上层处理界面的逻辑,增加若干调试代码,在若干次尝试中,有重现过那么几次,但大部分时候是正常的,这下,不知道怎么办了。

每当工作中遇到难啃的问题时,我有以下两个方法来缓解:

  • 就此问题已经做出的尝试以及结果,请教周围其他不忙的同事
  • 先把这个问题放一放,解决手头上不那么难的问题和需求

大多数情况下,这两种方法都会使用。通过解决手头上其他问题,可以给受挫的自己鼓气加油。向其他同事请教,我会重新讲述一片这个问题的背景和尝试解决的方法和结果,同事大部分只能指点一二,最后还是要靠自己来解决。

具体措施

这个问题是偶发问题,解决偶发问题,关键在于提高重试频率,增发问题发生概率。在这里,首要的是构造一个不稳定的网络环境,推荐使用 NetLimiter 来控制特定进程的网络状态。对于其他问题,可以尝试一些自动化工具或者Mock软件来快速构造测试压力,使得问题更加容易出现。

由于正常情况下,软件的超时检测时间以及重连间隔都比较长。在这里,为了更好的触发问题,可以降低软件的超时检测时间以及重连间隔,最好达到一断网就能马上触发断线事件。

经过调试发现,有时候在程序中加入断点,会影响通知模块的处理,有可能造成加上断点时,程序表现的正常,去掉断点,程序就不对了。针对加断点造成程序执行路径变化的问题,我也不是很清楚,在后期的调试过程中,逐渐减少断点的使用,增加调试打印,输出些关键变量。

最后方案

针对该问题的解决方案,有上层界面修改和底层修改。考虑到上层修改影响范围小,可控性较好。底层修改影响的范围大,不好把握影响范围,最后采用的修改上层的解决方案,算是质量和进度的妥协了吧。

回顾

从之前面对问题的一头雾水,逐层抽丝剥茧分析后,直到最后解决这个问题,做到最后,居然不记得之前对这个问题一无所知的心理状态,每每想到这个问题,自然而然的从最佳分析路径一路到解决方案,中间没有任何弯路,这种感觉真是奇怪。就好像,对一个事物从不理解到彻底理解后,自己就再也回不到不理解的状态。改完这个问题后,真是浑身舒畅,这感觉真舒畅。

原文地址:https://www.cnblogs.com/cherishui/p/12331933.html