Arbeiten mit WebAssembly und C#: Fortgeschrittenes Niveau in .NET

Einführung in WebAssembly und C#: Von der Theorie zur Praxis

WebAssembly (WASM) ist zum Standard für leistungsstarke Webanwendungen geworden. Das .NET-Ökosystem bietet leistungsstarke Werkzeuge zur Kompilierung von C#-Code in WASM und eröffnet Möglichkeiten zur Übertragung komplexer Algorithmen, Bibliotheken und sogar ganzer Frameworks in den Browser. Auf fortgeschrittenem Niveau erfordert die Arbeit mit WebAssembly und C# nicht nur ein Verständnis der grundlegenden Kompilierung, sondern auch der Feinheiten der Speicherverwaltung, der Interaktion mit JavaScript (JS Interop), der Optimierung der Binärdateigröße und des Debuggings.

In diesem Artikel betrachten wir die wichtigsten Aspekte, die es Ihnen ermöglichen, über einfache Beispiele hinauszugehen und effiziente, skalierbare WASM-Anwendungen in C# zu erstellen.

1. Kompilierung und Bereitstellung von .NET in WebAssembly: Fortgeschrittene Methoden

Für die Kompilierung von C# in WASM wird die Mono/WASM-Laufzeitumgebung verwendet, die in Blazor WebAssembly integriert oder über .NET WASM Build Tools verfügbar ist. Auf fortgeschrittenem Niveau ist es wichtig, den Build-Prozess zu kontrollieren.

1.1. Optimierung der Build-Größe und AOT-Kompilierung

Standardmäßig verwendet Blazor die JIT-Kompilierung innerhalb der WASM-Umgebung, was zum Laden der vollständigen Mono-Umgebung führt (~2-3 MB komprimiert). Zur Größenreduzierung kann die AOT (Ahead-of-Time) Kompilierung verwendet werden. Sie kompiliert Ihren C#-Code direkt in WASM-Anweisungen und macht JIT überflüssig.

<!-- In der .csproj-Datei -->\n<PropertyGroup>\n  <RunAOTCompilation>true</RunAOTCompilation>\n  <WasmDebugLevel>0</WasmDebugLevel>\n  <WasmNativeStrip>true</WasmNativeStrip>\n</PropertyGroup>

Allerdings erhöht AOT die Build-Zeit und die Größe der resultierenden Datei (reduziert aber die Größe der geladenen Umgebung). Konfigurieren Sie WasmDebugLevel und WasmNativeStrip, um Debug-Informationen zu entfernen.

1.2. Lazy Loading und Aufteilung von Assemblies

Für große Anwendungen verwenden Sie Lazy Loading. Sie können .NET-Bibliotheken nur bei Bedarf laden. In Blazor geschieht dies über LazyAssemblyLoader:

@inject LazyAssemblyLoader Loader\n\n@code {\n    private async Task LoadHeavyLibrary()\n    {\n        var assemblies = await Loader.LoadAssembliesAsync(new[] { "HeavyLibrary.dll" });\n        // Jetzt ist die Bibliothek verfügbar\n    }\n}

Dies ist entscheidend für SEO und UX, da der Initial Load schnell bleibt.

2. Interaktion mit JavaScript (JS Interop) auf tiefer Ebene

Fortgeschrittene Arbeit mit WebAssembly erfordert einen effizienten Datenaustausch zwischen C# und JS. Der Standard-IJSRuntime arbeitet über JSON-Serialisierung, was bei großen Datenmengen langsam ist.

2.1. Direkte Arbeit mit Speicher über Span und IntPtr

Verwenden Sie System.Runtime.InteropServices.JavaScript (verfügbar in .NET 7+). Sie können Zeiger auf JS-Arrays erhalten und direkt damit arbeiten, wodurch Kopieren vermieden wird.

using System.Runtime.InteropServices.JavaScript;\n\n// Export einer C#-Funktion nach JS\n[JSExport]\npublic static unsafe int ProcessData(int* dataPtr, int length)\n{\n    Span<byte> span = new Span<byte>(dataPtr, length);\n    // Hochleistungsverarbeitung direkt vor Ort\n    return span.Length;\n}\n\n// Import einer Funktion aus JS\n[JSImport("window.processResult", "MyModule")]\npublic static partial void ProcessResult(int result);

Dieser Ansatz ermöglicht die Verarbeitung von Bildern, Audio oder großen Datenarrays (z. B. aus WebGL) ohne Mehraufwand durch Marshalling.

2.2. Synchroner JS Interop

Standardmäßig sind JS-Aufrufe aus WASM asynchron. Für Szenarien, die Synchronität erfordern (z. B. in Spielschleifen), verwenden Sie [JSImport] mit IsBlocking = true (verfügbar in .NET 8+). Dies blockiert den WASM-Thread, bis eine Antwort von JS eingeht.

[JSImport("getTimestamp", "MyModule", IsBlocking = true)]\npublic