跨平臺技術演進及Flutter未來 [復制鏈接]

2019-11-8 14:54
安卓Coder 閱讀:421 評論:0 贊:0
Tag:  跨平臺 Flutter

一、移動跨平臺技術演進

1. 引言

移動互聯網發展十余年,伴隨著 Android、iOS 等智能手機的不斷普及,移動端已逐步取代 PC 端,成為兵家必爭之地。正所謂“得移動端者得天下”,移動端已成為互聯網領域最大的流量分發入口,一大批互聯網公司正是在這大趨勢下崛起。

2. 為什么需要跨平臺技術

伴隨著移動互聯網的高速發展,公司間競爭越來越激烈,如何將好想法快速落地、快速試錯,成為備受關注的問題。提升研發效率、縮短研發周期,保障產品快速試錯并能快速迭代新功能,讓新產品新功能以最快的速度同時抵達 Android、iOS 等多端用戶。

眾所周知,Android 應用采用 Java 或 Kotlin 編寫,iOS 應用采用 Objective-C 或 Swift 編寫,Web 端采用 HTML /CSS/JavaScript 編寫。當需要開發支持多端的應用,每一端都需要獨立研發、測試,一直到上線,以及后續的維護工作,工作量成倍增漲,勢必延長研發周期。

為了解決多端獨立開發的問題,跨平臺技術便應運而生,各大互聯網公司為此都投入大量人力,于是出現了各種跨平臺技術框架,面對移動領域的跨平臺技術方案的層出不窮,又該如何做技術選型呢?

3. 移動端技術選型

作為移動端的跨端技術方案,所關注無外乎以下這4個方面:研發效率、動態性、多端一致性、性能體驗。

跨平臺技術演進及Flutter未來
  1. 研發效率:最大化代碼復用,減少多端差異的適配工作量,降低開發成本,專注業務開發,實現“write once,run everywhere”的終極目標。效率提升是貫穿整個業務的生命周期線,即便業務上線后,可持續降低后續的維護成本,加快新feature的迭代速度,這是一個持續的效率收益。當然,這里不得不說,任何一門新技術在開發啟動學習階段會有一些成本,但上手后的收益是長期的。

  2. 動態化:突破渠道的更新頻率,可快速迭代新功能,這一點不僅是跨平臺技術的訴求,也是Native技術必備的殺手锏,這也是評估跨端技術的一個重要考核點。

  3. 多端一致性:好產品在多端UI設計上,往往是整體風格統一,所以業務方采用原生各自獨立開發完成后,還需額外花不少時間來修改UI以保證多端一致性;可見,各端獨立實現開發方式,帶來的效率滯后,不僅僅是Android和iOS各開發一份代碼的工作量,還有雙端UI的一致性對齊的工作。

  4. 性能體驗:一般地,跨端技術方案擁有以上多重優勢,但在性能方面比原生流暢更差些。犧牲部分體驗換來效率提升,這一點也是情理之中,試想一下,跨平臺技術方案同時兼得這4點,那么原生技術恐怕已退出歷史舞臺,早已是跨平臺技術的天下,所以往往跨平臺技術的性能優劣便成為核心指標。

4. 跨平臺技術劃分

對研發效率和體驗的不斷追逐,移動端的跨平臺技術方框架層出不窮,然則天下武功眾多,萬變不離其宗,從其核心本質來劃分,可大致分為以下三大類:

跨平臺技術演進及Flutter未來
  1. Web技術:主要依賴于WebView的技術,功能支持受限,性能體驗很差,比如PhoneGap、Cordova、小程序

  2. 原生渲染:使用JavaScript作為編程語言,通過中間層轉化為原生控件來渲染UI界面,比如React Native、Weex。

  3. 自渲染技術:自行實現一套渲染框架,可通過調用skia等方式完成自渲染,而不依賴于原生控件,比如Flutter、Unity。

5. 跨平臺技術演進

