在Flutter中嵌入Native組件的正確姿勢是...

引言

在漫長的從Native向Flutter過渡的混合工程時期，要想平滑地過渡，在Flutter中使用Native中較為完善的控件會是一個很好的選擇。本文希望向大家介紹AndroidView的使用方式以及在此基礎之上拓展的雙端嵌入Native組件的解決方案。

1. 使用教程

1.1. DemoRun

嵌入地圖這一場景可能在很多App中都會存在，但是現在的地圖SDK都沒有提供Flutter的庫，而自己開發一套地圖顯然不太現實。這種場景下，使用混合棧的形式是一個比較好的選擇。我們可以直接在Native的繪圖樹中嵌入一個Map，但是這個方案嵌入的View並不在Flutter的繪圖樹中，是一種比較暴力且不優雅的方式，使用起來也很費勁。

這時候，使用Flutter官方提供的控件AndroidView就是一種比較優雅的解決方案了。這里做了一個簡單的嵌入高德地圖的demo，就讓我們跟着這個應用場景，看一下AndroidView的使用方式和實現原理。

1.2. AndroidView使用方式

AndroidView的使用方式和MethodChannel類似，比較簡單，主要分為三個步驟：

第一步：在dart代碼的相應位置使用AndroidView，使用時需要傳入一個viewType，這個String將用於唯一標識該Widget，用於和Native的View建立關聯。

第二步：在native側添加代碼，寫一個PlatformViewFactory，PlatformViewFactory的主要任務是，在create()方法中創建一個View並把它傳給Flutter（這個說法並不准確，但是我們姑且可以這么理解，后續會進行解釋）

第三步：使用registerViewFactory()方法注冊剛剛寫好的PlatformViewFactory，該方法需要傳入兩個參數，第一個參數需要和之前在Flutter端寫的viewType對應，第二個參數是剛剛寫好的的PlatformViewFactory。

配置高德地圖的部分這里就省略不說了，官方有比較詳細的文檔，可以去高德開發者平台進行查閱。

以上便是使用AndroidView的所有操作，總體看起來還是比較簡單的，但是真正要用起來，還是有兩個無法忽視的問題：

1. View最終的顯示尺寸由誰決定？
2. 觸摸事件是如何處理的？

下面就讓小閑魚來給各位一一解答。

2. 原理講解

想要解決上面的兩個問題，首先必須得理解所謂"傳View"的本質是什么？

2.1. 所謂"傳View"的本質是什么？

要解決這個問題，自然避免不了的需要去閱讀源碼，從更深的層面去看這個傳遞的整個過程，可以整理出一張這樣的流程圖：

我們可以看到，Flutter最終拿到的是native層返回的一個textureId。根據native的知識ky h這個textureId是已經在native側渲染好了的view的繪圖數據對應的ID，通過這個ID可以直接在GPU中找到相應的繪圖數據並使用，那么Flutter是如何去利用這個ID的呢？

在之前的深入了解Flutter界面開發中，也給大家介紹了Flutter的繪圖流程。我這里也給大家再簡單整理一下

Flutter的Framework層最后會遞交給Engine層一個layerTree，在管線中會遍歷layertree的每一個葉子節點，每一個葉子節點最終會調用Skia引擎完成界面元素的繪制，在遍歷完成后，在調用glPresentRenderBuffer（IOS）或者glSwapBuffer(Android)按完成上屏操作。

Layer的種類有很多，而AndroidView則使用的是其中的TextureLayer。TextureLayer在之前的《Flutter外接紋理》中有更為詳細的介紹，這里就不再贅述。TextureLayer在被遍歷到時，會調用一個engine層的方法SceneBuilder::addTexture() 將textureId作為參數傳入。最終在繪制的時候，skia會直接在GPU中根據textureId找到相應的繪制數據，並將其繪制到屏幕上。

那么是不是誰拿到這個ID都可以進行這樣的操作呢？答案當然是否定的，Texture數據存儲在創建它的EGLContext對應的線程中，所以如果在別的線程進行操作是無法獲取到對應的數據的。這里需要引入幾個概念：

• 顯示屏對象（Display）：提供合理的顯示器的像素密度和大小的信息
• Presentation：它給Android提供了在對應的上下文（Context）和顯示屏對象（Display）上繪制的能力，通常用於雙屏異顯。

這里不展開講解Presentation，我們只需要明白Flutter是通過Presentation實現了外接紋理，在創建Presentation時，傳入FlutterView對應的Context和創建出來的一個虛擬顯示屏對象，使得Flutter可以直接通過ID找到並使用Native創建出來的紋理數據。

2.2. View最終的顯示尺寸由誰決定？

通過上面的流程大家應該都能想到，顯示尺寸看起來像是由兩部分決定的：AndroidView的大小，Android端View的大小。那么實際上到底是有誰來決定的呢，讓我們來做一個實驗？

直接新建一個Flutter工程，並把中間改成一個AndroidView。

//Flutter class _MyHomePageState extends State<MyHomePage> { double size = 200.0; void _changeSize() { setState(() { size = 100.0; }); } @override Widget build(BuildContext context) { return new Scaffold( appBar: new AppBar( title: new Text(widget.title), ), body: Container( color: Color(0xff0000ff), child: SizedBox( width: size, height: size, child: AndroidView( viewType: 'testView', ), ), ), floatingActionButton: new FloatingActionButton( onPressed: _changeSize, child: new Icon(Icons.add), ), ); } }

在Android端也要加上對應的代碼，為了更好地看出裁切效果，這里使用ImageView。

