Flutter 多平台的项目架构讨论

目前正在用 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 多平台的同仁,能帮忙出出主意。

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


Flutter 多平台的项目架构讨论

更多关于Flutter 多平台的项目架构讨论的实战教程也可以访问 https://www.itying.com/category-92-b0.html

7 回复

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

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

更多关于Flutter 多平台的项目架构讨论的实战系列教程也可以访问 https://www.itying.com/category-92-b0.html


分享一下个人的方案,利用代码生成来实现代码级的平台切换:
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 的工具链模式。(虽然估计很多人会觉得是邪道吧)

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

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

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

回来说下我最终采用的办法,我自创了一个还算能用的方案,目前正在用这个方式重构手机版的数独游戏,同步开发桌面版(计划上 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

在这可以找到下载链接。

关于Flutter多平台的项目架构讨论,以下是我的专业见解:

Flutter作为一套由Google开发的开源UI工具包,以其跨平台一致性、高性能表现及丰富的组件和插件生态,为移动应用开发带来了全新的体验和强大的开发能力。

在Flutter多平台项目架构设计中,可借鉴MVP(Model-View-Presenter)架构模式的思想,将代码分为数据层、业务逻辑层和界面展示层。数据层负责数据的获取和存储,业务逻辑层负责处理数据和业务逻辑,界面展示层则负责将数据和业务逻辑展示给用户。这种分层设计不仅提高了代码的复用性和可维护性,还促进了团队合作开发。

同时,Flutter的跨平台开发不仅仅是技术问题,更是一种策略和方法论。开发者需根据项目的实际需求,合理地进行架构设计和策略选择,以最大化地利用Flutter的优势。例如,对于UI层,需根据不同平台的特性进行设计,利用Flutter的布局机制来适配不同屏幕尺寸和方向,为不同平台定制主题和样式,从而保持一致的用户体验。

综上所述,Flutter多平台的项目架构设计需综合考虑技术、策略和团队协作等多个方面,以构建出高质量、高性能的跨平台应用。

回到顶部