跨平臺技術,一直以來是每一個有追求的開發者所追逐的夢想,同時也是守舊者的噩夢,跨平臺的多端一體化方案勢必顛覆現有的原生各端獨立開發模式,接下來列舉眾多的跨平臺技術中最為關鍵的幾個技術方案的演進階段。

跨平臺技術演進及Flutter未來

從上圖可以看出,技術演進過程大致分以下三個階段:

  • 第一階段,采用WebView技術繪制界面的Hybrid混合開發技術,通過JS Bridge 將系統部分能力暴露給 JS 調用,其缺點是性能較差,功能受限,擴展性差,不適合交互復雜的場景,比如Cordova。

  • 第二階段,針對WebView界面性能等問題,于是繪制交還原生渲染,僅僅通過JS調用原生控件,相比WebView技術性能體驗更好,這是目前絕大部分跨平臺框架的設計思路,比如React Native、Weex。另外,最近小程序也比較火,第一和第二階段的融合,依然采用WebView作為渲染容器,通過限制Web技術棧的子集,規范化組件使用,并逐步引入原生控件代表WebView渲染,以提升性能。

  • 第三階段,雖然通過橋接技術使用原生控件解決了功能受限問題,提升性能體驗,但相比原生體驗差距還是比較大,以及處理平臺差異性非常耗費人力。于是Flutter提出自帶渲染引擎的解決方案,盡可能減少不同平臺間的差異性, 同時媲美原生的高性能體驗,因此業界對 Flutter有著極高的關注度。

面對現有的如此多跨平臺方案,為何當下最火的跨平臺技術是Flutter,有哪些優勢呢?

RN、Weex均使用JavaScript作為編程語言,JavaScript作為前端開發語言,在跨平臺開發中可謂大放異彩,利用web技術不僅能開發出網站,也可以開發手機端web應用和移動端應用程序,似有一統三界(Android、iOS、Web)的趨勢,這就是大家常說的“大前端”時代。這些技術方案流暢度不太好,平臺一致性較差,至今還沒能大面積取代原生開發。

Flutter是以Dart語言編寫,開發體驗更接近客戶端,從大家使用反饋來看也是如此,Flutter開發環境這一套的流程對于前端開發來說并不太友好。Flutter的定位同樣是多端一體化,但是以客戶端為首,先磨平Android和iOS雙端開發體驗,再逐步向Web端滲透,從Flutter規劃的Roadmap也能看出,Flutter for web目前仍處于預覽版,Flutter客戶端方向都已經如火如荼上線了不少應用。

在此之前,大家常說“大前端”,對于Flutter技術,在筆者看來稱之為“大移動端”更貼切,Flutter的UI框架優先支持客戶端(Android/iOS)應用的同時,然后再適配Web端。移動互聯網時代,不少公司都制定“移動優先”的戰略,甚至只開發移動端,沒有Web端。移動互聯網的時代造就“大移動端”,Flutter作為一款能做到媲美原生的高性能跨平臺技術方案,或許一統天下。

在跨平臺技術領域,只要挑戰在,技術就不會停滯,伴隨著技術不斷演進與革新,終將走向美好。

6. Flutter技術優勢

Flutter是徹底的跨平臺方案,既沒有采用WebView,也沒有采用JS橋接原生控件,而是自行實現一套UI框架,在引擎底層通過Skia渲染到屏幕。對于UI之外所需要使用的移動設備自身提供的服務,比如相機、定位、屏幕觸摸等,則采用Platform Channels跟原生系統通信的方式來實現。

對于Flutter優勢,回到前面講到移動端技術選型的4要素,研發效率、動態性、多端一致性、性能體驗,分別對應下面這一組詞語。

跨平臺技術演進及Flutter未來

高效率:采用dart語言編寫代碼,雖然剛開始上手需要點時間,但熟練后效率比較高。一套代碼適用多個平臺(Android、iOS、Web),以及高效的Hot Reload能快速輔助調試;

