宇联通 IM 在消息轰炸下程序崩溃下的优化经历

宇联通IM完成了三端（pc, android, 鸿蒙）的基本功能，就进行了消息轰炸测试。

测试目标：

   1， 消息不丢失  

   2， 消息已读正确

   3，程序稳定，功能运行流畅，不出现卡顿，pc端内存占用在2G左右。

  为控制IM不占用太多内存，对pc端内存进行控制： -Xmx1524m

测试方法：

     建一个测试群，群里面四个用户：pc用户，android用户，鸿蒙用户，测试用户。 测试用户在群里发送消息，其他用户接受消息。

     测试程序通过测试用户循环发送群消息，每隔20毫米发送一条群消息，直至发送到指定数量消息。

     界面测试要求：

     a,  只显示热点消息总数，不查看测试群里的消息，可以查看其他群消息或用户消息或其它功能。

     b，进入群里，实时查看群消息，并滑动界面查看上面消息

     c，混合操作，查看群消息后，查看其他功能，如其他群消息等

测试数据：

   1，连续发送500笔文本消息

    2，连续发送1000笔文本消息

    3， 连续发送10000笔文本消息

    4， 连续发送100000笔文本消息

测试结果：

500笔文本消息	只显示热点消息	正确显示500笔未读消息。
实时查看群消息	正确显示500笔已读消息，消息列表滑动流畅
混合操作	正确显示500笔已读消息， 但是偶尔出现未读消息数量不为0情况， 程序功能运行流畅
1000笔文本消息	只显示热点消息	正确显示1000笔未读消息。
实时查看群消息	android和鸿蒙正确显示1000笔已读消息，android和鸿蒙的消息列表运行流畅。pc端程序卡死，内存占用超过2G
混合操作	android和鸿蒙正确显示1000笔已读消息，android和鸿蒙消息列表运行流畅 pc端程序卡死，内存占用太高2G多点

 由于pc端程序内存占用超过2G，程序卡死，测试终止。分析pc内存占用太高的原因。

当进入群消息列表时，pc端业务是最复杂：1，显示群消息。2，群消息进行已读处理。3，增加热点消息数并在消息已读后减少消息热点数，4，增加总热点消息数并在消息已读后减少总消息热点数， 5，消息列表滑动。android和鸿蒙端，3,4只处理业务，不进行显示，而pc端需要联动显示。

因此第一步去掉热点消息联动展示功能，发现内存占用立刻降下来，测试1000笔数据时，1000笔消息能正常接受，正常已读，程序运行也流畅，只是在对消息列表进行频繁滑动时，内存占用还是迅速上升，滑动频率太多时，pc内存占用还是超过了2G，需要进行优化。

热点消息联动展示由于有并发操作，接受消息增加数量，消息已读减少数量，热点消息总数不一致的情况需要解决并发的问题，这个可以放到后面进行解决。

热点消息联动展示导致内存升高，分析时消息刷新机制的问题，事件机制刷新改成bind和Observable机制刷新，内存占用降了很多。频繁滑动大消息列表时，内存占用升高，分析发现是用户头像的缘故，因此增加缓存图片，使用WeakReference缓存图片，频繁滑动查看超大消息列表时，内存占用不会上升太大。

通过以上两次优化，pc端内存占用能够控制在1.5G。因此针对pc端进行了单独测试，通过测试用户向pc用户连续（每隔20毫米）发送一笔p2p消息，连续发送1000笔，5000笔， 10000笔消息时程序都能运行流畅，消息未出现丢失情况。但是连续发送100000笔消息，pc程序内存占用还是达到了2G，程序还是出现卡顿的情况。终止发送消息后，并使用Visualvm释放程序内存，内存迅速降到600M.

初步分析上面的优化不够彻底，消息组件（MessageView）太重量了（需要支持文本消息，富文本消息，附件消息，图片消息，视频消息，语音消息，组合消息， 路径消息，html消息， web消息等），需要进行大改，后续再分享。

结论：

     1， 宇联通IM在消息轰炸下，消息没有丢失，但是已读消息数量出现不一致情况。

     2，android和鸿蒙端在消息轰炸下，程序运行流畅。

     3，javafx开发的pc端在消息连续轰炸下，存在内存超过2G的情况，需要继续优化。

pc端优化后，再进行一次消息轰炸测试。