帶你重新“玩轉”Flutter
Flutter作為一項已經逐漸進入規模化實踐的技術，它的價值已經初步獲得認可，後續應該有不錯的生命力。作為較早期的Flutter實踐者，我一直在思考Flutter的技術價值以及如何釋放這些價值，本篇嘗試從一個新的視角去結構化的梳理Flutter的技術價值並做對應的應用分析。這裡不會涉及到Flutter具體領域的技術點，但是會結合我們團隊過去的探索實踐，在技術使用策略的層面做一些總結，希望能幫助到小夥伴們在開發實踐中思考提煉，抬頭看路，仰望星空，找到未來的創新方向。前端有些啥問題
要溯源Flutter, 就得從前端說起了。這裡的前端是相對於後端的概念，大概泛指透過圖形介面實現使用者互動的終端技術。這個領域一直很有活力，伴隨著網際網路一路走來，很多新思路和新技術都有點眼花繚亂：上古的MVC已經不大提起了，老一輩的MVP,MVVM也逐漸暗淡，新一輩的Vue,Angular,React方興未艾，還有Redux, Mobx, Hooks推波助瀾。這些技術都像是一個個有感情的小生命，有的熱情，有的文藝，有的高冷，十分熱鬧。也許你會想：它們都在說個啥？它們都想解決一個啥問題？節點，連線和網路
網際網路是這一切存在的大背景，網際網路有3個大要素：節點，連線和網路拓撲結構。每一個要素的進化都會給前端帶來升級和變革：從PC網際網路到移動網際網路再到物聯網是節點在進化；充滿想象的5G時代是連線在進化；從中心化到分散式是網路拓撲結構在進化。前端的使命是讓使用者(人)高效的嵌入到網路之中，讓人和裝置融合為一個有生命的網路“節點”。
PS：網路模型可以適配到前端的很多場景，裡面的“節點”可以代指手機裝置，應用程式，程式，頁面，甚至元件。節點與前端技術
前端技術是使用者(人)與裝置的粘合劑，讓二者有機的構成一個網路節點。我嘗試剖析下前端技術在節點中的形態：首先它需要提供介面給使用者，並響應使用者的互動；需要管理和遠端節點的通訊，交換資訊；還需要管理當前節點的資訊狀態；最後，為了方便的嵌入到網路中，節點需要一個友好的“外觀”，就是生命週期。生命週期描述了節點的誕生，消亡，所擁有的權益，和所承擔的責任。
PS：這個分治模型也具有一定的通用性，可以適用在應用程式，頁面，或者元件。前端要解決的問題
當然，前端技術作為一種軟體技術，在日常的工程開發中也需要基礎的構建部署支撐。那麼，綜合前面的討論，前端要解決的基礎要素問題有：這裡面生命週期管理是一個比較“隱形”的問題，它其實就是構建“外觀”描述，也就是“元件化”。這些基礎要素問題的結構關係大概是：
這幾個基礎要素問題的解決往往不能孤立的進行，在設計解決方案的時候需要彼此配合。前端領域的技術方案通常都會合並解決其中的幾個問題，比如：React解決介面管理和生命週期；Vue解決了介面管理,狀態管理,和生命週期；Redux專注解決狀態管理；GraphQL，BFF,Serverless解決遠端通訊；webpack解決構建部署等等...那麼，Flutter解決了什麼問題？或者，Flutter可以解決哪些問題呢？Flutter都有些啥
有趣的技術方案應該有自己旗幟鮮明的個性，做架構設計往往是遇到了獨特的問題或者發現了更好的工具。因此，使用Flutter做解決方案的時候，應該梳理下Flutter都帶來了些什麼。一般來說，主要有Dart語言，Dart執行時(VM)，GUI框架，和相關的開發構建工具。Dart語言
Dart語言不好說有多優秀，總的來說是一門工程“友好”的現代語言。也許感覺平淡無奇，但官方在介紹Flutter的時候，還略有“驕傲”的展示了它的包容性：它能較為原生的支援宣告式，過程式，物件導向，函式式，和響應式等業務場景，它給技術方案實現提供了很自由的正規化空間，這是值得發掘和嘗試的。結合我自己的實踐，有幾個點值得一說：•支援類似“協程”處理（async/await/yield）：Dart是單執行緒的，但是支援非同步。這一點需要在使用中去體會，不展開說，理解深了以後，可能對很多問題都有新解法。•提供Stream：當你要進階學習Flutter的時候，很多地方能見到它。它能做流式資料處理，函式組合，傳輸控制，屬於進階必知必會。•mixin特性：這是很有用的特性，尤其在架構設計方面。它提供了新的組合方式，在做功能組合的時候，Dart可以使用物件注入，或者高階函式，或者mixin。Dart-Runtime / VM
當你引入Flutter，你就有一個Dart-Runtime啦。當然，它本來的意義是支援Flutter執行的，然而就像JS的V8引擎一樣，本來是用來支援H5頁面的，後面的腦洞就越開越大了。當然Dart沒有JS的動態能力(特殊的場合也可以)，但它是跨端的，而且aot效能有保障，發掘空間較大，還能同時覆蓋幾乎所有場景，手機app開發，PC的構建部署，服務端，甚至serverless執行時。Flutter應用開發框架
Flutter帶來了高效能的跨平臺GUI Framework，這沒啥可說的，用就是了！但如果已經有了自己的開發生態，捨棄成本太大，又想“借用”下Flutter的技術優勢，大概有幾種方案：•語言轉換，基本上就是把其他語言的佈局結果交給Flutter Framework。•中層Framework介入，選擇一棵樹介入，這樣對接面會小一些。•底層Framework替換，整個替換掉Flutter Framework, 直接使用底層的Engine。
當然，還有一種方式就是混合開發了，需要實現混合棧管理，而且在1.22版本以後，Flutter升級了Navigator元件，提供了Navigator 2.0，這對混合開發是一個利好。開發構建工具
值得一提的是HotReload，誰用誰知道。熱部署不僅介面開發需要，這是個通用需求，如果在服務端透過Dart實現一個，也是極好的。Flutter的構建工具並無太多亮點，而且因為Dart語言在Flutter中不支援反射(產物太大，增加包體積)，業務架構實現上很多需要依賴於編譯時處理的技術，這對構建系統的能力有較大依賴的。換一個角度，因為這一領域尚沒有成熟方案，加上Dart的工程“友好”，可能實現由一種語言來統一前端開發，後端開發，以及構建和部署，真做到了會很酷！Flutter可以有些啥玩法
討論前端要解決的幾個基礎要素問題，也討論了Flutter帶來的技術工具，結合這兩點，看看利用Flutter都能做些啥。遠端通訊
“遠端通訊”是一個做了抽象的概念，具體形式會根據“節點”的定義不同而不同。可以是指物理裝置之間的通訊(手機與伺服器)，也可以指模組之間(頁面與另一個頁面)的通訊，還可以指元件之間(兩個StatefulWidget之間)的通訊。因為在Flutter中“一切皆是Widget”，所以簡化的看，Flutter裡面大概分為兩種情形：面向伺服器的通訊和元件(Widget)之間的通訊。•面向伺服器的通訊：這方面有傳統的Restful，GraphQL,還有興起於“雲原生”概念的Serverless。藉助於Dart的能力延伸，Dart-Runtime可以成為Serverless的可選容器，那麼前後兩端都可以使用Dart來開發，如果再用Dart補足中間的構建部署pipeline，那麼可以搭建出一個很“雲原生”概念的應用程式開發流(dev flow):
Flutter的跨端能力結合雲原生的彈性部署，前後端的實現可以放到一起，它們之間的呼叫也變得簡單自然，有理由相信這會是一個高效的開發方式。閒魚已經做了前期的探索，並在業務中嘗試落地。此外，GraphQL與Flutter也是值得嘗試的組合，GraphQL和React正規化在理念上很對味口，但是我們並沒有嘗試過。•元件之間的通訊：Flutter提供的基礎業務程式設計元件是StatefulWidget和StatelessWidget,它們是按樹形結構來組織的，並提供了InheritedWidget來支援它們之間的通訊，在通訊方式可以總結出3種：Notify型：通知/監聽模式，Flutter提供了ValueNotifier和ChangeNotifier, 簡單方便，適用於輕量資訊通訊，參見Provider
Invoke型：介面呼叫模式，類似輕量RPC方式，在Flutter的應用架構設計中竟然很少見到。它確實有些重，但是有前面的模式沒有的優勢：它是雙向的。
Transmission型：資料傳輸模式，Dart提供了Stream來支援這種模式。使用靈活，擴充套件方便，幾乎是框架設計必備，參見BLoC。
狀態管理
狀態管理是個大問題，它由兩個元素構成：狀態和處理狀態的邏輯。在程式碼實現上，狀態就是資料，邏輯就是函式。當它們變得複雜的時候，解決的辦法其實就是拆分，然後再合理的組合。我嘗試從狀態和邏輯的拆分選擇上來列舉所有可能的解法：•狀態不拆，拆分邏輯： 這種做法的特點全域性共用一個狀態結構體物件，所有狀態全部放在這個物件中，叫做“統一狀態管理”。只有一個資料物件，就消除了各個處理邏輯之間資訊共享問題，邏輯內部沒有狀態，變得非常的純粹（比如純函式來實現），再將邏輯以合適的方式組合成一個整體，實現上界限清晰，簡單優雅，代表的方案就是Redux。
如果採用這種設計方案，推薦使用函式式風格來實現，這倒不是因為函式式“更高效”，“更優雅”之類的，而是它與函式式的思路十分的契合，在實現上更容易把握住思路。用物件導向來實現也並沒有問題，最後的效果取決於你所面臨的工程環境和使用者。
這種狀態管理好處顯而易見：一處狀態發生改變，不需要到處發事件同步。但是如果用在複雜大業務上面(比如一個有數十個頁面流程的業務產品），狀態必定是複雜的，狀態結構體必然是龐大的。Redux的方式很好的管理了邏輯，如果要管理一個統一龐大的狀態資料，也許記憶體級別的SQL是個不錯的主意，GraphQL-Client給了我們啟發，我們也正在嘗試實踐。
•邏輯不拆，拆分狀態： 我把這種叫做“步進狀態管理”，實際上這類似於狀態機模式。但如果要真正使用，狀態必須是有限的，而且不能經常變動。這與網際網路持續多變的業務需求實際是不符合的，所以採用這種方式的設計幾乎沒有。但在一些很嚴肅的業務場景中，比如交易流程，一旦定下來就不容易變動。這時，步進狀態管理就很合適了。
•同時拆分邏輯和狀態： 這是容易想到方案，在更細的粒度上，將狀態和它對應的處理邏輯拆分打包，變成更小的域（scope），然後統一協調這些子域（subModel），我把這種叫做“組合狀態管理”。進一步的方案可以統一定義subModel的基礎行為，然後引入排程器來協調管理它們，subModel之間還可以共享上下文來共享資訊等等。這種思路形式自由，可以採用的實現方式很多，經典的物件導向當然不在話下，scoped_model採用的就是這種思路，scoped_model實現的簡單易懂，同時能力也比較有限。當然也可以採用函式式的方式，高階函式+閉包也能很好的實現，但是圈內沒有看到有相關的設計實現。還有一點，Dart提供了Mixin特性，透過這個特性，可以得到更簡潔的實現方案。比如，可以沉澱很多特定的Model，然後透過with選擇組合到業務Model中來(參考Flutter Framework中WidgetsBinding的實現)。目前flutter-hook在做這方面的探索，flutter-hook看起來有些迷惑，其核心就是利用了Dart的Mixin特性來組合狀態。
介面管理
Flutter使用了響應式UI，目的就是讓業務開發減少介面的管理工作，只要提供好頁面“描述”就行了。雖然Flutter內建了類似Virtual Dom的Diff機制，但是，做這個Diff也是要費效能的，如果我們在框架設計上能內建的把Diff工作提前到資料層，是不是可以提升效能呢？我們嘗試了幾種方法，受制於在Flutter中Dart不能反射，效果不理想，也許後續生態完善之後會有好的解法。在UI開發中，Flutter一直有一個隱隱的聲音就是動態化，官方好像是“忽略”的，這裡也不談了。生命週期
Flutter透過StatefulWidget給業務開發提供了基礎的生命週期管理。元件生命週期的設計是隨著業務場景的不同而不同的，我自己的理解，設計生命週期要從兩點出發：一是元件從誕生到消亡的時間線，二是元件在場景中所擁有的權益和所承擔的責任。生命週期的擴充套件原點是StatefulWidget,因業務場景不同而擴充套件不同，很難展開講。 舉個例子，如果使用原生Flutter開發(或者叫純Flutter開發)，StatefulWidget所提供的生命週期是足夠的。但是如果要做混合開發，引入混合棧後，顯然就不夠用了。這時候就需要提供新的元件來擴充套件生命週期，更好的滿足混合場景的開發。當時我在做混合棧的時候並沒有能理解到這一點。結語
本篇從分析前端開發需要面對的幾個基礎核心問題入手，結合Flutter帶來的技術工具，嘗試結構化的分析Flutter在業務開發中可能的技術選擇和探索方向。當然，技術同學既要仰望星空，還需要腳下看路，對於Flutter開發中的熱點技術問題，歡迎關注閒魚技術公眾號的其他文章，或者加入我們，和閒魚一起做一點不一樣的技術！
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69900359/viewspace-2749460/，如需轉載，請註明出處，否則將追究法律責任。
