節日獻禮:Flutter圖片庫重磅開源!
作者:閒魚技術——新宿
背景:
去年,閒魚新一代圖片庫 PowerImage 在經過一系列灰度、問題修復、程式碼調優後,已全量穩定應用於閒魚。相對於上一代 IFImage,PowerImage 經過進一步的演進,適應了更多的業務場景與最新的 flutter 特性,解決了一系列痛點:比如,因為完全拋棄了原生的 ImageCache,在與原生圖片混用的場景下,會讓一些低頻的圖片反而佔用了快取;比如,我們在模擬器上無法展示圖片;比如我們在相簿中,需要在圖片庫之外再搭建圖片通道。
簡介:
PowerImage 是一個充分利用 native 原生圖片庫能力、高擴充套件性的flutter圖片庫。我們巧妙地將外接紋理與 ffi 方案組合,以更貼近原生的設計,解決了一系列業務痛點。
能力特點:
- • 支援載入 ui.Image 能力。在基於外接紋理的方案中,使用方無法拿到真正的 ui.Image 去使用,這導致圖片庫在這種特殊的使用場景下無能為力。
- • 支援圖片預載入能力。正如原生precacheImage一樣。這在某些對圖片展示速度要求較高的場景下非常有用。
- • 新增紋理快取,與原生圖片庫快取打通!統一圖片快取,避免原生圖片混用帶來的記憶體問題。
- • 支援模擬器。在 flutter-1.23.0-18.1.pre之前的版本,模擬器無法展示 Texture Widget。
- • 完善自定義圖片型別通道。解決業務自定義圖片獲取訴求。
- • 完善的異常捕獲與收集。
- • 支援動圖。(來自淘特的PR)
Flutter 原生方案:
在介紹新方案開始之前,先簡單回憶一下 flutter 原生圖片方案。
原生 Image Widget 先通過 ImageProvider 得到 ImageStream,通過監聽它的狀態,進行各種狀態的展示。比如frameBuilder
、loadingBuilder
,最終在圖片載入成功後,會 rebuild
出 RawImage
,RawImage
會通過 RenderImage
來繪製,整個繪製的核心是 ImageInfo
中的 ui.Image
。
- • Image:負責圖片載入的各個狀態的展示,如載入中、失敗、載入成功展示圖片等。
- • ImageProvider:負責 ImageStream 的獲取,比如系統內建的 NetworkImage、AssetImage 等。
- • ImageStream:圖片資源載入的物件。
在梳理 flutter 原生圖片方案之後,我們發現是不是有機會在某個環節將 flutter 圖片和 native 以原生的方式打通?
新一代方案:
我們巧妙地將 FFi 方案與外接紋理方案組合,解決了一系列業務痛點。
FFI:
正如開頭說的那些問題,Texture 方案有些做不到的事情,這需要其他方案來互補,這其中核心需要的就是 ui.Image
。我們把 native 記憶體地址、長度等資訊傳遞給 flutter 側,用於生成 ui.Image
。
首先 native 側先獲取必要的引數(以 iOS 為例):
_rowBytes = CGImageGetBytesPerRow(cgImage); CGDataProviderRef dataProvider = CGImageGetDataProvider(cgImage); CFDataRef rawDataRef = CGDataProviderCopyData(dataProvider); _handle = (long)CFDataGetBytePtr(rawDataRef); NSData *data = CFBridgingRelease(rawDataRef); self.data = data; _length = data.length;
dart 側拿到後
@override FutureOr<ImageInfo> createImageInfo(Map map) { Completer<ImageInfo> completer = Completer<ImageInfo>(); int handle = map['handle']; int length = map['length']; int width = map['width']; int height = map['height']; int rowBytes = map['rowBytes']; ui.PixelFormat pixelFormat = ui.PixelFormat.values[map['flutterPixelFormat'] ?? 0]; Pointer<Uint8> pointer = Pointer<Uint8>.fromAddress(handle); Uint8List pixels = pointer.asTypedList(length); ui.decodeImageFromPixels(pixels, width, height, pixelFormat, (ui.Image image) { ImageInfo imageInfo = ImageInfo(image: image); completer.complete(imageInfo); //釋放 native 記憶體 PowerImageLoader.instance.releaseImageRequest(options); }, rowBytes: rowBytes); return completer.future; }
我們可以通過 ffi 拿到 native 記憶體,從而生成 ui.Image。這裡有個問題,雖然通過 ffi 能直接獲取 native 記憶體,但是由於 decodeImageFromPixels
會有記憶體拷貝,在拷貝解碼後的圖片資料時,記憶體峰值會更加嚴重。
這裡有兩個優化方向:
- 1. 解碼前的圖片資料給 flutter,由 flutter 提供的解碼器解碼,從而削減記憶體拷貝峰值。
- 2. 與 flutter 官方討論,嘗試從內部減少這次記憶體拷貝。
FFI 這種方式適合輕度使用、特殊場景使用,支援這種方式可以解決無法獲取 ui.Image 的問題,也可以在模擬器上展示圖片(flutter <= 1.23.0-18.1.pre),並且圖片快取將完全交給 ImageCache 管理。
Texture:
Texture 方案與原生結合有一些難度,這裡涉及到沒有 ui.Image
只有 textureId。這裡有幾個問題需要解決:
問題一:Image Widget 需要 ui.Image
去 build RawImage
從而繪製,這在本文前面的Flutter 原生方案介紹中也提到了。 問題二:ImageCache 依賴 ImageInfo 中 ui.Image
的寬高進行 cache 大小計算以及快取前的校驗。 問題三:native 側 texture 生命週期管理
都有解決方案:
問題一:通過自定義 Image 解決,透出 imageBuilder 來讓外部自定義圖片 widget 問題二:為 Texture 自定義 ui.image
,如下:
import 'dart:typed_data';import 'dart:ui' as ui show Image;import 'dart:ui';class TextureImage implements ui.Image { int _width; int _height; int textureId; TextureImage(this.textureId, int width, int height) : _width = width, _height = height; @override void dispose() { // TODO: implement dispose } @override int get height => _height; @override Future<ByteData> toByteData( {ImageByteFormat format = ImageByteFormat.rawRgba}) { // TODO: implement toByteData throw UnimplementedError(); } @override int get width => _width;}
這樣的話,TextureImage 實際上就是個殼,僅僅用來計算 cache 大小。 實際上,ImageCache 計算大小,完全沒必要直接接觸到 ui.Image,可以直接找 ImageInfo 取,這樣的話就沒有這個問題了。這個問題可以具體看 @皓黯 的 ISSUE 與 PR。
問題三:關於 native 側感知 flutter image 釋放時機的問題
修改的 ImageCache 釋放如下(部分程式碼):
typedef void HasRemovedCallback(dynamic key, dynamic value);class RemoveAwareMap<K, V> implements Map<K, V> { HasRemovedCallback hasRemovedCallback; ...}//------ final RemoveAwareMap<Object, _PendingImage> _pendingImages = RemoveAwareMap<Object, _PendingImage>();//------void hasImageRemovedCallback(dynamic key, dynamic value) { if (key is ImageProviderExt) { waitingToBeCheckedKeys.add(key); } if (isScheduledImageStatusCheck) return; isScheduledImageStatusCheck = true; //We should do check in MicroTask to avoid if image is remove and add right away scheduleMicrotask(() { waitingToBeCheckedKeys.forEach((key) { if (!_pendingImages.containsKey(key) && !_cache.containsKey(key) && !_liveImages.containsKey(key)) { if (key is ImageProviderExt) { key.dispose(); } } }); waitingToBeCheckedKeys.clear(); isScheduledImageStatusCheck = false; }); }
整體架構:
我們將兩種解決方案非常優雅地結合在了一起:
我們抽象出了 PowerImageProvider ,對於 external(ffi)、texture,分別生產自己的 ImageInfo 即可。它將通過對 PowerImageLoader 的呼叫,提供統一的載入與釋放能力。
藍色實線的 ImageExt 即為自定義的 Image Widget,為 texture 方式透出了 imageBuilder。
藍色虛線 ImageCacheExt 即為 ImageCache 的擴充套件,僅在 flutter < 2.2.0 版本才需要,它將提供 ImageCache 釋放時機的回撥。
這次,我們也設計了超強的擴充套件能力。除了支援網路圖、本地圖、flutter 資源、native 資源外,我們提供了自定義圖片型別的通道,flutter 可以傳遞任何自定義的引數組合給 native,只要 native 註冊對應型別 loader,比如「相簿」這種場景,使用方可以自定義 imageType 為 album ,native 使用自己的邏輯進行載入圖片。有了這個自定義通道,甚至圖片濾鏡都可以使用 PowerImage 進行展示重新整理。
除了圖片型別的擴充套件,渲染型別也可進行自定義。比如在上面 ffi 中說的,為了降低記憶體拷貝帶來的峰值問題,使用方可以在 flutter 側進行解碼,當然這需要 native 圖片庫提供解碼前的資料。
資料:
FFI vs Texture:
機型:iPhone 11 Pro;圖片:300 張網路圖;行為:在listView中手動滾動到底部再滾動到頂部;native Cache:20 maxMemoryCount; flutter Cache:30MBflutter version 2.5.3; release 模式下
這裡有兩個現象:
FFI: 186MB波動Texture: 194MB波動
在 2.5.3 版本中,Texture 方案與 FFI,在記憶體水位上差異不大,記憶體波動上面與 flutter 1.22 結論相反。
圖中棋格圖,為開啟 checkerboardRasterCacheImages
後所展示,可以看出,ffi方案會快取整個cell,而texture方案,只有cell中的文字被快取,RasterCache 會使得 ffi 在流暢度方面會有一定優勢。
滾動流暢性分析:
裝置: Android OnePlus 8t,CPU和GPU進行了鎖頻。case: GridView每行4張圖片,300張圖片,從上往下,再從下往上,滑動幅度從500,1000,1500,2000,2500,5輪滑動。重複20次。方式: for i in {1..20}; do flutter drive --target=test_driver/app.dart --profile; done 跑資料,獲取TimeLine資料並分析。
結論:
- • UI thread 耗時 texture 方式最好,PowerImage 略好於 IFImage,FFI方式波動比較大。
- • Raster thread 耗時 PowerImage 好於 IFImage。Origin 原生方式好是因為對圖片 resize了,其他方式載入的是原圖。
更精簡的程式碼:
dart 側程式碼有較大幅度的減少,這歸功於技術方案貼合 flutter 原生設計,我們與原生圖片共用較多程式碼。
FFI 方案補全了外接紋理的不足,遵循原生 Image 的設計規範,不僅讓我們享受到 ImageCache 帶來的統一管理,也帶來了更精簡的程式碼。
單測:
為了保證核心程式碼的穩定性,我們有著較為完善的單測,行覆蓋率接近95%。
關於開源:
我們期待通過社群的力量讓 PowerImage 更加完善與強大,也希望 PowerImage 能為大家在工程研發中帶來收益。
Issues:
關於 issue,我們希望大家在使用 PowerImage 遇到問題與訴求時,積極交流,提出 issue 時儘可能提供詳細的資訊,以減少溝通成本。在提出 issue 前,請確保已閱讀 readme。
對於 bug 的 issue,我們自定義了模板(Bug report),可以方便地填一些必要的資訊。其他型別則可以選擇 Open a blank issue
。
我們每週會花部分時間統一處理 issues,也期待大家的討論與 PR。
PR:
為了保持 PowerImage 核心功能的穩定性,我們有著完善的單測,行覆蓋率達到了 95%(power_image庫)。
在提交PR時,請確保所提交的程式碼被單測覆蓋到,並且涉及到的單測程式碼請同時提交。
得益於 Github 的 Actions 能力,我們在主分支 push 程式碼、對主分支進行 PR 操作時,都會觸發 flutter test
任務,只有單測通過才可合入。
未來:
開源是 PowerImage 的開始,而不是結束,PowerImage 可做的事情還有很多,有趣而豐富。比如第一個 issue 中描述的 loadingBuilder
如何實現?比如 ffi 方案如何支援動圖?再比如Kotlin和Swift···
PowerImage 未來將持續演進,在當前 texture 方案與 ffi 方案共存的情況下,伴隨著 flutter 本身的迭代,我們將更傾向於向 ffi 發展,正如在上文的對比中, ffi 方案可以天然享用 raster cache 所帶來的流暢度的優勢。
PowerImage 也會持續追隨 flutter 的腳步,以始終貼合原生的設計理念,不斷進步,我們希望更多的同學加入進來,共同成長。
其他四個Flutter開源專案: 閒魚技術公眾號-閒魚開源
PowerImage相關連結:
GitHub:(✅star🌟)
http://github.com/alibaba/power_image
Flutter pub:(✅like👍)
http://pub.dev/packages/power_image
- Kraken中事件通道原理分析
- 我在閒魚做搭建——魔魚搭投編輯器介紹
- Flutter富文字編輯器系列文章3——互動篇
- Flutter富文字編輯器系列文章3——互動篇
- 打造Flutter高效能富文字編輯器——渲染篇
- 節日獻禮:Flutter圖片庫重磅開源!
- 節日獻禮:Flutter圖片庫重磅開源!
- 關於閒魚測試資料構造,我有幾條心得
- 關於閒魚測試資料構造,我有幾條心得
- 打造Flutter高效能富文字編輯器——協議篇
- 打造Flutter高效能富文字編輯器——協議篇
- 閒魚前端技術體系的背後——魔魚(良心推薦,從思路到實踐)
- 閒魚如何保障交易鏈路質量
- Flutter 音影片開發的新思路
- 實效性與準確性的背後:多系統資料聚合展示
- Flutter滑動體驗對齊原生-滑動曲線篇
- 閒魚搜尋-成交寬度優化實踐
- 閒魚策略中樞業務擴充套件模組實現
- 閒魚互動玩法標準化建設
- 一條慢SQL引發的改造