動態化:2017年3月蘋果下發警告郵件,禁止JSPatch等 iOS App熱更新方案,從此iOS動態化成為一個不宜公開討論的話題。同樣地,Flutter引擎在某一個官方版本對動態化做過一些嘗試,但后續基于風險考慮移除,當然并沒有阻礙大家對技術的探索,這里不方便展開討論;

高一致性:實現UI像素級的控制,Flutter渲染引擎依靠跨平臺Skia圖形庫來實現,僅依賴系統圖形繪制相關的接口,比如未來Android會支持vulkan,iOS會支持metal,這些都是通過skia封裝調用。可最大程度上保證不同平臺的體驗一致性,見下圖所示。

跨平臺技術演進及Flutter未來

高性能:渲染性能優于現有的各種跨平臺框架,可媲美原生性能的跨平臺技術方案,Dart代碼執行效率比JS高,通過AOT編譯成平臺原生代碼,渲染采用自渲染skia方案,既不需要JS Bridge橋接,也不需要Art虛擬機參與。再從渲染原理來看看Flutter的高性能的底氣在哪里。

圖解:

  • Android原生框架,通過調用Java Framework層,再調用到skia來渲染界面;

  • 其他跨平臺方案(如RN),通過JSBridge中間層來將JS寫的APP轉換成相應的原生渲染邏輯,可見比Native代碼增加了更多邏輯,性能遜色差于原生框架;

  • Flutter框架,APP通過調用Dart Framework層,再直接調用到skia來渲染界面,并沒有經過原生Framework過程,可見其渲染性能并不會弱于Native技術,這是一個性能上限很高的跨平臺技術。

當然,不得不說目前的Flutter確實不夠盡善盡美,會存在一些不夠盡善盡美之處,比如生態不夠健全,包體積問題,但其該方案的上限比較高,想象空間比較大,相信更多開發者參與進來,經過更多打磨,未來會做得更好。

7. 業界發展近況

2017年5月Google I/O大會正式對外公布Flutter,到2018年12月發布Flutter1.0,引發全球大量的開發者和企業開始研究Flutter。StackOverflow 2019年的全球開發者文件調查中,Flutter被評選為最受開發者歡迎的框架之一,超過了TensorFlow和Node.js。

跨平臺技術演進及Flutter未來

目前,全球越來越多的公司已經在大家耳熟能詳的知名APP中使用Flutter技術并落地,尤其國內知名互聯網公司對Flutter投入度很大,社區也是非常活躍。

跨平臺技術演進及Flutter未來

8. Flutter未來趨勢

目前Flutter主要在移動Android/iOS跨雙端,Flutter 的愿景是成為一個多端運行的 UI 框架,能夠支持不僅僅是移動端,還包括Web、桌面、甚至嵌入式設備。在2019 Google I/O 開發者大會上推出的使用 Flutter 開發 Web 應用的框架,同年9月發布Flutter 1.9,并將Flutter web合入Flutter主倉庫。

跨平臺技術演進及Flutter未來

從架構圖看,Flutter采用同一個Dart Framework層來統一Flutter C++引擎和Web引擎,最終可以運行在Android,iOS,Browser上,從Flutter引擎代碼不難看出Flutter也是支持Fuchsia操作系統。

《 Android技術架構演進與未來 》文中已介紹過,Fuchsia是Google內部正在開發的一款新的操作系統,采用Flutter作為系統默認的UI框架,也就是說Flutter天然支持Fuchsia,這無疑讓Flutter在眾多的跨平臺方案更有優勢。

從Fuchsia技術架構來看,內核層zircon的基礎LK是專為嵌入式應用中小型系統設計的內核,代碼簡潔,適合嵌入式設備和高性能設備,比如IOT、移動可穿戴設備等,目前這些領域還沒有標準化級別的壟斷者。以及在框架層中有著語音交互、云端以及智能化等模塊,由此筆者揣測未來Fuchsia率先應用在音控等智能嵌入式設備。

