背景介紹
Android應用采用Java或Kotlin編寫，iOS應用采用Objective-C和Swift編寫，但當我們要去開發支援多端的應用，每一端都需要獨立研發、測試，直到上線。為了解決多端獨立開發的問題，跨端技術的方案備受青睐。
兩輪跨端技術的嘗試要追溯到2019年，當時整個網際網路行業都在提效的大背景推動下開始各種跨端方案的嘗試，而前身還是兩輪助力車團隊的兩輪大前端也開始了跨端技術方案的探索。
當時可供選擇的跨端方案有React Native方案、Weex方案，H5離線化方案以及當時較火的Flutter技術方案，而我們的目标是希望能夠找到穩定、适合我們業務特性，并且可以繼續進行深耕的技術方案進行調研和嘗試。
思考和調研
主流的跨端方案主要分為兩種，一種是将JavaScriptCore引擎當作虛拟機的方案，代表的架構是React Native。另一種使用自渲染引擎的方案，代表架構是Flutter。
架構層+原生渲染方案
它的開發語言選擇了js，使用的文法和React完全一緻，不用于一般React應用，它需要借助原生的能力來進行渲染，元件最終都會被渲染為原生元件。雖然給使用者帶來比較好的體驗，但性能方面不會很高。
以Web為基礎的H5 Hybrid離線化方案
相對來說這是開發成本最小的一種方案，因為它實際上是在寫前端的界面，和普通開發H5網頁并沒有太大的差別。這一方案所面臨的主要考驗就是性能問題以及因為網絡延遲而帶來的使用者體驗問題。在此基礎上我們引入了離線化的方案，我們計劃是通過CRM平台發放H5離線包到達本地，使用WebView進行本地資源加載，來突破性能問題。
架構層+自渲染引擎方案
這種方案和上面的差別就是，它并沒有直接借用原生能力去渲染元件，而是利用了更底層的渲染能力，自己去渲染元件。這種方式顯然鍊路會比較短，性能方面也會更突出，同時在保持多端渲染一緻性上面，也會比前面兩種方案更加可靠，這類架構的典型例子就是Flutter。
方案對比與選擇
我們在選擇跨端方案的時候，不隻是要考慮常見的幾種重要名額，如程式設計語言、性能、技術架構等來判斷是否适合我們團隊和産品，更多還要去考慮開發效率、社群支援等工程化方面的名額，同時還要考慮團隊現狀、所選方案的生态和技術未來的發展方向。
對比方案制定
在社群、成熟度趨于一緻的時候，跨平台方案的性能就成了重要的考慮因素和名額。性能更佳的Flutter當然是首選。另一方面，對于原本是Native開發的人來說，React Native與Flutter開發成本是相差不大的，從長遠角度來看，選擇Flutter技術方案似乎是較為合适的選擇。
同時結合當時組内的情況，我們選擇了H5 Hybrid離線化和Flutter作為比較方案進行端測的嘗試。H5 Hybrid離線化方案相對來說比較簡單，而且自主性比較強，方案邏輯簡單風險較小。如果試驗成功我們可以走出一條自主創新的跨端路線，而Flutter技術方案性能較高，社群也比較活躍，UI渲染架構做的較為徹底，也是當時跨端技術方案的代表方向。是以我們綜合以上的考慮，希望通過實踐拿到關鍵的對比資料，為後續最終的方案選擇提供支援。
Flutter是什麼
Flutter是Google的移動UI架構，可以快速在iOS和Android上建構高品質的原生使用者界面，它是Google一個新的用于建構跨平台的手機App的SDK。寫一份代碼，可以多端運作，Flutter同時可以與現有的代碼一起工作，被越來越多的開發者群組織使用，并且Flutter是完全免費和開源的。
從官方的介紹來看，Flutter的特點可以總結成三點。一是跨平台，現在Flutter 3基本可以實作跨6種平台，甚至支援嵌入式開發。到目前為止Flutter算是支援平台最多的架構了，良好的跨平台性，直接帶來的好處就是減少開發成本。二是原生使用者頁面，讓我們的體驗更好，性能方面也會更好。用官方的話就是平滑而自然的滑動效果和平台感覺，為使用者帶來全新的體驗。三是開源免費，同Android系統一樣，這些都是免費開源的。
方案線上驗證
經過一段時間的調研和分析以後，我們基本上确定了兩輪跨端方案的技術選型和對比方案。本着謹慎的原則，我們花費了一定的精力在這兩個方案的驗證對比、以及跨端技術方案的推進方法探索上。
H5 Hybrid離線化方案
針對該方案，我們的計劃是分兩期執行。第一期是完成架構的核心代碼，并在BOS端完成一個頁面的改造上線，拿到線上運作資料。第二期是在第一期資料的基礎上打造CRM平台，完善方案的系統應用。
該方案的基本結構分為代碼層、協定層、Hybrid離線SDK層以及離線包管理系統。其中的代碼層是符合特定标準的H5工程開發産生的代碼。當H5頁面産生資源或樣式的申請時，容器層會檢測資源請求事件，并根據資源協定尋找本地資源包對應位置的資源并進行加載。本地資源加載完成後，形成資料流請求響應傳回H5頁面。
資料的流轉在架構中經曆了資料分發、協定解析、目标執行、結果回報幾個階段。通過在端側建立協定層的封裝，保證了協定規則統一。整個協定過程做了SDK化的封裝，保證了核心架構層的穩定。
Flutter方案
針對Flutter方案的嘗試，我們需要在一開始優先解決工程結構、打包建構、上線內建和原生工程混合開發的問題。
針對于工程結構，Flutter在業務上的應用需要一個Host載體，我們選擇了Flutter Module工程作為Flutter業務工程的Host工程。向上輸出建構産物對原生工程的繼承，向下組裝和集合業務工程，形成統一的子產品注入、頁面注冊的形式。
針對Flutter項目打包建構、上線內建和混合開發的問題，我們需要結合當時公司産物建構和管理規則進行Flutter産物的建構。我們的方案是在Jinkens上面建立單獨的Job進行Flutter module産物的建構，最終把生成的Android和iOS産物內建到原生工程中，實作Flutter環境和代碼的內建。以上便初步搭建完成了Flutter業務開發工程結構，并實作了在原生工程中混合開發、建構上線的一系列流程。
比對實驗
在頁面上線後，我們很快拿到了一手資料。在穩定性方面兩種方案表現都比較好，沒有出現頁面crash的情況。在加載性能、白屏或者異常方面，Flutter方案要比H5 Hybrid離線化方案表現得更好。綜合以上運作情況對比，我們基本确定了Flutter作為主要的大前端實踐方案。
Flutter應用推進
架構1.0階段
我們對Flutter技術工程化應用生産了各種輪子，以求達到對Flutter規範、高效應用的目的，比如資料的流轉分發、網絡子產品的封裝、MVVM結構的組織等。這一階段的架構主要分為頁面路由管理、資料總線、工程架構、網絡請求、資源管理群組件管理。總體來說在這一階段，我們對于Flutter應用基本形成了初具雛形的工程結構體系和基礎能力建設。
架構2.0階段
在這一階段Flutter的應用算是進入了深水區，随着應用場景的增加，各種問題暴露出來，其中比較棘手的問題有Flutter狀态管理、頁面生命周期和混合插件缺失問題。針對Flutter狀态管理、頁面生命周期的問題，我們基于原生開發的經驗，搭建了一套符合 MVVM标準的Flutter代碼基礎結構。
這套基礎結構主要分為Page與VM兩部分，組織關系如圖所示。Page與VM邏輯分開，Page是對VM的封裝，VM是業務邏輯的獨立單元，包含了完整的UI以及邏輯層Module。
下面是Page基礎結構功能定義說明。在這一結構中，我們是以PageRoute為基礎進行擴充封裝。PageLifecycle定義了生命周期和生命周期狀态值；LifecycleEventNotify負責生命周期事件的傳遞；LifecycleNotifyManager是生命周期架構的核心樞紐，所有的事件彙總到這裡向下調用生命周期API；LifecycleFromFlutter和LifecycleFromBoost收集flutter原生和flutter boost的生命周期的調用，總結調整後按照新的生命周期規範發送事件；PageAnimation是頁面動畫的內建工具；WidgetProviderRender是頁面UI搭建的工具類，負責provider、widget的建立群組裝，最終形成完整的頁面；ModuleBinder是頁面對Module的綁定工具，實作了module宿主的綁定，當宿主銷毀時module能感覺到并做出相應的反應。
下面是VM層基礎結構。VM層和Page層基本類似，不同的是它會根據VM的特點進行自身生命周期的感覺和處理，處理方式相對Page會更加複雜。
Flutter Map元件
針對以地圖為代表的原生混合元件能力的建設，當時flutter社群的能力支援不足，沒有合适的輪子使用，但是我們的業務場景又是比較重地圖的。在這種情況下，我們就需要自己去開發一套地圖元件。
如圖是Flutter Map的總體結構圖，我們利用的是flutter架構的PlatformView機制，在原生層實作view的執行個體化建立，再交給flutter進行UI的渲染，實作了原生view在flutter體系中的渲染和展示。接下來我們需要在flutter層與原生view進行操控，這裡需要我們能夠準确找到對應的原生view，并通過channel通道傳達相關的指令。原生view收到指令以後，會根據規則做出相應的動作，并産生結果原路傳回給調用方。原生view産生一些事件狀态時，比如地圖的拖動、加載完成等事件，需要及時傳遞給flutter端，同時flutter端有一些狀态也需要傳遞給原生端，以便業務側和原生view側都能夠及時做出相應的反應。這裡我們以channel為基礎建立了雙工通道，實作了flutter與 platform兩端實作實時進行事件通知的能力。
Flutter标準體系化建設階段
在這一階段我們的flutter在兩輪大量的業務場景的應用實踐下，基本趨于穩定的狀态，經過我們在這一階段對flutter的體系化改造，形成了集合flutter工程搭建、開發調試、基礎能力沉澱以及開發标準輸出的體系化結構。
Git倉庫整理
在倉庫結構方面，我們整合了散亂的flutter倉庫維護狀态，形成了現在統一、标準、聚合的倉庫集合。目前的倉庫叫HBFlutter，包括中間件子分組、基礎元件子分組、native能力子分組和其他子分組。
元件分類
在基礎能力沉澱方面，我們對現有基礎元件進行了梳理和标準化改造，基本形成了一套體系化的flutter基礎能力建設。
技術總結
Flutter技術目前在兩輪得到了應用和推廣，在哈啰App兩輪業務場景下基本實作了全量Flutter化改造，Bos App也在今年開啟了Flutter技術改造，目前已經基本實作大部分流程的Flutter化改造，目前線上運作相對平穩。兩輪業務在應用Flutter技術後實作了開發效率的大幅度提升，同時也很大程度上解決了Android和iOS UI不一緻的問題。後續我們将繼續追蹤Flutter技術的發展，并視業務場景的需求進行合理的應用和推廣。
作者:田克雨
來源:微信公衆号:哈啰技術
出處:https://mp.weixin.qq.com/s/Zshn9NQ9ZWwczMsgeVRZHw