對標蘋果的靈動島 華為帶來實況窗功能
繼蘋果的靈動島之后，華為也在今天正式推出了“實況窗”功能。據今天鴻蒙OS 4.0的現場演示顯示，華為的實況窗可以更高效的展現出實時通知，比如鎖屏上就能看到外賣、打車、銀行
跨端技術一直是移動端開發領域的熱門話題，Flutter 作為一種領先的移動跨端技術之一，憑借其快速的渲染引擎、豐富的UI組件庫和強大的開發工具，成為了開發人員的首選之一。
從 Flutter 誕生之初，我們就一直關注著它的發展，Flutter 早期版本變更較為頻繁，并且經常伴隨著 Breaking Change，另外可用的三方插件較少且不穩定。直到2019年，Flutter 的熱度暴漲，國內不少團隊陸續把 Flutter 引入到了生產環境使用，社區也涌現出不少優秀的開源項目，我們也決定在這個時候做一些技術上的嘗試。
經過這幾年在 Flutter 技術上的不斷學習、探索和積累，Flutter 已經成為了客戶端技術體系中的重要組成部分。
回顧整個過程，我們大致經歷了這么幾個階段：可行性驗證、基建一期建設、小范圍試驗、基建二期建設、大范圍推廣、前端生態的探索，下文將分別對每個階段展開進行介紹。
其實在這之前我們已經做過了一些調研，但許多結論都是來源于網上的一些文章或者其它團隊的實踐，這些結論是否靠譜是否真實還有待商榷，另外，網上的文章大都千篇一律，要么使勁吹捧，要么使勁貶低，要得出相對客觀的結論還是得需要我們自己通過實踐才能得出。
我們確定了以下幾個維度，用來評估 Flutter 是否值得我們進一步投入：
由于前期對 Flutter 的熟練度不高，基礎設施也還沒有搭建起來，所以在開發效率上，我們期望的 Flutter 的開發耗時能保持在原生開發耗時的 1.5 倍以內，不然雖然實現了跨端，但是需求的開發周期反而被拉長了，這樣得不償失。在UI一致性上，我們期望同一份代碼在兩端的表現要基本達到一致，不需要額外的適配成本。在性能方面，盡量保證崩潰、卡頓、內存、幀率這些指標在可控范圍內。
我們希望用較小的代價完成上述維度的評估，所以在試驗期間的架構及基礎設施方面我們做的比較簡單。
當時我們正在做一個叫切克的 App，用戶量級比較小，工程架構也相對簡單一些，正好可以用來做一些技術方面的探索和驗證。
我們選擇的是切克的商品詳情頁，用 Flutter 技術實現了一個一模一樣的商詳，按1:1的流量分配給 Native 和 Flutter。
由于我們的工程不是一個全新的項目，所以采用的是 Native 與 Flutter 混合開發的方式，Native 主工程只依賴 Flutter 產物即可，同時也盡量避免對原有工程的影響。
關于混合頁面棧的問題，我們沒有額外處理，因為暫時只測試一個頁面，不會涉及到多頁面混合棧的問題，所以暫時先忽略。
為了降低驗證成本，我們沒有對接現有的 Native 的持續集成流程，而是直接在本地構建 Flutter 產物，然后上傳到遠程倉庫。
經過一段時間的線上驗證，我對 Flutter 技術基本有了一個比較全面的了解：
在開發效率上由于基礎庫和基建的缺失，在處理 Flutter 業務跟 Native 業務的交互時需要更多的適配成本，包括像頁面跳轉、埋點上報、接口請求、圖片加載等也需要額外的處理，但我們評估隨著后續基建的不斷完善，這部分的效率是可以逐步得到改善的；而在涉及UI開發方面，得益于熱重載等技術，Flutter 的開發效率是要優于原生開發的。整體評估下來，在開發效率方面 Flutter 是符合我們的預期的。
在UI一致性上，除了在狀態欄控制和文本在某些情況下需要特殊適配下外，其它控件在兩端的表現基本一致。
在性能表現上，Flutter 會額外引入一些崩潰，內存占用也有所上漲，但還在可接受范圍內。
Flutter 的學習成本相對還是比較高，畢竟需要單獨學習一門語言，另外 Flutter 的渲染原理也跟原生有很多差異，需要轉變思維才能更快的適應，此外 Flutter 還提供了眾多的 Widget 組件，也需要較長時間學習。
在發展趨勢上，Flutter 無疑是當時增長最快的跨端技術之一，社區的活躍程度以及官方的投入都非常高，國內不少團隊也都在積極推進 Flutter 技術的發展，Flutter 正處在一個快速的上升期。
整體來說，Flutter 是滿足我們團隊對跨平臺技術的需求的，我們計劃在接下來的一段時間投入更多資源，把 Flutter 的基礎設施逐漸建立起來。
基建一期內容主要包括以下幾個方面：
在基建一期完成后，我們的目標是要達到：
工程架構指的是原生工程與 Flutter 工程之間的關系，以及 Flutter 工程與 Flutter 工程之間的關系。
我們知道，使用 Flutter 開發通常有兩種情況，一種是直接使用 Flutter 開發一個新的App，屬于純 Flutter 開發；一種是在已有的 Native 工程中引入，屬于混合開發。我們當然屬于后者。
而混合開發又可分為兩種：源碼集成和產物集成。源碼集成需要改變原工程的項目結構，并且需要 Flutter 開發環境才能編譯，而產物集成則不需要改動原工程的項目結構，只需把 Flutter 的構建產物當作普通的依賴庫引入即可，原有 Native 工程和 Flutter 工程從物理上完全獨立。顯而易見的我們選擇產物集成的方式，引入 Flutter對于原工程以及非 Flutter 開發人員來說，基本上是毫無感知的。
所以原生工程與 Flutter 工程之間的關系如下圖所示：
原生工程與Flutter工程之間的關系
根據已有的客戶端基建的開發經驗，我們將所有 Flutter 工程分為了四層：
容器層負責提供 Flutter 的基礎運行環境，包括 Flutter 引擎管理、頁面棧管理、網絡框架、KV存儲、數據庫訪問、埋點框架、Native 與 Flutter 通信通道和其它基礎功能。
公共層包含一些通用的開源庫、自定義UI組件、部分通用業務等。
業務層包含用戶信息、商品、發布等業務組件。
殼工程負責集成各業務組件，最終構建出產物集成到 Native 主工程。
其中業務層、公共層、容器層都是由若干個獨立的工程所組成，整體結構如下：
Flutter分層架構
開發框架是為了提高開發效率、規范代碼結構、減少維護成本等考慮而設計的一套軟件框架，包括：基礎能力、狀態管理、頁面棧管理等。
開發框架需要提供各種必要的能力，比如：頁面跳轉、埋點、網絡請求、圖片加載、數據存儲等，為了最大化減少研發成本，我們在底層定義了一套通用的數據交互協議，直接復用了現有的 Native 的各項能力，也使得 Native 的各種狀態與 Flutter 側能夠保持統一。
相信了解 Flutter 的同學一定知道狀態管理，這也是跟 Native 開發區別較大的地方。在開發較為復雜的頁面時，狀態維護是非常繁瑣的，在不引入狀態管理框架的情況下，開發效率會受很大影響，后期的維護成本以及業務交接都是很大的問題。
另外，在開發框架設計之初，我們就期望從框架上能夠在一定程度上限定代碼結構、模塊之間的交互方式、狀態更新方式等，我們期望的是不同的人寫出來的代碼在邏輯、結構和風格上都能保持比較統一，即在提高開發效率的同時，也能保證項目后續的可維護性和擴展性，減少不同業務間的交接成本。
基于上述這些需求，在我們對比了多個開源項目后，FishRedux 的整體使用感受正好符合我們的要求。
如下圖，兩個頁面的代碼結構基本一致：
收藏詳情和個人主頁
在早期版本，Flutter 引擎的實例占用內存較高，為了減少內存消耗，大家普遍采用單實例的模式，而在 Native 和 Flutter 混合開發的場景下就會存在一個問題，就是 Native 有自己的頁面棧，而 Flutter 也維護著一套自己的頁面棧，如果 Native 頁面與 Flutter 頁面穿插著打開，在沒有特殊處理的情況下，頁面棧會發生錯亂。在調研了業內的各種開源方案后，我們選擇引入 FlutterBoost 用來管理頁面混合棧。
為了方便開發同學搭建 Flutter 的開發環境，同時能夠管理使用的 Flutter 版本，我們開發了 zflutter 命令行工具，包含以下主要功能：
如圖：
zflutter
客戶端使用的是自研的 Beetle 平臺（集工程管理、分支管理、編譯、發布于一體），短時間內要支持上 Flutter 不太現實，基于此，我們先臨時自己搭臺服務器，通過 gitlab 的 webhook 功能結合 zflutter 工具簡單實現了一套自動化構建的服務，待 Beetle 支持 Flutter 組件化開發功能后，再將工作流切回到 Beetle 平臺。
在完成基建一期的開發工作后，我們決定通過開發幾個實際業務來試驗目前的基礎設施是否達到既定目標。
我們以不影響主流程、能覆蓋常見UI功能、并且能跟 Native 頁面做AB測試（主要是方便在出問題時能夠切換到 Native 版本）為條件挑選了個人資料頁和留言列表頁進行了 Flutter 化改造，如下圖所示：
個人資料頁/留言列表頁
這兩個頁面涵蓋了網絡請求、圖片加載、彈窗、列表、下拉刷新、上拉加載更多、左滑刪除、埋點上報、頁面跳轉等常見功能，足以覆蓋日常開發所需的基礎能力。
經過完整的開發流程以及一段時間的線上觀察，我們得出如下結論：
目前已具備的基礎能力已經足夠支撐普通業務開發（開發過程中補足了一些缺失的能力）。
整個開發過程在工程依賴管理和分支管理方面的支持還比較缺失，比較依賴人工處理。
我們在開發前根據頁面功能同時做了純 Native 開發排期和 Flutter 開發排期，按單人日的成本來對比的話，Flutter 實際開發耗時跟 Native 排期耗時比為 1.25:2，Native 是按照 Android+iOS 兩端各一人算的，也就是1.25人/日比2人/日，如果后續對 Flutter 技術熟悉度提升后相信效率還可以進一步提升。
線上兩個 Flutter 頁面的體驗效果跟 Native 對比基本感覺不到差別，但是首次進入 Flutter 頁面時會有短暫的白屏等待時間，這個是由于 Flutter 環境初始化導致的延遲，后續可以想辦法優化。
在引入 Flutter 之后，轉轉的安裝包體積在兩端都分別有所增加：
試驗結果基本符合預期，包體積的增量也在我們的可接受范圍內，接下來將進行基建二期的建設，補足目前缺失的能力。
基建二期的內容主要包含以下工作：
為了能讓大家更清晰的了解 Beetle 的工程管理機制，這里先簡單介紹下客戶端的工程類型：
舉個例子，當有一個新版本需要開發時，先從 Native 主工程創建一個版本同時創建一個 Release 分支，即版本分支，然后從版本分支根據具體需求創建對應 Native 組件的版本分支，Flutter 主工程此時可看作是一個 Native 組件，比如此時創建了一個 Flutter 主工程的版本分支后，可以進入 Flutter 主工程再根據需要創建對應的 Flutter 組件工程的版本分支。
Beetle 目前已支持 Flutter 工程管理、分支管理、組件依賴管理以及組件的發布、Flutter 產物的構建等，Beetle 的作用貫穿從開發到上線的整個工作流。
為了讓大家更快的熟悉 Flutter 開發，我們在客戶端內部組織了5次 Flutter 快速入門的系列分享：
Flutter快速入門系列
同時也逐步完善內部文檔的建設，包括：FlutterSdk 源碼維護策略、Flutter 入門指南、Flutter 混合開發方案、Flutter 與 Native 通信方案、Flutter 開發環境配置、Flutter 組件化工程結構、Flutter 開發與調試、Flutter 開發工作流、ZFlutter 工具使用介紹、Flutter 開發之 Beetle 使用指南等，涵蓋了從環境搭建、開發調試到構建發布的整個過程。
在完成基建二期的建設后，整體基礎設施已經能夠支撐我們常見的業務，開發工作流也基本順暢，于是我們開始了在內部大范圍推廣計劃。
我們先后改造和新開發了個人主頁、我發布的頁面、微商詳、奇趣數碼頁等業務，基本涵蓋了常見的各種類型的頁面和功能，整體開發效率與原生單端開發效率持平，但是在特別復雜的頁面的性能表現上，Flutter 的表現相對要差一些。
部分頁面如下圖所示：
個人主頁
在跨端技術領域我們知道 Web 技術是天然支持的，如果能把前端生態引入到 Flutter 中，那么對客戶端來說，在業務的支持度上會更上一個臺階，Web 的體驗得到提升的同時客戶端也具備了動態化，基于此背景我們開始探索 Flutter 在 Web 上的可能性。
當時可選的開源方案有：Kraken、MXFlutter、Flutter For Web。
Kraken 是一款基于 W3C 標準的高性能渲染引擎。Kraken 底層基于 Flutter 進行渲染，通過其自繪渲染的特性，保證多端一致性。上層基于 W3C 標準實現，擁有非常龐大的前端開發者生態。
Kraken 的最上層是一個基于 W3C 標準而構建的 DOM API，在下層是所依賴的 JS 引擎，通過 C++ 構建一個 Bridge 與 Dart 通信。然后這個 C++ Bridge 把 JS 所調用的一些信息，轉發到 Dart 層。Dart 層通過接收這些信息，會去調用 Flutter 所提供的一些渲染能力來進行渲染。
Kraken 是不依賴 Flutter Widget，而是依賴 Flutter Widget 的底層渲染數據結構 —— RenderObject。Kraken 實現了很多 CSS 相關的能力和一些自定義的 RenderObject，直接將生成的 RenderObject 掛載在 Flutter RenderView 上來進行渲染，通過這樣的方式能夠做到非常高效的渲染性能。
MXFlutter 是一套使用 TypeScript/JavaScript 來開發 Flutter 應用的框架。
MXFlutter 把 Flutter 的渲染邏輯中的三棵樹（即：WidgetTree、Element、RenderObject ）中的第一棵（即：WidgetTree），放到 JavaScript 中生成。用 JavaScript 完整實現了 Flutter 控件層封裝，實現了輕量的響應式 UI 框架，支撐JS WidgetTree 的 build邏輯，build 過程生成的UI描述， 通過Flutter 層的 UI 引擎轉換成真正的 Flutter 控件顯示出來。
Flutter 在 Web 平臺上以瀏覽器的標準 API 重新實現了引擎。目前有兩種在 Web 上呈現內容的選項：HTML 和 WebGL。
HTML 模式提供了最佳的代碼大小，CanvasKit 則提供了瀏覽器圖形堆棧渲染的最快途徑，并為原生平臺的內容提供了更高的圖形保真度。
我們對以上方案從接入成本、渲染性能、包體積、開發生態、學習成本等多維度進行了對比：
最終選擇了 Kraken 作為我們的首選方案。
為了使 Kraken 順利接入轉轉App，我們做了以下幾個方面的工作：
上線后，我們對頁面的各項指標進行了對比，使用 Kraken 容器加載比使用 WebView 加載，在首屏加載耗時的指標上平均增加了281毫秒，原因為：當前版本的 Kraken 容器不支持直接加載 HTML，且只能加載單個 JsBundle，導致加載效率比 WebView 差。
通過跟前端同學溝通，從開發效率上來看，Kraken 工程的開發周期會比實現同樣需求的普通 Web 工程增加1.5到2倍的時間，主要原因是受到 CSS 樣式、Api 差異，無法使用現有UI組件，另外 Kraken 的調試工具目前還不夠完善，使用瀏覽器調試后還須在客戶端容器中調試，整體下來導致開發 Kraken 工程會比開發普通Web工程耗費更多時間。
由于之前選擇的 Web 頁面太過簡單，不具備代表性，所以我們重新選定了“附近的人”頁面做為改造目標，再次驗證 Kraken 在實際開發過程中的效率及性能體驗。頁面如圖所示：
附近的人
最終因為部分問題得不到解決，并且整體性能較差，導致頁面沒能成功上線。
存在的問題包括但不限于下面列舉的一些：
CSS 定位、布局表現與瀏覽器表現不一致
部分 API 表現與瀏覽器不一致(getBoundingClientRect等)
iOS，Android系統表現不一致
頁面初始化渲染完成，動態修改元素樣式，DOM不重新渲染
滑動監聽計算導致 APP 崩潰
調試成本高
不支持 vue-router，單項目單路由
不支持熱更新，npm run build 預覽
不支持 sourceMap，無法定位源代碼
真機調試只支持 element 和 network；dom 和 element 無法互相選中；無法動態修改 dom 結構，無法直接修改樣式.......
頁面白屏，假死
安全性問題
無瀏覽器中的“同源策略”限制
兼容性
npm 包不兼容等
通過這一系列的探索和嘗試，我們了解到了 Kraken 目前還存在許多不足，如果繼續應用會帶來高額的開發調試以及維護成本，所以暫時停止了在 Kraken 方向上的投入，但我們仍然在這個方向上保持著關注。
目前轉轉在Flutter方向上的實踐和探索只是一個起點，我們意識到仍然有很多工作需要去做。我們堅信Flutter作為一項領先的跨端技術，將為轉轉業務的發展帶來巨大的潛力和機會。我們將持續努力，加強技術建設，不斷完善實踐經驗，推動Flutter在轉轉的應用和發展，為用戶提供更好的產品和體驗。
本文鏈接：http://www.www897cc.com/showinfo-26-16288-0.html轉轉Flutter實踐之路
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： WebGPU 入門：繪制一個三角形
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號