跨平臺技術演進及Flutter未來

目前大家普遍比較看好的未來兩個技術就是5G和IoT時代。對于5G的需求,很大程度上是因為移動互聯網發展到“IoT時代”的階段。這個發展階段,全球上網設備的數量可能會達到500億個。隨著5G+IOT時代的到來,現在大家比較關注的Flutter包大小也同樣不再是一個問題,或許Flutter技術的生命期比客戶端更長,或許Fuchsia正在馳騁IOT疆場,你所掌握的Flutter技術棧可以無縫遷移,一次彎道超車的機會。

到此,介紹完跨平臺技術演進以及Flutter的優勢。看到這,相信你可能對Flutter技術有一定興趣,為了能讓大家快速了解Flutter內部原理而不枯燥,本文不放任何的源碼,通過一系列圖來幫大家從整體架構來快速理解Flutter。

二、Flutter引擎架構

1. Flutter技術架構

先來看看Flutter整體的技術架構,分為四層,從上之下依次是Dart APP,Dart Framework, C++ Engine,Platform。

跨平臺技術演進及Flutter未來

Flutter架構最核心的便是Framework(框架)和Engine(引擎):

  • Flutter Framework層:用Dart編寫,封裝整個Flutter架構的核心功能,包括Widget、動畫、繪制、手勢等功能,有Material(Android風格UI)和Cupertino(iOS風格)的UI界面, 可構建Widget控件以及實現UI布局。

  • Flutter Engine層:用C++編寫,用于高質量移動應用的輕量級運行時環境,實現了Flutter的核心庫,包括Dart虛擬機、動畫和圖形、文字渲染、通信通道、事件通知、插件架構等。引擎渲染采用的是2D圖形渲染庫Skia,虛擬機采用的是面向對象語言Dart VM,并將它們托管到Flutter的嵌入層。shell實現了平臺相關的代碼,比如跟屏幕鍵盤IME和系統應用生命周期事件的交互。不同平臺有不同的shell,比如Android和iOS的shell。

2. Flutter編譯產物

看完Flutter內部架構,或許你好奇,Flutter不用Android/iOS的本地語言技術開發,Dart編寫完的代碼如何讓不同系統可以識別,最終編譯后得到的產物是什么呢?

跨平臺技術演進及Flutter未來

Flutter產物分為Dart業務代碼和Engine代碼各自生成的產物,圖中的Dart Code包含開發者編寫的業務代碼,Engine Code是引擎代碼,如果并沒有定制化引擎,則無需重新編譯引擎代碼。

一份Dart代碼,可編譯生成雙端產物,實現跨平臺的能力。經過編譯工具處理后可生成雙端產物,圖中便是release模式的編譯產物,Android產物是由vm、isolate各自的指令段和數據段以及flutter.jar組成的app.apk,iOS產物是由App.framework和Flutter.framework組成的Runner.app

這個過程涉及frontendserver、gensnapshot、xcrun、ninja編譯工具。frontendserver前端編譯器會進行詞法分析、語法分析以及相關全局轉換等工作,將dart代碼轉換為AST(抽象語法樹),并生成app.dill格式的dart kernel。gensnapshot經過CHA、內聯等一系列執行流的優化,根據中間代碼生成優化后的FlowGraph對象,再轉換為具體相應系統架構(arm/arm64等)的二進制指令。

3. Flutter引擎啟動

既然了解了Flutter的編譯產物,那你或許又好奇,Flutter這臺引擎如何發動的,怎么跟Native銜接呢?

跨平臺技術演進及Flutter未來

