Flutter的四种Build模式(app/module/package/plugin)

这两天工作需要,得把之前Flutter的工作重新拾起。

我们知道,通过命令行(flutter create)可以创建 flutter 代码,通过 flutter create -h发现 -t 的模版下面有四种模式,分别是app、module、package、plugin

看文本解释只能知道 "什么场景用什么刀”,但每种刀背后的 “材质” 才是重点,要知道 “为什么” 这么用。

flutter create -h

网上的介绍大多是翻译了一下这段文字,没有解释过多,我特意 分别创建了一遍,对比了差异,如果有疏漏,欢迎反馈,及时改正~

先对比目录,再对比差异文件内容

flutter create -t app flutter_app


flutter create -t module flutter_module


flutter create -t package flutter_package


flutter create -t plugin flutter_plugin

我们把app和module视为一组(A),package和plugin视为一组(C),由外及内的进行对比。

相比A组,C组的一级目录下多了 CHANGELOG.md 和 LICENSE,也就是说,C组的角色一般是“可以被发布到开源组件库”的 “组件”,A则不是。

组内对比1,package中缺少ios和android目录,也就是说,它的默认定位是“纯正的flutter组件”,只包含dart代码。plugin则偏向于“抽象组件”——基于平台特性的抽象层,例如与平台相关的 camera、权限、定位等差异较大的功能模块。

组内对比2,module中多了一个Config文件目录,这个目录里区分了debug和release的配置,方便在Xcode里匹配不同build模式。换句话说,module的功能里考虑到了调试模式,而app中则没有。另外一点,app的Generated.xcconfig中比app的文件中多了一个叫FLUTTER_FRAMEWORK_DIR的变量,这是flutter engine的真实目录。

在app和module的ios工程文件夹中没有找到podfile文件,我们以flutter_boost为例,在example的podfile中找到,这个变量是用来引入Flutter这个pod的,目的是将Flutter engine以pod的形式引入工程。而module中并不需要,因为他只是个组件,在开发的demo中需要这样做,但build的时候,是要跟flutter engine分开的。


Generated.xcconfig

因此,app的目标是最终产出一个apk或者ipa包的;module最终是产出一个framework,在原生工程中引入的;package是产出一个dart组件;plugin是产出一个抽象层的组件,会包含原生代码。