Flutter 多平台的项目架构讨论

[andyzhshg]

目前正在用 flutter 做一个数独游戏，目前的目标平台是移动平台，面向 APP Store 和 Google Play 的海外用户。

因为国内各种游戏版号和备案的限制，现在上架的时候是直接剔除的国区，所以 APP 内直接集成了 Firebase 的服务和 Admob 的广告。

现在项目的构造是除了数独的逻辑部分我提炼成了一个 package 之外，所有的其他逻辑相关的代码都在一个主项目库中，主要是界面，广告，内购这些。

目前数独逻辑 package 代码是大几千行的代码量，主项目是 1 万+的代码量。

以上是前提。

我现在想把项目做一个重构，让它能够更具有灵活性，力求可以达到：

• 支持国内市场，这部分可能需要做的是将 firebase 和广告等内容用国产方案替代。
• 支持 web ，目前因为使用了 dart:io 等只有原生平台支持的库，所以并不能在 web 上跑起来。web 版的功能会有很大的阉割，主要是在官网用来试玩和引流。
• 支持桌面平台，主要是想支持 Mac App Store 和 Windows(有可能是 steam)。桌面平台的主要区别是界面的布局，以及剔除广告和收费点的微调等。

现在移动版的开发已经完成并上线了 App Store 和 Google Play ，所以在研究项目的重构方案。

我的想法是首先抽离游戏玩的部分的界面逻辑为一个 package ，然后内购广告等都抽离为相应的 package ，给不同的平台生成一个不同的主项目，在主项目中用胶水代码按需来组合这些 package 。

不过这样就导致项目过多，需要同时打开 N 个库来修改，不太方便不同的平台调试。如何最大化的提炼逻辑让胶水代码量最小也是个挑战。

不知道有没有做过 flutter 多平台的同仁，能帮忙出出主意。

后端转移动端中老年野生程序员先行谢过。

[AoEiuV020JP]

没怎么明白你的想法，flutter 跨平台处理应该主要是在 import 区分，
import 'utils_cmd.dart'
if (dart.library.js_util) 'utils_web.dart'
if (dart.library.ui) 'utils_flutter.dart';
像这样不同平台导入不同的源码文件做不同的实现，部分可以在代码用用 Platform 区分平台，

而如果是原生代码需要分情况处理，比如安卓要分国内和国外打包，这个是有专用的 productFlavors 功能支持，不同 flavor 使用不同的依赖，不同的代码，不同的工程配置，编译运行时得选一个，

[debuggerx]

分享一下个人的方案，利用代码生成来实现代码级的平台切换：
https://www.debuggerx.com/2022/04/17/conditional-compilation-using-source-gen-in-flutter-1/
https://www.debuggerx.com/2022/06/19/conditional-compilation-using-source-gen-in-flutter-2/
https://www.debuggerx.com/2023/06/20/conditional-compilation-using-source-gen-in-flutter-3/

好处是单一代码库，避免非常复杂的架构设计，且符合 flutter/dart 的工具链模式。（虽然估计很多人会觉得是邪道吧）

[AppJun]

个人弱弱地觉得，有人玩有盈利，值得弄再重构。

[andyzhshg]

@debuggerx 感谢回复，我发现仁兄的这三篇文章几天前就已经躺在我的收藏夹里了。已经粗读过一遍，感觉还是稍稍复杂，不过确实是一个很好的思路。

[debuggerx]

@andyzhshg 是的，用什么方案取决于项目规模、特性，开发者的喜好以及团队的协作流程

[andyzhshg]

回来说下我最终采用的办法，我自创了一个还算能用的方案，目前正在用这个方式重构手机版的数独游戏，同步开发桌面版（计划上 Steam 和 Mac App Store ）。

这个方案将几乎所有的代码逻辑都整合在一个大的 flutter 插件项目中，然后根据不同平台或者 App 的需求创建一个 flutter App 。这个 App 的项目只包含一些配置信息，包括是运行在什么平台，是否支持内购，采用什么广告平台，发行的渠道等等信息。

甚至，我计划把不同的 App （指的是开发中和计划开发的不同 App ，比如在站里征求过建议的 3D 数独 https://v2ex.com/t/998390 ，以后想做的杀手数独，儿童数独等等）都放在这一个杂糅的插件项目中。

这样做好处是最大化的复用了代码，包含逻辑和界面，因为不同数独无论是逻辑还是界面都是大同小异的，还捎带有一个收获，因为不同的 App 中其实已经包含了彼此的代码，所有可以实现在 A App 中试玩 B App 或者 B App 试玩 A App ，方便 App 数量上来之后交叉推广。

缺点也很明显，会导致程序包膨胀，因为重构还在进行中，但我预估代码逻辑本身不会造成太大的膨胀，需要担心的是各类资源，主要是游戏迷题包，目前还没有想好怎么处理。

目前 Hi Sudoku 已经更新到了 1.2.4 ，无论是界面还是操作都有了不少的改进，欢迎试玩。

这是以前在论坛推广的帖子： https://v2ex.com/t/992373

在这可以找到下载链接。