Flutter IM跨端架构设计和实现

3. 性能测试略差：核心数据源存储Native内存，需经Flutter Plugin将数据源序列化上抛Flutter侧，在大批量数据源情况下性能表现较差；

从舆情层面总结闲鱼IM当前架构的主要问题如下：

1. 定位问题困难：线上舆情反馈千奇百怪，测试始终无法复现相关场景，因此很多时候只能靠现象猜测本质；

2. 疑难杂症较多：架构不稳定性造成出现的问题反复出现，当前疑难杂症主要包括未读红点计数，iPhone5C低端机器架构，以及多媒体发送等多个问题；

3. 问题差异性大：Android和iOS两端逻辑代码差异大，包括现存埋点逻辑都不尽相同，因此排查问题根源时候双端都会有不同问题根因，解决问题方案也不相同；

业界跨端方案

为解决当前IM痛点，闲鱼今年特起关于IM架构升级项目，重在解决客户端中双端一致性痛点，初步设想方案就是实现跨端统一的Android/iOS逻辑架构；

在当前行业内跨端方案可初步归类如下图架构，在GUI层面的跨端方案有Weex,ReactNative,H5,Uni-APP等，其内存模型大多需要通过桥接到Native模式存储；

在逻辑层面的跨端方案大致有C/C++等与虚拟机无关语言实现跨端，当然汇编语言也可行；

此外有两个独立于上述体系之外的架构就是Flutter和KMM（谷歌基于Kotlin实现类似Flutter架构），其中Flutter运行特定DartVM，将内存数据挂载其自身的isolate中；

考虑闲鱼是Flutter的前沿探索者，方案上优先使用Flutter；

然而Flutter的isolate更像一个进程的概念(底层实现非使用进程模式)，相比Android，同一进程场景中，Android的Dalvik虚拟机多个线程运行共享一个内存Heap，而DartVM的Isolate运行隔离各自的Heap，因而isolate之间通讯方式比较繁琐（需经过序列化反序列化过程）；

整个模型如下图所示：