Flutter 初學者到底需要怎樣的Demo?

本文轉載自查看原文 2020-03-03 15:57 892 ，Android開發

Flutter，毫無疑問是今年最火的技術方向，作為最早接觸Flutter的一批開發者，從入門，到現在，我也經歷了各種階段，從入門時的無從下手，到略懂之后被各種蜜汁Widget弄的焦頭爛額，到現在可以建立起Flutter的整體知識結構，整個過程實際上是非常痛苦的，這跟Flutter的設計思想有關——一切皆組件，這雖然是一個非常好的設計思路，但是茫茫多的Widget，會讓開發者陷入泥潭無法自拔，很難建立起Flutter的知識架構。

在我的Flutter群中，經常有很多初學者在群里尋求Flutter的入門之道，雖然Flutter的官方文檔非常完善，社區里面各種Flutter的Demo也非常之多，但是，恕我直言，基本沒有一個是可以很好的幫助開發者建立Flutter知識架構的，今天，我就來分析下，初入門的Flutter修仙者究竟需要一個怎樣的Demo。

1什么是好的Demo

wiki上對demo的定義是：a demonstration of a product or technique。

說的很清楚，就是對這門技術或產品的演示，Demo是初學者或者說是初次使用者了解產品、技術的第一通道。就跟人與人見面的第一印象一樣，Demo從很大程度上決定了這個產品推廣和宣傳上的好與壞。

那么一個好的Demo究竟需要一些怎樣的特點呢？

首先，一個好的Demo需要將這門技術的使用細節和使用方式演示清楚，這里要注意的是，是演示，是將這門技術的功能展示出來，這是Demo的核心，所以它的第一個特點就是——具有演示性。

其次，初學者是通過Demo來學習如何使用這門技術，所以Demo的代碼必須簡潔、易懂，這點非常重要，對於一門新的技術來說，初學者很難快速掌握這門技術的全貌，這就導致在看Demo的時候，很難站在一個全局的角度來看，所以當代碼很復雜的時候，就很難理解其中的含義了。

這跟我們平時寫代碼一樣，對於不同類型的代碼，需要寫不同風格的代碼，舉個例子來說，對於頻繁變化的業務代碼，如果在設計的時候套用各種設計模式、各種抽象、繼承，看上去好像代碼寫的很牛掰，但是一旦這個架構無法滿足業務的拓展，就會變成噩夢，而一旦接手別人的這種代碼，那更是噩夢中的噩夢，所以對於這種代碼來說，開發者需要的是寫【易於修改的代碼】而不是炫技的代碼。

而另一方面，比如寫一個SDK，功能相對集中，業務需要相對穩定，這個時候就需要寫【架構良好的代碼】，在SDK中，開發者可以使用合適的設計模式，來優化項目的架構，讓增加SDK的拓展性和穩定性。

對於Demo來說，我們需要的是第一種代碼，即【超級簡單的代碼】，除了一些必要的工具類或者通用方法外，涉及知識點的Demo演示代碼都應該不做任何抽象，直接使用最基本的API調用來進行編寫，這樣的代碼雖然會產生一些冗余，但是極大的增加了代碼可讀性和可學習性，這才是學習Demo代碼的意義，也是Demo的另一個特性——代碼簡潔、易懂。

再其次，Demo與人一樣，好看的皮囊總是讓人更喜歡。雖然只是一個演示程序，但起碼，要能看的過去吧，不是幾個隨便的按鈕，參差不齊的排列，各種明顯的bug。

以上，我們總結了一個好的Demo應該具有的特點：

良好的演示效果
簡單明了的代碼
好看的界面設計

這些東西雖然看起來簡單，但是真要做好，實際上也是很難的。

2那些不那么好的Demo

作為一個曾經的Flutter初學者，我也看過社區中的非常多的Flutter Demo，下面就我了解的一些Demo來給大家看看，它們是否是一個好的Demo。

當然，所有的評論都是基於上面的幾點特性來的，不針對任何開發者。

下面的這些截圖都是我平時看的一些Demo中的截圖。

這幾張圖是演示了Flutter中的一些Widget的使用方法，不過看完之后，我感覺還是一臉懵逼，不知道具體是什么意思，這就完全沒有體現出演示的效果。

再看下面幾張圖：

還有這些：

雖然是個簡單演示程序，但起碼，還是設計一下吧。。。好歹文字要對齊是吧？

再來看看下面這張。

這是Google Sample里面的代碼，你可能沒看出來這是什么玩意，但你品，你細品，這些都是代碼。。。是的，它Demo里面展示的代碼，實際上就是這樣一行行拼起來的，我真的是第一次看見這么簡單粗暴的方法。

說到代碼結構，就不能不提Google的官方Demo，Flutter SDK中有很多官方提供的Demo項目，每個項目都非常具有實戰意義，但是，我想當不推薦初學者去看，主要是因為一個非常簡單的演示程序，Google可以寫的非常復雜，這不得不說Google開發者的代碼功底十分強大，但是，這也太不照顧初學者的感受了。