這是一個當前還沒開發完成的功能,準確來說連預覽版也算不上的功能。我原本以為 MAUI 是無法在 WPF 上面跑的,然而在看完了 MAUI 整個大的設計,才了解到,原來 MAUI 是一個非常龐大的開發項目。在 MAUI 里面,雖然現在是正式發布的,但正式發布的版本里面只有采用原生控件進行繪制的方案。這和官方開始的宣傳不符合,在閱讀了 MAUI 相關文檔才發現,實際上 MAUI 還有一個很大的部分,那就是自繪部分,還沒完成,代碼也分了倉庫,這就是一開始沒找到的原因。本文將告訴大家 MAUI 還沒發布的這部分大殺器
本文所涉及的全部都是繪制的渲染層,而眾所周知,一個 UI 框架最重要的兩個部分就是交互和渲染。本文僅僅只會涉及到渲染的一部分
制作一個跨平臺的 UI 框架有很多個方式,例如使用各個平臺提供的原生控件,也就是說在 Windows 平臺上,采用 WinUI 的按鈕,在 iOS 平臺上使用蘋果提供的按鈕,具體的按鈕樣式等等就需要取平臺最小集以及開放定制性,最重要的代表就是原先的 Xamarin 的方式。采用各個平臺的提供的原生控件的一個優勢在于可以獲取平臺提供的功能,更加貼合具體平臺的視覺和交互,缺點是不同的平臺的視覺效果有所差異。另一個方式是做中間較底層的自繪,基本上各個平臺都會提供自繪的能力,如 WPF 下的 DrawingContext 和 Win2D 等等,基于此方式做自繪,可以更加方便接入原有的平臺,降低原有的應用接入的成本,而這就是本文的重點。最后一個方式是做底層的自繪,使用平臺最底層的繪制邏輯,或者其他渲染框架的封裝進行二次封裝,如 Skia 或 GTK 等,對此進行渲染。使用底層的自繪邏輯可以做到更多的可控性,但缺點也在于可控性導致開發起來十分麻煩,與現有的應用接入也相對來說無法實現最好的性能
很多的 UI 框架都會采用其中的一個方式。然而別忘了 MAUI 是某軟主力做的,按照某軟的想法,那就是都要。在 MAUI 里面,既可以使用平臺提供的原生控件進行拼接制作界面,也可以使用基于的各個平臺的獨立 UI 框架提供的自繪能力繪制界面,也可以調用到底層的渲染邏輯進行渲染
但,這也不是免費的。如此大的一個項目,自然投入的成本,無論是人力還是開發周期,都是非常龐大的。盡管現在 MAUI 正式發布了,可惜還有很大部分的工作還沒完成,甚至還沒開始
在吸取了很多次失敗的教訓之后,某軟決定拆分倉庫,以解決如此大的一個項目的某些組件或部分的失敗帶來整體的失敗。這是 dotnet runtime 組的成功的例子帶來的組織形式的經驗,在 dotnet runtime 里面,將不穩定的實驗的功能放在 .NET Runtime Lab 倉庫里面。不穩定的功能,如果能成,那自然能大大提升 dotnet 的競爭力,如果不成也不應該影響到整個 dotnet 的發布
當前的 MAUI 也是這個管理方式,在 MAUI 里面,將渲染層拆出一個 Microsoft.Maui.Graphics 倉庫,如 MAUI 自定義繪圖入門?所提到的。其實 Microsoft.Maui.Graphics 是由原本的 System.Graphics 改名而來。這個 System.Graphics 項目初步完成時間比 MAUI 早很多,定位是做全平臺的繪制封裝層,提供了各個平臺的繪制渲染的上層統一。包括了兩個實現方式,一個是對各個平臺提供的 UI 框架的自繪邏輯進行封裝,從而對上層統一。另一個方式對各個底層繪制渲染邏輯包括 Skia 和 GTK 甚至是 DirectX 進行封裝,從而提供給上層統一的邏輯,只需要簡單的代碼即可切換
接下來是在有 Microsoft.Maui.Graphics 的基礎上,也就是在能提供各個平臺上層統一的繪制能力之后,進行實現各個基礎控件。這就是 Microsoft.Maui.Graphics.Controls 倉庫,這個倉庫的需求就是制作自繪的控件。如此即可實現各個平臺上像素級的統一,或者是更加方便接入原有的應用的 UI 框架
本文是在 2022.06 寫的,以上的很多功能都只是能吹不能用。但是只是寫一篇水文,那可不是我的風格。自然就是開始實際的寫代碼階段
認識我的伙伴們都知道,我對渲染是比較熟悉的。我接下來將告訴大家,如何使用 Maui 提供的框架層,配合 WPF 提供具體的自繪邏輯,兩個放在一起,從而實現 WPF 使用 MAUI 的自繪邏輯
核心的實現方法是 WPF 提供畫布功能,讓 MAUI 可以在 WPF 上面畫元素。在 MAUI 里面提供框架,以及具體的繪制指導,和上層 API 調用
本文以下部分將用到還沒有發布,但是也差不多快完成的?Microsoft.Maui.Graphics.Xaml.WPF
?提供的功能。這個庫的代碼放在 Microsoft.Maui.Graphics 倉庫,這個庫屬于做中間較底層的自繪,利用 WPF 提供的豐富的繪圖能力從而介入 MAUI 定義的抽象接口。由于此庫還沒完成,為了完成接入,我沒有使用 DLL 引用,而是拷貝了這個庫的代碼到我的測試代碼里面,然后再進行稍微的魔改,解決構建不通過
大概的對接方式如下,先在 WPF 里面放一個 Canvas 控件,這個控件將被作為 MAUI 的畫布。如此也能解答一些伙伴的疑惑,那就是 MAUI 接入 WPF 的話,能作為控件的形式接入,而不作為類似 WindowsFormsHost 的方式接入。如本文下面的代碼,只是提供一個 Canvas 控件,讓 MAUI 將內容繪制在這個 Canvas 上。如此可見 MAUI 的大的方面的設計還是很好
<Canvas x:Name="Canvas" />
在后臺代碼里面,將創建 XamlCanvas 類型的?_canvas
?字段,同時將上面代碼的 Canvas 傳入
public partial class MainWindow : Window{ public MainWindow(){InitializeComponent();_canvas.Canvas = Canvas;SizeChanged += (source, args) => Draw();} public IDrawable Drawable{ get => _drawable; set{_drawable = value;Draw();}} private void Draw(){ if (_drawable != null){ using (_canvas.CreateSession()){_drawable.Draw(_canvas, new RectF(0, 0, (float) Canvas.Width, (float) Canvas.Height));}}} private readonly XamlCanvas _canvas = new XamlCanvas(); private IDrawable _drawable;
}
以上代碼的 XamlCanvas 繼承了 ICanvas 接口。在 MAUI 的自繪里面,最重要的就是 ICanvas 接口,這是一個表示畫布的接口,在這個接口里面實現了具體的繪制的抽象 API 定義。換句話說,如果你想要接入自己想要的其他平臺,那很重要的一點就是去實現 ICanvas 的功能
以上的 XamlCanvas 是屬于庫提供的功能,將通過傳入的 Canvas 實現對接 MAUI 和 WPF 的邏輯
有了畫布之后,想要在界面繪制內容,那還需要告訴框架層想要畫出什么內容。這就是屬于業務層的內容了,在業務層里面,將需要繼承 IDrawable 接口,實現 Draw 方法。在 Draw 方法進行業務層的渲染
例如一個畫線的業務功能,可以使用如下實現方式
class DrawLines : IDrawable{ public void Draw(ICanvas canvas, RectF dirtyRect){canvas.DrawLine(50, 20.5f, 200, 20.5f);canvas.DrawLine(50, 30.5f, 200, 30.5f);}}
將 DrawLines 的對象設置給 Drawable 屬性,即可看到界面畫出線
以上的 DrawLines 就是屬于?通用 MAUI 渲染層
?的邏輯,將這段代碼拿出來,可以跑在使用其他底層渲染技術但是接入 Microsoft.Maui.Graphics 的渲染技術,例如底層換成是 Win2D 等。如此即可通過造上層的 通用 MAUI 渲染層的邏輯,從而搭建起界面效果的生態。更多自定義的繪圖,請看 MAUI 自定義繪圖入門 - lindexi - 博客園
我十分推薦大家跑一下我的 demo 從而了解到當前的 MAUI 的實現進度
本文測試代碼放在github?和?gitee?歡迎訪問
可以通過如下方式獲取本文的源代碼,先創建一個空文件夾,接著使用命令行 cd 命令進入此空文件夾,在命令行里面輸入以下代碼,即可獲取到本文的代碼
git initgit remote add origin https://gitee.com/lindexi/lindexi_gd.gitgit pull origin 8d4c37dbbde83e03a6daa4e3454a5d007c64dffe
以上使用的是 gitee 的源,如果 gitee 不能訪問,請替換為 github 的源
git remote remove origin
git remote add origin https://github.com/lindexi/lindexi_gd.git
獲取代碼之后,進入 RijoqicainejoHifolurqall 文件夾