為了開始學一個東西前，我習慣性的會先問自己為什么？到底為什么我要開始學Flutter呢？

不確定你是為什么開始學習Flutter，我的直接原因的話是因為我們的項目可能在后面會考慮用Flutter重構，作為目前最新的跨平臺方案，它有著它的魅力所在，雖然目前正式版本還沒出，但是它的beta版本的效果，讓大家都眼前一亮。不過從另外一方面來看，我一直在嘗試學習一個跨平臺的技術方案，來幫我打通整個前端技術，之前一直考慮學習web或者RN、weex，現在來看感覺從Flutter開始也可能是一個好的開始，因為Flutter的dart語言跟java的一些語法相似，可以幫你對Android有一些了解，同時Android Studio可以作為Flutter的IDE，畢竟Google自家的，可以幫我了解很多安卓相關的知識，同時dart就是為了干掉JS而出生的，所以更有必要看看這個比JS效率更高的語言是怎么個樣子了。

Fuchsia

有一個特別值得注意的點，今年也就是18年Google在紐約的開發者大會上，全部會議過程中都沒有再提及Android，而是主要聊了ChromeOS和Fuchsia，而Fushsia的UI層就是由Flutter構建的，主要開發語言也是Flutter的開發語言Dart。所以能看到一種潛在的趨勢。

Fuchsia 項目的知名參與者包括 Travis Geiselbrecht 和 Brian Swetland。

早在久遠的上個世紀九十時代中期，當時的蘋果公司因自家的操作系統無法及時推出，正尋找替代品。當時有兩個理想的候選產品分別是 Be 公司的多媒體操作系統BeOS，以及被蘋果公司掃地出門的喬布斯開辦的 NeXT 公司的產品 NeXTSTEP。后來由于 Be 公司要價太高等原因，蘋果公司收購了NeXT公司重新獲得喬布斯繼而研發出后來大放異彩的 OSX，而 Be 公司則由于經營不善在2001年黯然被Palm公司收購。

能被蘋果公司列為收購目標的 BeOS 實力自然不弱，而上面這兩位小哥，就曾在 Be 公司做操作系統開發。由于 BeOS 在當時來說設計非常先進，公司關門后很多工程師和愛好者覺得可惜，所以繼承BeOS的設計重新實現了一個開源系統名字叫 Haiku，Haiku 使用的內核叫做 NewOS。自然地 —— NewOS 的發起人和主力開發就是這倆哥們。

可能倆人對極度精簡的產品比較偏愛，又或者是覺得 NewOS 內核的設計還太過厚重，總之，2008 年倆人又針對嵌入式設備設計了一個極其輕巧的內核 littlekernel（簡稱：lk）。

一晃快20年過去，隨著所供職公司的關停并轉，他們又分別在Danger、Palm、Android、Apple、Google等巨頭公司工作過。Brian Swetland 最近的一份工作是在谷歌任高級軟件工程師，負責管理 Linux 內核開發相關事務。幾天前，他在 github 上公布了 Fuchsia，用到的內核叫做 Magenta，正是基于他們的 lk 內核項目擴展功能而來。

可以看出來，項目負責人絕對是經驗豐富的老司機了。

對比各個階段的跨平臺技術

從宏觀上來看，移動互聯網興起也才10年不到的時間，很多人朋友開玩笑說iOS沒人要了，Android沒人要了，在我看來其實調侃更多一些，本質上這還是一個新興的平臺，從最早期的Native開發持續了1到2年之后，大家都在為了提高效率努力去嘗試各種跨平臺的方法。我剛開始接觸Flutter的第一秒鐘就問了我自己一個問題，Flutter到底和之前的方案有什么本質上的不一樣？一個一個來看之前方案的原理，自然就會理解了。

1.NativeApp階段

NativeApp階段.png

這個階段是最初戰場，基本上iOS、Android、網頁需要3端共同開發，維護自己的原生部分。很自然的暴露出來的問題就是效率問題，雖然保證了各端的穩定性，但是時間成本又是一個問題。

2.WebApp階段

webApp.png

這個階段大家嘗試了讓APP做殼Web做核的方式，一時間各種說法都出來了，說Web要統一3端了，不過是理論分析罷了，都低估了性能的瓶頸問題，大量用戶體驗的問題反饋了出來，大家又回到了第一戰場。

3.RN、weex階段

RN&WEEX.png

當開發者認識到Web 的繪制問題是性能的瓶頸問題時，果斷的采取了通過原聲繪制的方式來實現。這樣大大的解決了性能問題。FaceBook的RN和阿里的Weex都應運而生，它們的原理都相似，只是上層采用的語言不通，中間采用的橋有差異。這類方式在兩三年之間，從最初的看似美好已經變成了各家公司已經開始放棄RN退回原生了，原因就在于橋的成本太高，當涉及到復雜跨橋的調用的時候，就會出現性能問題，更嚴重的問題是我最初沒有想到的，那就是即使忽略性能問題的情況下開發成本降低了，但是維護成本缺提高了很多。RN的整體思想是一處學習到處使用，所以在Android和iOS的使用方式上還是有差異的，而且在開發插件的時候，還是需要開發android iOS兩套插件，能達到像H5一樣，一處編寫，到處運行還是有很大的差異的，所以除了android和ios團隊外還需要一個團隊維護RN，RN架構的維護成本要比android和iOS的開發的難度高多了。所以成本比原來還高，還有很多Rn架構本身沒有辦法結局的問題，對于小團隊來說簡直就是噩夢

4.Flutter階段

Flutter.png

