由于之前不见中的代码组成，导致很多电话聊天的命令不能够执行，比如说接通之后提示还有挂断电话之后向服务器的反馈，这些有时候时间久了就不能够执行，一开始我还以为是网络问题，但是我通过日志查看和网络没有问题，因为在出现这种故障的时候，客户端其他的内容可以获取，这说明网络是畅通的，我还怀疑是不是时间是个计数器出现问题，但是通过日志分析也是没问题的，后来我发现是我自己涉及的逻辑问题，有可能会导致一些状态下不能够再次执行下一个任务，所以我就对于这个逻辑的设计有些重新的整理了一下。

在目前测试来看，还没有出现之前的那些问题，这个问题非常的重要，因为也不能够通过后期服务器进行修改，一旦用户核心了最新的软件之后，出现问题相对幸福的话，只能要让用户更新下载，所以说在发布之前一定要自己先测试好，明天我再花点时间测试一下公告，还有删除账号的一些功能，对了我发现选手账号这个功能真的非常重要。

一会儿我再去检测一下前段时间被我删除的几个账号，有没有在重新注册，如果发现的话我直接删除，我昨天随意走访了一个已经被我删除号码的用户，我发现他有而且在这里聊天很久，通过他的平均聊天时长可以分清楚，这不是一个正常聊天的用户，他在这里潜伏着，可能是想拉拢更多的视频聊天客户，像这种人在平台里面有一天也是一种损失，所以说我直接把他删除了，也没法公告，也没有通知他，他应该自己心里有数。

虽然我在做向服务区反馈这一步的时候非常的谨慎，也采取了很多逻辑设计，但是我还是担心有一天有个用户他的电话聊天没有记录，我在问他通话时间多久的时候，他会胡乱说的，因为通过电话线的话还是有个截图的这个截图，他如果进行处理的话时间也不会够的，所以说我要保留一个证据，就是他们聊天啊，有两种方案，第1种方法呢，就是在它的用户数据上进行一些记录，当需要调取证据的时候，我让他打开这个界面，所有内容应了然这个方案呢，就是我在服务器上对每次呼叫都进行记录，按照时间顺序来排列，如果真的出现问题的话，我可以一一排查，通过关键词的筛选，我觉得第2种方法应该比较靠谱一点第2种方案服务器出现故障的话，肯定不能聊天完成还有就是如果服务器故障之后不能够顺利完成的话，到时候会以什么样的方式记录。