Flutter 多平台的项目架构讨论

2023-11-15 11:58:07 +08:00
 andyzhshg

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

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

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

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

以上是前提。

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

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

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

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

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

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

1721 次点击
所在节点    Flutter
6 条回复
AoEiuV020JP
2023-11-15 12:27:53 +08:00
没怎么明白你的想法,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
2023-11-15 12:33:24 +08:00
分享一下个人的方案,利用代码生成来实现代码级的平台切换:
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
2023-11-15 12:38:12 +08:00
个人弱弱地觉得,有人玩有盈利,值得弄再重构。
andyzhshg
2023-11-15 12:43:09 +08:00
@debuggerx 感谢回复,我发现仁兄的这三篇文章几天前就已经躺在我的收藏夹里了。已经粗读过一遍,感觉还是稍稍复杂,不过确实是一个很好的思路。
debuggerx
2023-11-15 12:52:23 +08:00
@andyzhshg 是的,用什么方案取决于项目规模、特性,开发者的喜好以及团队的协作流程
andyzhshg
350 天前
回来说下我最终采用的办法,我自创了一个还算能用的方案,目前正在用这个方式重构手机版的数独游戏,同步开发桌面版(计划上 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

在这可以找到下载链接。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/992067

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX