Flutter 重构 QTalk

3. 架构层次较差：各端在架构设计上分层各不相同且不清晰，数据流推送方向复杂是主要的两个问题。

2. 逻辑与数据层除了个别能力（例如推送）必须使用原生代码，其余功能都 Dart 的统一实现，在维护和做新需求时工时减少约 50%。

1. provider 是最初选择的数据管理方案，由官方提供，使用的时候 model 类需要继承 ChangeNotifier，使用 Consumer 包裹需要改变的组件，一个新开发 Flutter 的同学上手很难把页面逻辑与页面 UI 分开，导致耦合严重，需要制定代码规范，而且如果 Consumer 包裹范围过大，一不小心就会影响性能表现，造成不必要的卡顿。

Fish-redux 用在逻辑层 IMMessage module 对象逻辑构建与表现层中，使 QT 原有的多方向型庞杂的数据架构变得整齐划一便于梳理，各个页面层级开发时拆解为独立的 page，扩展可以使用connector 即插即用，协作开发时降低了因为人员变动造成代码在页面层面造成混乱的可能性。

用于数据库对象与 IMMessage module 对象，数据层与逻辑层沟通。

通过事件总线来触发事件和监听事件，它是一种单例管理分发数据的模式，轻量级，全局可用，可以在没有渲染 context 对象参与的情况下传递数据，分治数据逻辑与业务。

3. ListView 改造

Flutter 现在版本的 Listview 在生成每个 item 时，不会根据 model 预取高度，而是在渲染完成以后再统计 item 高，这样就造成了几个后果。

a. ListView 不支持按 index 跳转，在 item 不等高的情况下没有简单的方式直接跳转到对应 index。

b. 跳转不在屏幕内的位置时，ListView 因为还不知道这个位置是不是在可滑动范围内，所以只能先尝试跳转，如果最终的跳转位置大于可滑动范围，就会产生弹跳。

c. scrollToEnd 方法，如果 List 末尾 item 不在屏幕内，则按照屏幕内的item平均高度估计末尾index所在位置，滑动之后，如果最终滑动停留位置不在最后一个item上，还要进行二次甚至三次跳转。

解决方式：引入 scrollable_positioned_list 控件，本质上是生成 2 个 ListView，一个 ListView 负责计算高度，一个 ListView 会真正渲染到界面上，跳转时先让第一个 List 跳转，算出最终的 index 高度，然后第二个 List 跳转精确的位置，而针对弹跳的问题，我们需要修改 ListView ，在跳转过程中发现有位移过大的情况，马上进行修正，示例代码如下：

void _jumpTo({@required int index, double offset}) {...// 使用偏移量offset var jumpOffset = 0 + offset; controller.jumpTo(jumpOffset); // 渲染之后发现溢出，进行修正 WidgetsBinding.instance.addPostFrameCallback((ts) { var offset = min(jumpOffset, controller.position.maxScrollExtent); if (controller.offset != offset) { controller.jumpTo(offset); }); }

4. 准确获取 iOS 键盘高度

iOS 键盘高度计算不准确，导致切换键盘与表情时高度不一致，使聊天界面抖动

原因：因为有些机型在 safeArea 的 bottom 高度不为 0，一般写法会直接将聊天页面写入一个 safeArea 中,而键盘弹出时 safearea 的 bottom 又会清0，导致键盘高度跳动。

解决方案：初始化 App 后，本地记录 safeArea 的bottom 高度，然后在聊天界面中去掉 safeArea 包装，使用本地记录的高度，给底部输入框增加高度避免与 iOS 导航栏重合。

5.Dart 代码无法与 Native 代码一起进行断点调试

原因：Dart 与 Native 代码分别进行编译，在运行时只能 link 一方的代码，编译器无法解析另一方产生的库。

解决方案：首先在 Xcode 或者 Android Studio中，由 Native 端启动 App，然后打开编译 Dart 代码的ide或者终端，使用 flutter attach 命令连接你的 Dart 代码到运行中的应用，这时候就可以同时调试 Native 与 Dart 与代码了。

五、 QT 桌面端遇到的问题与解决方案

1. 移动端界面的复用

之前提到过我们的数据管理方案可以使各个页面解耦，page 作为一个整体可以被其他组件复用，桌面端就是利用这种设计模式，只需要给移动端各个page 增加 connector 就可以把移动端 view 集成为一个桌面端主页面，对应的逻辑层只需要根据桌面端的特性做一部分适配，例如调用API不同，桌面端支持右键行为等。

图中 Page 与 Component 都是 fish-redux 中提供的基本逻辑与 UI 单元，它们可以任意的互相组合，它们满足了 QTalk 多端复用 UI 与逻辑的需求，也是选型的重要依据。

页面装配的过程可以由以下伪代码实现：

//各子页面适配器代码SessionListComponent.component.dartSessionListState{    ....}SessionListConnector{    //被this的属性改变之前调用，这个组件的state来自上层组件的state的属性    get    {        return HomePCPage.scState    }    //自身属性发生改变以后调用，同步上层组件的state    set    {        HomePCPage.scState = this.state;    }}//桌面端主页合成代码HomePCPage.page.dartHomePCPage{    ....    dependencies:        //重载了+号用于增加子组件属性，返回一个带有connector的组件给上层page使用        slot:SessionListConnector() + SessionListComponent(),}

2. 多 Window 创建，互传消息，调用 PC 端 native 能力

PC 端有很多原生平台相关能力 Flutter-desktop 尚未拥有，比如多窗口，录屏，web 使用，拖拽文件共享，menubar 配置等

解决方案：引入 NativeShell 框架，采用多引擎方式解决 PC 端遇到的多窗口问题，改变工程结构，在 dart 启动 main 函数之前增加一个 rust 类来管理窗口，调用 rust 中的各平台系统库来把各种语言（c++ c# oc等）写成系统api统一成 rust 类型的文件，减少平台差异性。

适配 NativeShell 中也遇到过很多问题，列举 2 个例子：

a. 打包脚本空安全报错

cargo 是 rust 包管理器，NativeShell 使用 cargo 为桌面端打包，NativeShell 默认打包脚本里不允许没有适配 null safety 的库加入工程，我们重新梳理了打包脚本并且在加入了在 Flutter 编译时非空判断，最终顺利在rust 环境里打出了 Mac 与 Windows 的包。

b. Mac 客户端打包问题

NativeShell 打包过程里，每个 Window 都会产生一个子工程，壳工程直接引用了子工程目录，最终的包里会含有大量中间产物，造成包体积特别大，我们改造了这个流程，只把子工程产生的 dll 与 framework 加入最终产物中，打出了正常大小的包。我们还与作者沟通，提出了 PR，最终这些代码和建议合并到了制作方打包工具当中.

3. PC 端多窗口同时向主窗口发送消息，造成的Dart 主 isolate 指令排队

说明这个问题之前我们先了解一下 Flutter 的事件循环原理：

Dart 应用中，有一个事件循环和 两个队列：event queue 和 microtask queue。