Flutter IM跨端架构设计和实现

在当前行业内跨端方案可初步归类如下图架构，在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之间通讯方式比较繁琐（需经过序列化反序列化过程）；

整个模型如下图所示：

若按官方混合架构实现Flutter应用，开启多个FlutterAcitivty/FlutterController，底层会生成多个Engine，对应会存在多个isolate，而isolate通讯类似于进程通讯（类似socket或AIDL），这里借鉴闲鱼FlutterBoost的设计理念，FlutterIM架构将多个页面的Engine共享，则内存模型就天然支持共享读取，

原理图如下：

Flutter IM 架构设计

▐  新老架构对比

如下图是一个老架构方案，其核心问题主要集中于Native逻辑抽象差，其中逻辑层面还设计到多线程并发使得问题倍增，Android/iOS/Flutter交互繁杂，开发维护成本高，核心层耦合较为严重，无插拔式概念；

考虑到历史架构的问题，演进如下新架构设计：

架构从上至下依次为业务层，分发层，逻辑层以及数据源层，数据源层来源于推送或网络请求，其封装于Native层，通过Flutter插件将消息协议数据上抛到Flutter侧的核心逻辑层，处理完成后变成Flutter DB的Enitity实体，实体中挂载一些消息协议实体；

核心逻辑层将繁杂数据扁平化打包挂载到分发层中的会话内存模型数据或消息内存模型数据，最后通过观察者模式的订阅分发到业务逻辑中；

Flutter IM重点集中改造逻辑层和分发层，将IM核心逻辑和业务层面数据模型进行封装隔离，核心逻辑层和数据库交互后将数据封装到分发层的moduleData中，通过订阅方式分发到业务层数据模型中；

此外在IM模型中DB也是重点依赖的，个人对DB数据库管理进行全面封装解，实现一种轻量级，性能佳的Flutter DB管理框架；

▐  DB存储模型

Flutter IM架构的DB存储依赖数据库插件，目前主流插件是Sqflite，其存储模型如下：

依据上图Sqflite插件的DB存储模型会有2个等待队列，一个是Flutter层同步执行队列，一个是Native层的线程执行队列，其Android实现机制是HandlerThread，因此Query/Save读写在会同一线程队列中，导致响应速度慢，容易造成DB SQL堆积，此外缺失缓存模型，于是个人定制如下改进方案：

Flutter侧通过表的主键设计查询时候会优先从Entity Cache层去获取，若缓存不存在，则通过Sqflite插件查询，同时改造Sqflite插件成支持sync/Async同步异步两种方式操作，对应到Native侧也会有同步线程队列和异步线程队列，保证数据吞吐率；

但是这里建议查询使用异步，存储使用同步更稳妥，主要怕出现多个相同的数据元model同一时间进入异步线程池中，存储先后顺序无法有效的保证；

▐  ORM数据库方案

IM架构重度依赖DB数据库，而当前业界还没有一个完备的数据库ORM管理方案，参考了Android的OrmLite/GreenDao，个人自行设计一套Flutter ORM数据库管理方案，其核心思想如下：

由于Flutter不支持反射，因此无法直接像Android的开源数据库方式操作，但可通过APT方式，将Entity和Orm Entity绑定于一身，操作OrmEntity即操作Entity，整个代码风格设计也和OrmLite极其相似，参考代码如下：

▐  IM内存数据模型

FlutterIM架构在内存数据模型主要划分为会话和消息两个颗粒度，会话内存数据模型交托于SessionModuleData，消息内存数据模型交托于MessageModuleData；

会话内存数据有一个根节点RootNotice，然后其挂载PSessionMessageNotice（这里PSessionMessageNotice是ORM映射的会话DB表模型）子节点集合；

消息内存数据会有一个MessageConatiner容器管理，其内部挂载此会话中的PMessage(PMessage是ORM映射的消息DB表模型)消息集合。

依据上一章节，PSessionMessageNotice设计了一个OrmEnitity Cache，考虑到IM中会话数是有限的，因此PSessionMessageNotice都是直接缓存到Cache中，这种做法的好处是各地去拿会话数据元时候都是缓存中同一个对象，容易保证多次重复读写的数据一致性；

而PSessionMessageNotice考虑到其数量可以无限多的特殊性，因此这里将其挂载到MessageContainer的内存管理中，在退出会话的时机会校验容器中PMessage集合的数量，适当缩容可以减少内存开销，模型如下图所示：

▐  状态管理方案

Flutter IM状态管理方案比较简单，对数据源Session/Message维度使用观察者模式的订阅分发方式实现，架构类似于EventBus模式，页面级的状态管理无论使用fish-redux，scopeModel或者provider几乎影响面不大，核心还是需保留一种插拔式抽象更重要；架构如下图：

▐  IM同步模型方案

如下是当前现状的消息同步模型，模型中存在ACCS Thread/Main Thread/Region Thread等多线程并发场景，导致易出现多线程高并发的问题；

native的推送和网络请求同步的隔离方案通过Lock的锁机制，并且通过队列降频等方式处理，流程繁琐且易出错。

整体通过Region Version Gap去判断是否有域空洞，进而执行域同步补充数据。

改进的同步模型如下，在Flutter侧天然没多线程场景，通过一种标记位的转化同步异步实现类似Handler消息队列，架构清晰简约了很多，避免锁带来的开销以及同步问题。

进展以及性能对比

▐ 针对架构层面

在FlutterIM架构中，重点将双端逻辑差异性统一成同一份Dart代码，完全磨平Android/iOS的代码差异性带来的问题，降低开发维护，测试回归，视觉验收的一半成本，极大提高研发效率；

架构上进行重构分层，实现一种解耦合，插拔式的IM架构；同时Native到Flutter侧的大量数据上抛序列化过程改造成Flutter引用传递，解决极限测试场景下的私聊卡顿问题；

▐ 针对线上舆情

补齐UT和TLog的集团日志方式做到可追踪，可排查；另外针对于很多现存的疑难杂症重点集中专项解决，比如iphone5C的架构在Flutter侧统一规划，未读红点计数等问题也在架构模型升级中修复，此外多媒体音视频发送模块进行改造升级；

▐ 性能数据对比