//Android @Override public PlatformView create(final Context context, int i, Object o) { final ImageView imageView = new ImageView(context); imageView.setLayoutParams(new ViewGroup.LayoutParams(500,500)); imageView.setBackground(context.getResources().getDrawable(R.drawable.idle_fish)); return new PlatformView() { @Override public View getView() { return imageView; } @Override public void dispose() { } }; }

首先先看AndroidView，AndroidView對應的RenderObject是RenderAndroidView，而一個RenderObject的最終大小的確定是存在兩種可能，一種是由父節點所指定，還有一種是在父節點指定的范圍中根據自身情況確定大小。打開對應的源碼，可以看到其中有個很重要的屬性sizedByParent = true，也就是說AndroidView的大小是由其父節點所決定的，我們可以使用Container、SizedBox等控件控制AndroidView的大小。

AndroidView的繪圖數據是Native層所提供的，那么當Native中渲染的View的實際像素大小大於AndroidView的大小時，會發生什么呢？通常情況下，這種情況的處理思路無非就兩種選擇，一種是裁切，另一種是縮放。Flutter保持了其一貫的做法，所有out of the bounds的Widget統一使用裁切的方式進行展示，上面所描述的情況就被當作是一種out of the bounds。

當這個View的實際像素大小小於AndroidView的時候，會發現View並不會相應地變小（Container的背景色並沒有顯露出來），沒有內容的地方會被白色填充。這其中的原因是SingleViewPresentation::onCreate中，會使用一個FrameLayout作為rootView。

2.3. 觸摸事件如何傳遞

Android的事件流大家應該都很熟悉了，自頂向下傳遞，自底向上處理或回流。Flutter同樣是使用這一規則，但是其中AndroidView通過兩個類來去處理手勢：

MotionEventsDispatcher：負責將事件封裝成Native的事件並向Native傳遞；

AndroidViewGestureRecognizer：負責識別出相應的手勢，其中有兩個屬性：

cachedEvents和forwardedPointers，只有當PointerEvent的pointer屬性在forwardedPointers中時才會去進行分發，否則會存在cacheEvents中。這里的實現主要是為了解決一些事件的沖突，比如滑動事件，可以通過gestureRecognizers來進行處理，這里可以參考官方注釋。

/// For example, with the following setup vertical drags will not be dispatched to the Android view as the vertical drag gesture is claimed by the parent [GestureDetector]. /// /// GestureDetector( /// onVerticalDragStart: (DragStartDetails d) {}, /// child: AndroidView( /// viewType: 'webview', /// gestureRecognizers: <OneSequenceGestureRecognizer>[], /// ), /// ) /// /// To get the [AndroidView] to claim the vertical drag gestures we can pass a vertical drag gesture recognizer in [gestureRecognizers] e.g: /// /// GestureDetector( /// onVerticalDragStart: (DragStartDetails d) {}, /// child: SizedBox( /// width: 200.0, /// height: 100.0, /// child: AndroidView( /// viewType: 'webview', /// gestureRecognizers: <OneSequenceGestureRecognizer>[ new VerticalDragGestureRecognizer() ], /// ), /// ), /// )

所以總結起來，這部分流程總結起來其實也很簡單：事件最初從Native到Flutter這一階段不在本文的討論范圍之內，Flutter按照自己的規則去處理事件，如果AndroidView贏得了事件，事件就會被封裝成相應的Native端的事件並且通過方法通道傳回Native，Native再根據自己的處理事件的規則去處理。

3. 總結

3.1. 方案局限性

往大里說：這套方案是Google為了解決開發者日益增長的業務需求與落后的生態環境之間的矛盾而產生的，這一矛盾是一個新生態必然需要去面對的主要矛盾。為了解決這一個問題，最簡單的方式當然就是允許開發者使用老生態中已經非常成熟的控件。當然，這樣是可以臨時解決Flutter生態發展不全面的問題，但是使用這套方案不可避免的需要去編寫雙端代碼（甚至現在iOS還沒有對應的控件，當然之后肯定會更新），不能做到真正的跨端。

往小里說：這套方案存在着性能上的缺陷，在AndroidView這個類的第三句注釋中，官方就已經提到了這是一套比較昂貴的方案，避免在使用Flutter控件也能實現的情況下去使用它。如果之前有看過《Flutter外接紋理》這一文章的同學應該知道，Flutter實現外接紋理的方案中，數據從GPU->CPU->GPU的過程代價是比較大的，在大量使用的場景會造成明顯的性能缺陷。我們通過一些手段繞過了中間CPU這一步，並且將這項技術在APP中落地，用於處理圖片資源。

3.2. 實際應用

目前閑魚從Native向Flutter的遷移工作遇到了Native的本地圖片資源在Flutter側無法訪問的問題，在現在Flutter和Native必將長期共存的情況下，重新拷貝一份資源以Flutter的規則來存儲當然可以，但是不可避免地增大了包體積，而且不好管理。

面對這個問題，我們的解法便是借鑒了AndroidView使用Texture的思路並在將其優化。實現了Native和Flutter的圖片資源歸一化。除了用於加載位於Native資源目錄下的本地圖片之外，還可以利用Native的圖片庫來加載網絡圖片。

我們這么去做的原因是我們在Native側的圖片庫較為完善並且經受過大量的線上考驗，現在這一階段，我們不希望將過多的精力投入到重復造輪子這一件事上，而處理網絡圖片資源和處理本地圖片資源的思路其實是一樣的，所以我們選擇將圖片資源進行了統一地整合，在與官方的團隊進行溝通並完善后會和大家同步。

 

原文鏈接
本文為雲棲社區原創內容，未經允許不得轉載。