最近公司項目開發已經到了尾聲，我這邊也計劃用Flutter重新寫一遍公司項目，作為公司新技術引入學習，這項目我計劃全部用Flutter自帶的小部件來開發，不用任何第三方項目，這樣做的目的是為了學習新技術，熟悉原汁原味的Flutter自帶小部件，當然這個項目也是我們公司所有前端小夥伴和技術開發人員都能來參與進來，也希望大家能夠積極參與進來一起學習新技術，為公司存儲新技術。
我公司前端現狀
作為一個北上廣回重慶家鄉發展的前端工程師，來分析一下我現在公司前端技術現狀，前端技術原本就是一個雜而亂、多而繁的技術。特別是二三線城市技術人員的技術參差不齊，而且技術態度也很凌亂，在這樣的一個大環境下想完全一下子改善是很難的，我們公司目前前端分佈情況也很緊張，面對業務也很繁瑣而多，技術也是想到哪兒用到哪兒，APP分為Android，IOS開發，有後臺WEB開發，同時配備了H5混合APP開發，而且還有小程序也是H5來分擔，在任務繁瑣的眼前，每個開發人員在積極完成交代的任務後，基本無過多時間來學習新的項目，每次的迭代都是為了完成工期而無任何架構代碼質量可言，作為公司有自己產品來講，對技術人員的要求還是很高的，不光是要完成任務，而且還要保證代碼質量，空閒還要進行代碼重構是非常重要的，如果直接下達重構代碼任務是很難進行的，代碼沒有任何BUG前讓開發人員動代碼是很有牴觸心理的，所以我的安排就是先從人員技術培訓開發，後續我這邊會安排更多的培訓來讓大家明白代碼質量對於一個有自己產品的公司來講是非常重要的。讓大家明白我們不是在完成任務，我們每一句代碼對產品以後能不能走的更遠是非常重要的。
接下來安排
最近大家也知道，我更新的頻率沒有以前多了，是因為我這邊最近事情有點多，公司這邊有一些人事變動，自己對2020年也做了一些規劃，但是我沒有忘記我還有一個頭條號，沒有忘記我還要上來更新文章，因為我還有一堆支持我的粉絲。
接下來我這邊會安排定期更新一些Flutter文章，都是原汁原味的Flutter原生API搭建的技術文章,[不忘初心,方得始終],做事情只有不忘記自己最初持守的信念，到最後就一定能獲得成功。
Flutter版本的APP底部導航欄選擇
底部導航欄大家應該見過很多很多了，手機上的APP用這樣的導航方式已經很正常了，最開始也有過很多其他的嘗試方式，比如側滑欄來導航的，生命力最強的導航方式就是底部樣式是最久的了，直接打開Flutter官網API，可以很清楚的查看到有如下幾個API：
- CupertinoTabScaffold
- CupertinoTabView
- CupertinoTabBar
- BottomNavigationBar
這幾個導航小部件有什麼區別嗎？怎麼選擇了？
Flutter CupertinoTabScaffold 實現iOS應用程序的選項卡式的根佈局與結構。一個在底部放置標籤欄，標籤欄之間或後面放置內容的腳手架。
CupertinoTabView具有其自己的導航器狀態和歷史記錄的單個選項卡視圖。一個典型的選項卡視圖，用作CupertinoTabScaffold 中每個選項卡的內容，可以將多個具有並行導航狀態和歷史記錄的選項卡共存。
CupertinoTabBar iOS樣式的底部導航選項卡欄。使用BottomNavigationBarItem顯示多個選項卡，其中一個選項卡處於活動狀態，默認情況下第一個選項卡。
BottomNavigationBar顯示在應用程序底部的材質小部件，用於在少量視圖（通常在三到五個之間）中選擇。
看上面的介紹，其中有幾個是IOS樣式風格，然後就是Android樣式風格的導航樣式，一般作為底部導航選擇我們用的比較多的就是「BottomNavigationBar」這個部件了，底部導航一般在3到5個之間，所以我們選擇它再合適不過了。
BottomNavigationBar導航部件用法
底部導航欄通常與Scaffold結合使用，我們先看下 BottomNavigationBar 組件的構造函數：
BottomNavigationBar
BottomNavigationBarItem構造函數如下
完成效果圖：
總結：
源碼就不拿出來了，雖然是公司新技術學習項目，但是整個圖標都是用的公司項目圖標，所有的網絡請求都是用的公司API。暫時分享到這裡。歡迎大家點贊，轉發，關注，評論。
閱讀更多 技術剛剛好 的文章