這里以Android為例,熟悉Android的開發者,應該都了解APP啟動過程,會執行Application和Activity的onCreate方法,FlutterApplication和FlutterActivity的onCreate方法正是連接Native和Flutter的樞紐。

  • FlutterApplication.java的onCreate過程主要完成初始化配置、加載引擎libflutter.so、注冊JNI方法;

  • FlutterActivity.java的onCreate過程,通過FlutterJNI的AttachJNI方法來初始化引擎Engine、Dart虛擬機、Isolate、taskRunner等對象。再經過層層處理最終調用main.dart中main方法,執行runApp(Widget app)來處理整個Dart業務代碼。

Flutter引擎啟動中會創建有4個TaskRunner以及創建虛擬機,分別來看看它們的工作原理。

4. TaskRunner工作原理

Flutter引擎啟動過程,會創建UI/GPU/IO這3個線程,會為這些線程依次創建MessageLoop對象,啟動后處于epoll_wait等待狀態。對于Flutter的消息機制跟Android原生的消息機制有很多相似之處,都有消息(或者任務)、消息隊列(或任務隊列)以及Looper;有一點不同的是Android有一個Handler類,用于發送消息以及執行回調方法,相對應Flutter中有著相近功能的便是TaskRunner。

跨平臺技術演進及Flutter未來

上圖是從源碼中提煉而來的任務處理流程,比官方流程圖更容易理解一些復雜流程的時序問題,后續會專門講解個中原由。Flutter的任務隊列處理機制跟Android的消息隊列處理相通,只不過Flutter分為Task和MicroTask兩種類型,引擎和Dart虛擬機的事件以及Future都屬于Task,Dart層執行scheduleMicrotask所產生的屬于Microtask。

每次Flutter引擎在消費任務時調用FlushTasks方法,遍歷整個延遲任務隊列delayedtasks,將已到期的任務加入task隊列,然后開始處理任務。

  • Step 1: 檢查task,當task隊列不為空,先執行一個task;

  • Step 2: 檢查microTask,當microTask不為空,則執行microTask;不斷循環Step 2 直到microTask隊列為空,再回到執行Step 1;

可簡單理解為先處理完所有的Microtask,然后再處理Task。因為scheduleMicrotask方法的調用自身就處于一個Task,執行完當前的task,也就意味著馬上執行該Microtask。

了解了其工作機制,再來看看這4個Task Runner的具體工作內容。

  • Platform Task Runner:運行在Android或者iOS的主線程,盡管阻塞該線程并不會影響Flutter渲染管道,平臺線程建議不要執行耗時操作;否則可能觸發watchdog來結束該應用。比如Android、iOS都是使用平臺線程來傳遞用戶輸入事件,一旦平臺線程被阻塞則會引起手勢事件丟失。

  • UI Task Runner: 運行在ui線程,比如1.ui,用于引擎執行root isolate中的所有Dart代碼,執行渲染與處理Vsync信號,將widget轉換生成Layer Tree。除了渲染之外,還有處理Native Plugins消息、Timers、Microtasks等工作;

  • GPU Task Runner:運行在gpu線程,比如1.gpu,用于將Layer Tree轉換為具體GPU指令,執行設備GPU相關的skia調用,轉換相應平臺的繪制方式,比如OpenGL, vulkan, metal等。每一幀的繪制需要UI Runner和GPU Runner配合完成,任何一個環節延遲都可能導致掉幀;

  • IO Task Runner:運行在io線程,比如1.io,前3個Task Runner都不允許執行耗時操作,該Runner用于將圖片從磁盤讀取出來,解壓轉換為GPU可識別的格式后,再上傳給GPU線程。為了能訪問GPU,IO Runner跟GPU Runner的Context在同一個ShareGroup。比如ui.image通過異步調用讓IO Runner來異步加載圖片,該線程不能執行其他耗時操作,否則可能會影響圖片加載的性能。

5. Dart虛擬機工作

