Windows平台Flutter桌面应用的底层模块化探索

前言

Windows应用开发有着较为丰富和多样的技术选型。C#/WPF 这种偏Native的闭源方案，目前开发人员相对比较小众了。C++/QT 的跨平台框架，C++对于GUI开发来说上手会更难。JavaScript/CEF/Electron 基于Chromium 的跨端框架，使用前端技术栈来构建桌面应用，性能会略低一些。总而言之各有所长，有一点可以确定的是，跨端能力成为了选型的重要考量。
Flutter从诞生之初起，其核心目标就是跨平台，不仅仅支持Android和iOS的移动端设备，同时包括桌面端和Web端。随着2022年2月Flutter 2.10的推出，也带来了首个支持Windows平台的稳定版本。基于Flutter的跨平台特性，移动端或Web端的Flutter应用也能够在Windows系统上运行，Windows应用开发者能够享受到Flutter开发带来的便利和生产力上的提升，同时移动端开发者也能够快速上手Windows应用开发了。

Windows平台接入

在进一步探索和预演之后，通过Flutter的能力，可以很方便地将移动端的业务模块迁移至PC端，尽可能地实现一码多端，降低业务维护成本，以此为出发点，进行了Windows平台的接入。
闲鱼App已经在Android和iOS平台上有了多年的积累，并且采用了Native和Flutter混合的技术方案，Flutter和Native相辅相成，共同组成了App的完整生态。如果想要让Flutter相关的模块在Windows平台上运行，那就需要让Windows平台补齐Android和iOS平台提供给Flutter的能力。比如通过Platform Channel提供给Flutter侧相关的Native能力，通过Platform View将Native视图嵌入到Flutter页面中，都需要在Windows平台上进行重新开发。
Windows平台通过Plugin或FFI的方式提供相关能力，需要使用C++编写相关的平台代码。如果Plugin的代码可以自闭环，即所有C++代码都可以在Plugin内编写完成，那这个Plugin可以单独抽成一个Dart库。但是如果Plugin的代码需要复用其他Plugin或者主工程的C++代码，粗暴一点就是拷贝代码，或者通过CMakeLists来控制相互之间的依赖关系，通过find_package来完成头文件和库文件的链接。一旦依赖关系比较复杂，CMakeLists就会变得臃肿，依赖关系发生变化时，也会牵一发而动全身。随着系统复杂度的提升，开发人员的增加，模块之间相互耦合在一起，单一模块的修改都会影响到所有模块。
针对上述的问题，对于底层的模块化设计，梳理了需要遵循的设计原则：

• • 单一职责原则：一个模块维护一个单一的主要功能，划清模块间的职责边界；

• • 开闭原则：模块应该对扩展开放，对修改关闭。用抽象构建框架，用实现填充细节，通过扩展实体来实现变化，避免修改代码来实现扩展。

• • 迪米特法则：最少知道原则，对依赖的模块知道的越少越好，模块除了对外暴露的方法，其他实现细节都隐藏在内部。

• • 接口隔离原则：只依赖需要的接口，模块之间提供最小的接口实现依赖关系。

• • 依赖倒置原则：依赖抽象，不依赖具体细节，模块之间需要依赖抽象的架构，而非具体的模块细节。

首先基于上述的设计原则，制定了模块化拆解的XModule方案，依据职责来划分模块，设计对外暴露的抽象接口，抽象接口保持最小化原则，完成接口实现，编译出模块的动态链接库DLL，依赖到主工程并放置到特定目录，运行时通过插件机制进行动态加载。
其次针对模块化带来的依赖管理复杂的问题，引入了vcpkg的依赖管理方案，通过清单模式便捷地管理各个模块，可以自动引入间接依赖，并且版本冲突问题也不复存在了。
结合XModule和vcpkg之后，最终形成了下面的结构，后面将详细展开。

模块化拆解XModule

上述是一个登录模块的例子，Module 作为基类，定义了模块的一些生命周期方法。LoginModule是对外公开的业务接口，