開始前的考慮
1. 為什么選擇Flutter？
跨平臺的方案一直都在，H5，RN，Week，小程序，F(xiàn)lutter等等這些都是跨平臺可選擇的技術(shù)。就像商品的價(jià)格由競爭對手決定。在這些可選的技術(shù)里面，不得不說，F(xiàn)lutter是目前最好的一個(gè)，沒有之一。
可以說Flutter在目前的跨平臺技術(shù)方案中比其他選擇高出一個(gè)層次。所以，現(xiàn)在的決策就是：要么原生開發(fā)APP（加點(diǎn)H5）；要么跨平臺，用Flutter開發(fā)APP。
在二選一的情況下，決策就方便多了。比如電商類的APP，用Flutter是可以的。而游戲類的，元宇宙類的（其實(shí)就是VR），更偏向用原生。
Flutter把iOS的體驗(yàn)拉低到了Android一個(gè)級別，并且在開發(fā)體驗(yàn)上按照Android，H5，iOS的順序排列。按照這個(gè)特性，進(jìn)行跨平臺（Flutter）還是原生（特別是iOS）的選擇就簡單多了。
2. 是否要用GetX？
Flutter的Stateful Widget有點(diǎn)繁瑣
Flutter的路由管理確實(shí)麻煩
Flutter把UI和數(shù)據(jù)邏輯混雜在一起，確實(shí)不大好（一大坨的感覺）
就像iOS中的AFNetworking，GetX在Flutter的中熱度上升很快
GetX的侵入性很強(qiáng)，融合度很高。所以重要性比一般的第三方差價(jià)要高一個(gè)層次。用不用，在開始之前就要想好。
本人的選擇：用GetX，就像在iOS開發(fā)中會用AFNetworking一樣。
在2018年左右接觸Flutter，對于其原理和前景是看好的，但是蛋疼的開發(fā)體驗(yàn)，雞肋一樣的路由跳轉(zhuǎn)等等各種不爽的感覺，還是偏向原生iOS開發(fā)。
現(xiàn)在跟隨團(tuán)隊(duì)體驗(yàn)了一把Flutter開發(fā)電商APP。感覺有了GetX，當(dāng)然還有Dio，flutter_screenutil，cached_network_image等一大堆優(yōu)秀第三方框架。目前的感覺是：不再排斥跨平臺技術(shù)，用Flutter開發(fā)的體驗(yàn)還是可接受的。（當(dāng)然最舒服的開發(fā)體驗(yàn)還是iOS原生，沒有之一）
3. 是否要用GetX CLI？
GetX額外提供了一套命令模式的CLI，從創(chuàng)建APP到打包，都有對應(yīng)的腳手架命令可用
如果深度使用GetX，全盤接受GetX的框架規(guī)范，那么使用這套CLI是非常好的。你不需要思考，不需要做選擇，按照它推薦的模板進(jìn)行開發(fā)就可以了。只要一定時(shí)間的適應(yīng)，應(yīng)該還不錯(cuò)。
還是那句話，是否深度使用GetX，由其他競爭的第三方插件決定。比如網(wǎng)絡(luò)部分，顯然Dio做得更好。
就像iOS架構(gòu)中的VIPER，角色分得太多，對于復(fù)雜頁面還說得過去，但是對于數(shù)量更多的簡單頁面，就感覺不好了。命名一句話的事，為什么還要創(chuàng)建好幾個(gè)文件，分好幾個(gè)角色？
本人的選擇： 不用GetX CLI
4. GetX如何取舍？
GetX就像一個(gè)大工具箱，包羅萬象，如果不想全盤接受，那么就要懂得取舍。
- 狀態(tài)管理：
選用： GetBuilder + update() 模式
棄用： .obs + Obx 模式
響應(yīng)式路由管理，甚至是響應(yīng)式編程，函數(shù)式編程，看起來很美，但是用起來并不是很習(xí)慣。
- 路由
選用： 命名路由
棄用： 簡單路由
簡單的Get.to()其實(shí)挺好的，只是Get.toNamed()相比之下并沒有增加復(fù)雜度
在iOS開發(fā)中，曾經(jīng)的蘑菇街route就想實(shí)現(xiàn)命名路由，現(xiàn)在有現(xiàn)成的，當(dāng)然要用起來
- 依賴管理
選用： 直接使用Get.put() 和Get.find()
棄用： Binding類
一句話的事，非要多出一個(gè)類，沒必要；GetxController本來就是分離出來的邏輯部分，占內(nèi)存并不多，懶加載大多數(shù)情況收益不高；
- GetxController 事件監(jiān)聽：Workers
這個(gè)在GetxController的onInit()周期方法中添加觀察者，被觀察的變量需要添加.obs后綴。
這個(gè)在iOS開發(fā)中對應(yīng)的功能是KVO，對比起來實(shí)現(xiàn)還是很優(yōu)雅的，需要的時(shí)候可以采用。
這個(gè)功能只有響應(yīng)式編程范式一種，沒得選，用起來方便就好。
View的基類
選用： StatelessWidget
棄用： GetView、GetWidget，StatefulWidget國際化
目前的跨境電商APP，英語為默認(rèn)，中文備選，其他語言也是有可能需要的。
只是加一個(gè).tr后綴，使用起來已經(jīng)很方便了。當(dāng)然選用。切換語言集成Translations類就行了，方案很優(yōu)雅。主題Theme
白天模式和夜晚模式的切換，現(xiàn)在的需求也比較強(qiáng)烈。當(dāng)然選用。三大對話框
Get.snackbar();
Get.dialog();
Get.bottomSheet();
這三種都拋棄了煩人context，并且樣式一般都需要自定義，所以推薦使用。工具類GetUtils
這個(gè)還是很有用的；
比如，檢查郵件，電話號碼，等等還是非常贊的。
只是最好不要直接使用，而是包一層，分散到自己項(xiàng)目的工具類中去。GetConnect
這個(gè)就是所謂的xxxProvider角色的基類，這是網(wǎng)絡(luò)訪問部分。Dio做得更好，不選用。GetMiddleware()
看名字是中間件，具體的作用不清楚，不選用。有用的API
Get.arguments
Get.previousRoute
GetPlatform.isAndroid
GetPlatform.isIOS
Get.height
Get.width
Get.context
Get.contextOverlay
這些都是非常有用的工具，可以分散到各個(gè)工具類中，當(dāng)然也可以根據(jù)需要直接使用。GetxService
感覺跟Android中的Service組件有點(diǎn)像，需求的場景不多。用到的時(shí)候再研究，暫時(shí)先不考慮。參考文章：
Flutter應(yīng)用框架搭建(一)GetX集成及使用詳解
新建APP
方案1：flutter的命令，一行命令就搞定了。
方案2：Android Studio的New Flutter Project... 對話框
方案3：VSCode的新建命令
本人選擇： 方案2，有圖形化的IDE可以選擇，優(yōu)先考慮。
只要決定好項(xiàng)目名稱和包名以及文件位置，其他的都根據(jù)向?qū)нx擇默認(rèn)的就可以了。
原生的語言選擇了Swift和kotlin，這是目前的主流，原生代碼也很少會涉及。
- 腳手架自動生成的文件，和直接用Flutter命令差不多
- 項(xiàng)目視圖，目前只有一個(gè)main.dart文件，是默認(rèn)的計(jì)數(shù)器程序
- 接下來，用真機(jī)或者模擬器跑一下，看到默認(rèn)的模擬器程序可用就可以了。iOS的，可能需要打開Runner.workspace之類的，解決一下證書之類的問題，就當(dāng)做是普通的iOS項(xiàng)目處理就可以了。
接入GetX
GetX也是一個(gè)普通的第三方插件，所以上pub.dev按照說明接入就可以了。
由于GetX地位特殊，所以第一個(gè)引入。
GetX的侵入性比較強(qiáng)，需要修改main.dart。將默認(rèn)的MaterialApp修改為GetMaterialApp
默認(rèn)生成的main.dart中main()方法以及MyApp都足夠簡單，可以不修改。
MyHomePage就是默認(rèn)的技術(shù)器StatefulWidget，這個(gè)放在main中是不合適的，可以新建一個(gè)文件my_home_page.dart，將MyHomePage相關(guān)內(nèi)容移出來，讓main.dart保持簡單。
修改后的樣子：只要默認(rèn)的計(jì)數(shù)器程序仍然能跑起來，說明GetX已經(jīng)成功引入，并且能夠使用了。
裝IDE插件。GetX熱度很高，IDE的相關(guān)輔助插件很多。根據(jù)使用習(xí)慣，選擇一款適合自己的，這樣能帶來方便。
本人選擇： 結(jié)合前面的GetX的功能取舍，網(wǎng)名“小呆呆666”寫的一款插件比較適合，目前在用。AndroidStudio是可以的，但是VSCode沒有。不過這個(gè)插件主要是用來生成文件夾和文件，其他的VSCode中其他的插件也是可以用的。
參考文章
GetX代碼生成IDEA插件，超詳細(xì)功能講解（透過現(xiàn)象看本質(zhì)）
文件夾規(guī)劃
腳手架工程lib文件夾下只有main.dart一個(gè)文件，文件夾如何規(guī)劃，每個(gè)人都有自己的想法，只要自己滿意就好，沒有必要強(qiáng)求。參考文章中就有例子工程，都有可取之處。
lib下的文件夾命名規(guī)范遵循Linux的小寫加下劃線的模式，這個(gè)最好遵守一下。
routes : 路由，命名路由需要，并且把所有頁面都集中一個(gè)地方定義，也是好的。
modules：模塊，里面是一些頁面，需要用到插件來生成模板
utils: 工具類，這里封裝一些工具，想緩存，圖片之類的
components：組件，一些公用的組件。
services：網(wǎng)絡(luò)接口Api。幾乎每個(gè)頁面都離不開網(wǎng)絡(luò)，特別重要，單獨(dú)列出來。
themes：主題，白天和暗夜模式的切換，換膚等等
langs：多語言
configs：一些常數(shù)定義，信息配置等等
models：模型定義。這個(gè)可以跟頁面，也可以單獨(dú)列在這里。網(wǎng)絡(luò)和頁面都要用到。
以上這些是主動規(guī)劃的文件夾。在實(shí)際使用中并不會這么理想。有些插件會自動生成一些文件夾或者文件，直接就在lib目錄之下。
還有一些無法歸類的文件，那么就有可能在增加幾個(gè)頂級文件夾。這些都可以到時(shí)候再調(diào)整。
- 參考文章