Flutter引擎啟動會創建Dart虛擬機以及Root Isolate。DartVM自身也擁有自己的Isolate,完全由虛擬機自己管理的,Flutter引擎也無法直接訪問。Dart的UI相關操作,是由Root Isolate通過Dart的C++調用,或者是發送消息通知的方式,將UI渲染相關的任務提交到UIRunner執行,這樣就可以跟Flutter引擎相關模塊進行交互。

何為Isolate,從字面上理解是“隔離”,isolate之間是邏輯隔離的。Isolate中的代碼也是按順序執行,因為Dart沒有共享內存的并發,沒有競爭的可能性,故不需要加鎖,也沒有死鎖風險。對于Dart程序的并發則需要依賴多個isolate來實現。

跨平臺技術演進及Flutter未來

圖解:

  • isolate堆是運該isolate中代碼分配的所有對象的GC管理的內存存儲;

  • vm isolate是一個偽isolate,里面包含不可變對象,比如,true,false;

  • isolate堆能引用vm isolate堆中的對象,但vm isolate不能引用isolate堆;

  • isolate彼此之間不能相互引用;

  • 每個isolate都有一個執行dart代碼的Mutator thread,一個處理虛擬機內部任務(比如GC, JIT等)的helper thread;可見,isolate是擁有內存堆和控制線程,虛擬機中可以有很多isolate,但彼此之間內存不共享,無法直接訪問,只能通過dart特有的Port端口通信;isolate除了擁有一個mutator控制線程,還有一些其他輔助線程,比如后臺JIT編譯線程、GC清理/并發標記線程;

6. Widget架構概覽

Flutter引擎啟動后執行Dart業務,是通過runApp(Widget app)方法,那Widget又是什么呢?

跨平臺技術演進及Flutter未來

Widget是所有Flutter應用程序的基石,Widget可以是一個按鈕,一種字體或者顏色,一個布局屬性等,在Flutter的UI世界可謂是“萬物皆Widget”。常見的Widget子類為StatelessWidget(無狀態)和StatefulWidget(有狀態);

  • StatelessWidget:內部沒有保存狀態,UI界面創建后不會發生改變;

  • StatefulWidget:內部有保存狀態,當狀態發生改變,調用setState方法會觸發StatefulWidget的UI發生更新,對于自定義繼承自StatefulWidget的子類,必須要重寫createState方法。

三棵樹

跨平臺技術演進及Flutter未來

圖解:

  • Widget是為Element描述需要的配置, 負責創建Element,決定Element是否需要更新。Flutter Framework通過差分算法比對Widget樹前后的變化,決定Element的State是否改變。當重建Widget樹后并未發生改變, 則Element不會觸發重繪,則就是Widget樹的重建并不一定會觸發Element樹的重建。

  • Element表示Widget配置樹的特定位置的一個實例,同時持有Widget和RenderObject,負責管理Widget配置和RenderObject渲染。Element狀態由Flutter Framework管理, 開發人員只需更改Widget即可。

  • RenderObject表示渲染樹的一個對象,負責真正的渲染工作,比如測量大小、位置、繪制等都由RenderObject完成。

可見,開發者通過Widget配置,Framework通過比對Widget配置來更新Element,最后調度RenderObject Tree完成布局排列和繪制。

7. 渲染原理

Dart的UI采用Widget來實現,最終轉換為RenderObject,那界面又是如何渲染的呢?

跨平臺技術演進及Flutter未來

渲染過程,UI線程完成布局、繪制操作,生成Layer Tree;GPU線程執行合成并光柵化后交給GPU來處理,其中幾個關鍵步驟:

  • Animate: 遍歷_transientCallbacks,執行動畫回調方法;

  • Build: 對于dirty的元素會執行build構造,沒有dirty元素則不會執行,對應于buildScope

  • Layout: 計算渲染對象大小和位置,對應于flushLayout,這個過程可能會嵌套再調用build操作;

  • Compositing bits: 更新具有臟合成位的任何渲染對象, 對應于flushCompositingBits;

  • Paint: 將繪制命令記錄到Layer, 對應于flushPaint;

  • Compositing: 將Compositing bits發送給GPU, 對應于compositeFrame;

