这两天工作需要，得把之前Flutter的工作重新拾起。
我们知道，通过命令行（flutter create）可以创建 flutter 代码，通过 flutter create -h发现 -t 的模版下面有四种模式，分别是app、module、package、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分开的。
因此，app的目标是最终产出一个apk或者ipa包的；module最终是产出一个framework，在原生工程中引入的；package是产出一个dart组件；plugin是产出一个抽象层的组件，会包含原生代码。
