[已回复] 上线部署后发现的一些问题处理及求助

1 服务端正常，已关闭服务端日志。cpu,内存，宽带等各项数据查看正常，群聊大于100人+时消息接收比较慢。该问题不排除网络原因引起的。
2 当手机切换到其他的app时，再切换rainbow，某个群聊消息较多时，点开时有直接程序崩溃的现象。再打开会有历史未读的消息查看不到了。这个问题比较严重。正在分析消息加载的机制的问题。
3 IOS开发一个的问题，鉴于测试和线上环境的不一致。服务器的多次更换是必然发生的。当前定义的在default.h文件中的预处理变量，更换为域名的话，有dns解析延迟的问题。写死IP的话，更换IP就要上架一次这样太麻烦了。安卓版本已更换为httpdns的形式，不知IOS版本我要如何修改？

引用：xiaohao180731 发表于 2018-09-17 12:04
1 延迟这个问题，正在查看原因。
2 接入的已经准备做了。崩溃后消息丢失的问题后续我再发出来一起分析下 ...

1、延迟的问题一定要精确地查查；
2、先抓到奔溃原因，分析分析；
3、你这做法不是常态，而且ios自有它的不便之处，一般来说在这个阶段，用Ios企业账号就不需要提交审核了，整个方案fix后再提交app store。

引用：JackJiang 发表于 2018-09-17 11:50
1、延迟10分钟太夸张了，这一定是另有原因：所以你一定要按照我说的，把JProfile用熟练，找出这延迟10分 ...

1 延迟这个问题，正在查看原因。
2 接入的已经准备做了。崩溃后消息丢失的问题后续我再发出来一起分析下。我觉得群消息应该只加载最新的一屏的消息即可，比如20条。当下拉时再往上读取历史记录。这样保证不会由于消息记录过多而崩溃。微信和QQ都这样做的。
3 由于机器的网络问题，上线试行期肯定需要更换网络较好且各地区用户反馈较稳定的服务器。在稳定运行之后当然不会更换了。只是IOS相对麻烦，写死了IP的话，要更换就要发布审核一次。效率非常慢。

引用：xiaohao180731 发表于 2018-09-17 11:25
1 当前是我们自己的服务器，我们自己使用时部分消息甚至延迟10多分钟才接收到。
2 由于我们自己使用不会 ...

1、延迟10分钟太夸张了，这一定是另有原因：所以你一定要按照我说的，把JProfile用熟练，找出这延迟10分钟到底发生在哪一个环节、哪一个方法、那个行代码，JProfile完全可以做到，你想办法找出这个延迟的具体所在，凭感觉是做不好的。一个完整的im系统涉及的环节太多，所以要保证每一个环节都尽在掌握中。  如果你没有用过JProfile，那趁这个机会一定要用熟它。

2、你在你的客户端接入一个第3方bug统计工具，比如腾讯的bugly或友盟；

3、httpdns我没有用过，但关键原因是，你生产环境下为什么需要经常换ip地址？这是做何考虑的？

引用：JackJiang 发表于 2018-09-17 11:14
1、如果你确认关闭Log了的话，你需要再深入调试看看你服务端的性能瓶颈在哪里：
建议你使用JProfile详细 ...

1 当前是我们自己的服务器，我们自己使用时部分消息甚至延迟10多分钟才接收到。
2 由于我们自己使用不会出现崩溃现象，是由用户反应的，所以这个崩溃信息比较难抓出来，几乎不可能。
3 嗯，已经查看完了。但是在该项目中，我需要如何修改，如果取消预处理的define变量，修改为全局变量，那样需要改的地方较多，比较容易出现问题。这种情况下，我要如何更换为httpdns的方式。

1、如果你确认关闭Log了的话，你需要再深入调试看看你服务端的性能瓶颈在哪里：
建议你使用JProfile详细检测一条群聊消息（人数比较多的情况下），它从服务端收到的发出全过程中，哪个环节耗时最多，然后有针对性的来看代码并针对你的业务来优化（JProfile是可以看到每个方法的调用及耗时的，这是个神器）。这一点你务必要深入研究、

2、如果崩溃很容易复现，你就在logcat下把奔溃信息抓出来，我也可帮你看看。

3、移动端的DNS问题，在有的运营商网络下，确实比较慢，这是所有人都会面临的问题，这个可以参考一个这篇文章《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》，注意深入阅读第4节。