? ? ? ? 1.Google官方(多引擎方案)
????????Google官方建議的方式是多引擎方案,即每次使用一個新的FlutterEngine來渲染Widget樹,存在的主要問題是每個引擎都要有比較大的內存等資源消耗,雖然Flutter?2.0之后的FlutterEngineGroup通過在引擎間共享GPU?上下文、font?metrics?和?isolate?group?snapshot,開銷已大大降低,但是仍然沒有解決每個FlutterEngine是一個單獨isolate,不同FlutterEngine間的通信將會是非常麻煩的問題。
? ? ? ??2.大名鼎鼎的閑魚flutter_boost(單引擎方案)
????????Flutter?Boost采用的是直接共享Flutter?engine對象,在頁面切換時,?Flutter?View與Flutter?Engine進行attach與detach操作。Flutter?boost早期版本Dart側維護了一個Navigator棧的結構,基于棧的操作依賴對Flutter框架的一個屬性修改,具有侵入性,并且由于pop出的頁面就會銷毀,在多個平級邏輯頁面切換時,無法使其它flutter平級頁面狀態得到保持。最新版本主要變化是,?不再用棧式結構來管理Flutter頁面,?改為在native側和Flutter側對所有頁面都進行緩存。頁面的創建與銷毀與對應的native容器的生命周期保持一致。這一改變解決了侵入性問題,并且所有頁面的狀態都可以保持。
????????簡言之,?Flutter?boost最新版本的核心邏輯是,頁面導航的核心仍然由native進行驅動,根據native側的頁面生命周期事件,通過channel通知Flutter側響應頁面上屏等邏輯。?對于每個Flutter頁面,?在native側,?則都有一個FlutterViewContainer實例與之對應,??在dart側則是一個BoostContainer實例,其緩由FlutterContainerManager進行管理,兩者通過通信,保持生命周期一致。哪個頁面需要顯示,在native側就是將對應的vc?push進導航棧,同時將flutter引擎attach到對應的FlutterViewController。
? ? ? ?但Flutter?boost方案仍然存在一些問題:
????????(1)開源版本不夠穩定,?適配Flutter新版本非常慢
????????(2)未完全剝離對阿里業務框架的依賴,里面包含很多與導航無關的代碼依賴
????????3.哈嘍單車團隊的flutter_thrio(單引擎/多引擎均支持)
? ? ? ? flutter_thiro是哈嘍單車團隊提供的一個解決方案,其與flutter_boost的主要不同是,flutter_boost的導航切換都是由native側驅動,每次頁面切換native側都會創建一新的頁面放到導航棧中,而flutter_thrio在native之間及native和flutter之間的頁面切換同樣由native側驅動,但flutter頁面內部的切換由flutter自帶的Navigator來管理,native側導航棧不創建對應的頁面容器。這樣做的好處是可以節省部分內存,但需要通過一層包裝處理隔離這種導航實現方式上的差異,實現上會更復雜一些。
????????
??????????? 不過flutter_thrio整體封裝相當不錯,所有的頁面切換邏輯非常統一,均采用基于url進行頁面跳轉。同時既支持單引擎工作模式,也支持多引擎工作模式,同時不存在對引擎代碼的侵入式修改,不過該方案開源代碼已經有兩年多沒有更新,如果遇到問題,可能需要自行維護。
????????4.字節跳動團隊的Isolate復用方案和騰訊心悅團隊的TRouter方案
????????這兩個方案均未開源,從介紹來看都存在對flutter引擎的侵入式修改,比如今日頭條的方案就是通過修改 Flutter Engine 源碼,使多 FlutterView 實例對應的多 Flutter Engine 能夠在底層共享?Isolate。即在上層看來有多個Flutter?Engine?實例,但在底層只有一個唯一的Isolate,這樣就可以在解決多引擎內存占用大的問題的同時,保持數據仍然可以在引擎間共享。這類侵入性比較強的方案存在的主要問題是,接入方案就需要接入相關的自定義flutter引擎代碼,后續在可維護性上以及對flutter版本升級的兼容性上都存在較大不確定性。