GPU線程通過skia向GPU硬件繪制一幀的數據,GPU將幀信息保存到FrameBuffer里面,然后視頻控制器會根據VSync信號從FrameBuffer取幀數據傳遞給顯示器,從而顯示出最終的畫面。

8. Platform Channels

Flutter框架提供了UI的控件支持,對于APP除了UI還有其他依賴于Native平臺的支持,比如調用Camera的功能,該怎么辦呢?為此,Flutter通過提供Platform Channel的功能,使得Dart代碼具備與Native交互的能力。

跨平臺技術演進及Flutter未來

Platform Channel用于Flutter與Native之間的消息傳遞,整個過程的消息與響應是異步執行,不會阻塞用戶界面。Flutter引擎框架已完成橋接的通道,這樣開發者只需在Native層編寫定制的Android/iOS代碼,即可在Dart代碼中直接調用,這也就是Flutter Plugin插件的一種形式。

三、結束語

科技不斷在進步,技術不斷發展,移動跨平臺技術幾乎從Android、iOS誕生不久便出現,已發展快10年。時至今日,兼具跨端高效率與高性能體驗的Flutter力壓群雄,嶄露頭角,已然成為當下最熱門的移動端新技術,全球越來越多的公司在Flutter技術布局并落地產品應用,社區也非常活躍。

筆者之前一直從事于Android操作系統底層研發工作,今年剛接觸Flutter,Flutter作為一門全新的跨平臺技術框架,不斷深究會發現這是一個小型系統,涉及到的技術很廣:

  • 編譯技術如何將dart代碼轉換為AST(抽象語法樹),如何匯編轉換為機器碼,打包成產物是什么?

  • Flutter這臺引擎如何發動的,怎么跟Native原生系統銜接運行,如何識別產物并加載到內存?

  • 引擎啟動后,TaskRunner如何分發任務,跟原生系統消息機制有什么關系?

  • Dart虛擬機如何管理內存,跟isolate又有什么關系?

  • 開發者編寫的Widget控件如何渲染到屏幕上?

  • Flutter如何通過plugin支持移動設備提供的服務?

以上問題本文都已逐一回答,如果僅僅是用Flutter做業務開發,并不需要掌握這么深度技術,不過,知其然知其所以然,能讓你游刃有余。本文講述跨平臺技術的過去與未來,以及從宏觀架構解讀Flutter內部原理,后續有時間將更深入的技術細節以及實戰經驗角度來跟大家揭秘更多Flutter技術。

隨著5G+IOT時代的到來,Fuchsia系統或許發力IOT新戰場,你所掌握的Flutter技術棧可以無縫遷移,這是一次彎道超車的機會。即便Fuchsia落敗,相信只要深扎Flutter系統技術的精髓,其他任何的移動端新技術都可以輕松快速地掌握。

最后,用一句話來結束本次分享,“有時候,你選擇一個方向,不是因為它一定會成為未來,而是它有可能成為不一樣的未來。”


我來說兩句
您需要登錄后才可以評論 登錄 | 立即注冊
facelist
所有評論(0)
領先的中文移動開發者社區
18620764416
7*24全天服務
意見反饋:[email protected]

掃一掃關注我們

Powered by Discuz! X3.2© 2001-2019 Comsenz Inc.( 粵ICP備15117877號 )

时时彩改欢乐生肖 云南快乐时时彩今天 股票分析师排名 云南时时彩购买技巧 广东十一选五走势图下载 飞禽走兽玩法 3d开奖结果 神泣刚开始什么赚钱 新红牛 网络贷款怎么赚钱 分享互联网成功创业赚钱 什么软件能看电视赚钱 什么样的机构赚钱 奔驰宝马游戏机作弊器 捕鱼达人经典2旧版本 加拿大28预测55 网上手机赚钱是什么套路