和React Native一樣，Flutter也提供響應式的視圖，Flutter采用不同的方法避免由JavaScript橋接器引起的性能問題，即用名為Dart的程序語言來編譯。Dart是用預編譯的方式編譯多個平臺的原生代碼，這允許Flutter直接與平臺通信，而不需要通過執行上下文切換的JavaScript橋接器。編譯為原生代碼也可以加快應用程序的啟動時間。實際上，Flutter是唯一提供響應式視圖而不需要JavaScript橋接器的移動SDK。

從4個階段的區別已經大概有個基本的了解了，自然會發現從理論上Flutter是"最美"的.但是我自己也特別有疑問，幾乎每個階段大家都會有革命性的感覺，但是在時間的慢慢證明下，很多東西都是有存在的問題的。就我目前對Flutter的了解，我也看到了很多目前階段要面臨的問題。目前來看，大前端目前也還沒有"銀彈"。

從理論和實際上分析Flutter的優勢和需要面對的問題

優勢:

1.最大的優勢直接與平臺通信，從這點讓Flutter的性能天花板變成了和Native一樣

2.熱重載調試功能，Flutter的開發階段支持這個炫酷的功能，能特別方便的用IDE進行調試，可以不用每次都重新加載，這個是我這段時間寫Demo的時候給我眼前一亮的功能，特別好用。修改了代碼之后，可以直接熱加載在上次調試的基礎上，只變動你剛修改的地方。

3.徹底的UI統一一套。你不用再聽設計師驗收的時候說為什么兩端不一樣了。（這個不能說是絕對的好處，也影響不是特別大，因為也許很多安卓的用戶也不喜歡iOS的界面呢，暫且放進來吧，從效率的角度來分析）

4.Google親兒子，能保證平臺的穩定和后續的質量。

5.RN的性能問題被越來越多的平臺重視，也都開始進入重新選擇階段

一些需要面對的問題：

1.之前我看bestswifter提出來的問題是Flutter在git上的issue只增不減，當時看到的issue數量是3848，我目前來看已經到4122了。而反觀RN的issue還是維持在600左右，這也能反映出來目前Flutter還非常年輕，還有很多問題需要解決。

2.Flutter目前還在beta，正式版本還沒出，暫且把這個放到劣勢里面，還有很多不確定性。不過也正因為不確定性，它也有更多的可能性。

3.無法熱更新，從目前的beta版本來看，開發環境是JIT模式做動態化，但是release版本是AOT模式的，不支持動態化。不過在Flutter的issue里面有發現該團隊已經注意到這個問題，并且分析了理論上熱更新的可能性，也許會在正式版本發布這個功能也說不準。

4.包大小問題，因為需要把Flutter的庫給放到項目里，所以一定是會增加包的大小了，只是多少的問題。因為安卓原生架構里面包含一些Flutter用到的庫，所以相對小一些。iOS的包就會大一些。對于一些小廠來說可能影響不是很大，但是對于大廠來說，確實都有包大小限制。

5.因為Flutter用的是Dart語言，所以也是有學習梯度的，對于iOS開發來說可能相對安卓更陡峭一些,因為dart跟java有些地方很類似所以相對簡單一些。不過在這一周來看，我作為一個iOS開發來看，其實還好，萬變不離其宗，都是OOP，本質上都一樣。這個劣勢也能看成自己的一種挑戰吧，劣勢等級要看你的決心了。

6.生態問題。整個Flutter還是處于非常年輕的狀態，雖然Flutter的中文文檔非常多，非常詳細，但是走和跑是兩回事，確實你可以根據Google的官方文檔把環境都給搞出來，但是真正到實際開發中你會面對大量問題，到時候是否有一個強大的生態讓你去尋找答案，尋找可行的方案。所以這也是一個很重要的問題，畢竟你在快速的業務壓力下，是很難容許你去造輪子的，也要看公司給你的資源和空間。當然很多人會說愿意用業余時間去做。這是看上去很美系列，很考驗自律能力。

7.如果不是新項目呢？想中間集成一部分Flutter做功能該怎么辦呢？這又是一個復雜的問題，后續的文章會講解這個問題。

8.如果是新項目呢？是的，你可以從新搭建項目了，看上去很愉快。不過也有很長的過渡期，你同時可能還是需要原生iOS開發和安卓開發分散出來一部分精力去跟Flutter開發工程師做對接。當然這是一個始終都要面對的問題，也是不能忽視的問題。

最后

寫到現在，我發現我好想寫的弊端比優勢多，好吧，這些都是我客觀分析的點，也不能完全當作弊端，是我們對任何架構都可能需要面對的問題，只不過Flutter還太年輕，讓沒有接觸的同學都害怕了，怕沒有人幫你解決你遇到的問題，其實不要怕，沒有體驗過確實都沒有資格完全否定和完全肯定一個東西，所以我也會深入Flutter之后再對它進行更深的評價，后續我會記錄下來我的學習過程，給你做一個參考，希望能幫助到你，如果我遇到了難以解決的問題也希望你能給我提供幫助。當然也可能不夠全面，后續還會補充，不過Flutter本身的原理就值得我們去探索嘗試一下了，未來也許不是Flutter的，但Flutter一定是往前走了一步，而這一步讓我們都可能更接近了答案。

本頁內容由塔燈網絡科技有限公司通過網絡收集編輯所得，所有資料僅供用戶學習參考，本站不擁有所有權，如您認為本網頁中由涉嫌抄襲的內容，請及時與我們聯系，并提供相關證據，工作人員會在5工作日內聯系您，一經查實，本站立刻刪除侵權內容。本文鏈接:http://www.webpost.com.cn/18198.html