开始前的考虑
1. 为什么选择Flutter？
跨平台的方案一直都在，H5，RN，Week，小程序，Flutter等等这些都是跨平台可选择的技术。就像商品的价格由竞争对手决定。在这些可选的技术里面，不得不说，Flutter是目前最好的一个，没有之一。
可以说Flutter在目前的跨平台技术方案中比其他选择高出一个层次。所以，现在的决策就是：要么原生开发APP（加点H5）；要么跨平台，用Flutter开发APP。
在二选一的情况下，决策就方便多了。比如电商类的APP，用Flutter是可以的。而游戏类的，元宇宙类的（其实就是VR），更偏向用原生。
Flutter把iOS的体验拉低到了Android一个级别，并且在开发体验上按照Android，H5，iOS的顺序排列。按照这个特性，进行跨平台（Flutter）还是原生（特别是iOS）的选择就简单多了。
2. 是否要用GetX？
Flutter的Stateful Widget有点繁琐
Flutter的路由管理确实麻烦
Flutter把UI和数据逻辑混杂在一起，确实不大好（一大坨的感觉）
就像iOS中的AFNetworking，GetX在Flutter的中热度上升很快
GetX的侵入性很强，融合度很高。所以重要性比一般的第三方差价要高一个层次。用不用，在开始之前就要想好。
本人的选择：用GetX，就像在iOS开发中会用AFNetworking一样。
在2018年左右接触Flutter，对于其原理和前景是看好的，但是蛋疼的开发体验，鸡肋一样的路由跳转等等各种不爽的感觉，还是偏向原生iOS开发。
现在跟随团队体验了一把Flutter开发电商APP。感觉有了GetX，当然还有Dio，flutter_screenutil，cached_network_image等一大堆优秀第三方框架。目前的感觉是：不再排斥跨平台技术，用Flutter开发的体验还是可接受的。（当然最舒服的开发体验还是iOS原生，没有之一）
3. 是否要用GetX CLI？
GetX额外提供了一套命令模式的CLI，从创建APP到打包，都有对应的脚手架命令可用
如果深度使用GetX，全盘接受GetX的框架规范，那么使用这套CLI是非常好的。你不需要思考，不需要做选择，按照它推荐的模板进行开发就可以了。只要一定时间的适应，应该还不错。
还是那句话，是否深度使用GetX，由其他竞争的第三方插件决定。比如网络部分，显然Dio做得更好。
就像iOS架构中的VIPER，角色分得太多，对于复杂页面还说得过去，但是对于数量更多的简单页面，就感觉不好了。命名一句话的事，为什么还要创建好几个文件，分好几个角色？
本人的选择： 不用GetX CLI
4. GetX如何取舍？
GetX就像一个大工具箱，包罗万象，如果不想全盘接受，那么就要懂得取舍。
- 状态管理：
选用： GetBuilder + update() 模式
弃用： .obs + Obx 模式
响应式路由管理，甚至是响应式编程，函数式编程，看起来很美，但是用起来并不是很习惯。
- 路由
选用： 命名路由
弃用： 简单路由
简单的Get.to()其实挺好的，只是Get.toNamed()相比之下并没有增加复杂度
在iOS开发中，曾经的蘑菇街route就想实现命名路由，现在有现成的，当然要用起来
- 依赖管理
选用： 直接使用Get.put() 和Get.find()
弃用： Binding类
一句话的事，非要多出一个类，没必要；GetxController本来就是分离出来的逻辑部分，占内存并不多，懒加载大多数情况收益不高；
- GetxController 事件监听：Workers
这个在GetxController的onInit()周期方法中添加观察者，被观察的变量需要添加.obs后缀。
这个在iOS开发中对应的功能是KVO，对比起来实现还是很优雅的，需要的时候可以采用。
这个功能只有响应式编程范式一种，没得选，用起来方便就好。
View的基类
选用： StatelessWidget
弃用： GetView、GetWidget，StatefulWidget国际化
目前的跨境电商APP，英语为默认，中文备选，其他语言也是有可能需要的。
只是加一个.tr后缀，使用起来已经很方便了。当然选用。切换语言集成Translations类就行了，方案很优雅。主题Theme
白天模式和夜晚模式的切换，现在的需求也比较强烈。当然选用。三大对话框
Get.snackbar();
Get.dialog();
Get.bottomSheet();
这三种都抛弃了烦人context，并且样式一般都需要自定义，所以推荐使用。工具类GetUtils
这个还是很有用的；
比如，检查邮件，电话号码，等等还是非常赞的。
只是最好不要直接使用，而是包一层，分散到自己项目的工具类中去。GetConnect
这个就是所谓的xxxProvider角色的基类，这是网络访问部分。Dio做得更好，不选用。GetMiddleware()
看名字是中间件，具体的作用不清楚，不选用。有用的API
Get.arguments
Get.previousRoute
GetPlatform.isAndroid
GetPlatform.isIOS
Get.height
Get.width
Get.context
Get.contextOverlay
这些都是非常有用的工具，可以分散到各个工具类中，当然也可以根据需要直接使用。GetxService
感觉跟Android中的Service组件有点像，需求的场景不多。用到的时候再研究，暂时先不考虑。参考文章：
新建APP
方案1：flutter的命令，一行命令就搞定了。
方案2：Android Studio的New Flutter Project... 对话框
方案3：VSCode的新建命令
本人选择： 方案2，有图形化的IDE可以选择，优先考虑。
只要决定好项目名称和包名以及文件位置，其他的都根据向导选择默认的就可以了。
原生的语言选择了Swift和kotlin，这是目前的主流，原生代码也很少会涉及。
- 脚手架自动生成的文件，和直接用Flutter命令差不多
- 项目视图，目前只有一个main.dart文件，是默认的计数器程序
- 接下来，用真机或者模拟器跑一下，看到默认的模拟器程序可用就可以了。iOS的，可能需要打开Runner.workspace之类的，解决一下证书之类的问题，就当做是普通的iOS项目处理就可以了。
接入GetX
GetX也是一个普通的第三方插件，所以上pub.dev按照说明接入就可以了。
由于GetX地位特殊，所以第一个引入。
GetX的侵入性比较强，需要修改main.dart。将默认的MaterialApp修改为GetMaterialApp
默认生成的main.dart中main()方法以及MyApp都足够简单，可以不修改。
MyHomePage就是默认的技术器StatefulWidget，这个放在main中是不合适的，可以新建一个文件my_home_page.dart，将MyHomePage相关内容移出来，让main.dart保持简单。
修改后的样子：只要默认的计数器程序仍然能跑起来，说明GetX已经成功引入，并且能够使用了。
装IDE插件。GetX热度很高，IDE的相关辅助插件很多。根据使用习惯，选择一款适合自己的，这样能带来方便。
本人选择： 结合前面的GetX的功能取舍，网名“小呆呆666”写的一款插件比较适合，目前在用。AndroidStudio是可以的，但是VSCode没有。不过这个插件主要是用来生成文件夹和文件，其他的VSCode中其他的插件也是可以用的。
参考文章
GetX代码生成IDEA插件，超详细功能讲解（透过现象看本质）
文件夹规划
脚手架工程lib文件夹下只有main.dart一个文件，文件夹如何规划，每个人都有自己的想法，只要自己满意就好，没有必要强求。参考文章中就有例子工程，都有可取之处。
lib下的文件夹命名规范遵循Linux的小写加下划线的模式，这个最好遵守一下。
routes : 路由，命名路由需要，并且把所有页面都集中一个地方定义，也是好的。
modules：模块，里面是一些页面，需要用到插件来生成模板
utils: 工具类，这里封装一些工具，想缓存，图片之类的
components：组件，一些公用的组件。
services：网络接口Api。几乎每个页面都离不开网络，特别重要，单独列出来。
themes：主题，白天和暗夜模式的切换，换肤等等
langs：多语言
configs：一些常数定义，信息配置等等
models：模型定义。这个可以跟页面，也可以单独列在这里。网络和页面都要用到。
以上这些是主动规划的文件夹。在实际使用中并不会这么理想。有些插件会自动生成一些文件夹或者文件，直接就在lib目录之下。
还有一些无法归类的文件，那么就有可能在增加几个顶级文件夹。这些都可以到时候再调整。
- 参考文章
