宇联通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端优化后，再进行一次消息轰炸测试。