Architektur im Überblick - tauri-apps/tauri

Quelldateien

Diese Seite wurde aus den folgenden Quelldateien erstellt:

Tauri ist ein polyglottes und generisches Toolkit zur Entwicklung von Desktop-Anwendungen, das Rust-Tools mit HTML-Rendering in einem Webview kombiniert (ARCHITECTURE.md:7-17). Die Architektur zeichnet sich durch eine klare Trennung zwischen Backend (Rust) und Frontend (Webview) aus, wobei die Kommunikation über Message Passing erfolgt. Im Gegensatz zu anderen Ansätzen verwendet Tauri weder einen VM-Layer noch einen Kernel-Wrapper, sondern nutzt direkt die externen Crates TAO für Window-Management und WRY für Webview-Integration (ARCHITECTURE.md:75-87).

Systemarchitektur Gesamtübersicht

Die Tauri-Architektur gliedert sich in drei Hauptebenen: Core-Rust-Module, externe Runtime-Crates und Tooling-Komponenten. Das Herzstück bildet der tauri-Crate, der alle Komponenten zusammenführt und die Konfiguration aus tauri.conf.json zur Kompilierzeit einliest (ARCHITECTURE.md:18-52). Die Runtime-Abstraktionsschicht (tauri-runtime und tauri-runtime-wry) entkoppelt die Kernlogik von plattformspezifischen Implementierungen.

正在加载图表渲染器...

Erklärung der Architekturkomponenten:

Frontend Layer: Der Webview rendert die UI, während @tauri-apps/api die TypeScript-Schnittstelle für Backend-Kommunikation bereitstellt
Tauri Core: Zentrale Rust-Module, die Konfiguration, Asset-Management und Makros bereitstellen (crates/tauri/src/lib.rs:270-295)
Runtime Layer: Abstraktionsschicht mit Trait-Definitionen und konkreter WRY-Implementierung für plattformspezifische Aufrufe
Externe Crates: TAO und WRY übernehmen die direkte Kommunikation mit dem Betriebssystem
Tooling: CLI-Tools für Entwicklung und Build-Prozess

Tauri Core Komponenten

tauri Crate

Der tauri-Crate fungiert als zentrale Integrationskomponente, die Runtime, Makros, Utilities und API zum finalen Produkt zusammenführt. Er liest die tauri.conf.json-Datei zur Kompilierzeit ein und konfiguriert die Anwendung basierend auf den dort definierten Einstellungen (ARCHITECTURE.md:18-52). Die Hauptverantwortlichkeiten umfassen:

Script-Injection: Polyfills und Prototyp-Revision zur Laufzeit
API-Hosting: Schnittstelle für Systeminteraktionen
Update-Management: Verwaltung von Application-Updates

rust
1// Runtime-Trait-Definition (crates/tauri/src/lib.rs:270-275)
2pub trait Runtime: runtime::Runtime<EventLoopMessage> {}
3pub trait RuntimeHandle: runtime::RuntimeHandle<EventLoopMessage> {}
4
5impl<W: runtime::Runtime<EventLoopMessage>> Runtime for W {}
6impl<R: runtime::RuntimeHandle<EventLoopMessage>> RuntimeHandle for R {}

Die Context-Struktur kapselt alle erforderlichen Konfigurationen und Assets für die Anwendung (crates/tauri/src/lib.rs:270-295).

tauri-codegen und tauri-build

tauri-codegen übernimmt die Asset-Verarbeitung zur Kompilierzeit:

Embedding, Hashing und Komprimierung von Assets (inklusive Icons und System-Tray)
Parsen von tauri.conf.json und Generierung der Config-Struktur

tauri-build wendet Makros zur Build-Zeit an, um spezielle Features für cargo zu konfigurieren (ARCHITECTURE.md:18-52).

App-Struktur und Manager

Die App-Struktur repräsentiert die laufende Anwendungsinstanz und implementiert das Manager-Trait für die Manipulation globaler Anwendungselemente (crates/tauri/src/app.rs:661-688).

rust
1// App-Struktur (crates/tauri/src/app.rs:665-671)
2pub struct App<R: Runtime> {
3  runtime: Option&lt;R&gt;,
4  setup: Option<SetupHook&lt;R&gt;>,
5  manager: Arc<AppManager&lt;R&gt;>,
6  handle: AppHandle&lt;R&gt;,
7  ran_setup: bool,
8}

Kernkomponenten der App-Struktur:

runtime: Optionale Runtime-Instanz für direkten Zugriff
manager: Arc-wrapped AppManager für Thread-sichere Verwaltung
handle: Handle für Runtime-Operationen ohne Ownership

Runtime und Systemintegration

Runtime-Trait-Definitionen

Das tauri-runtime-Crate definiert die abstrakten Traits für Runtime-Operationen und entkoppelt so die Kernlogik von plattformspezifischen Implementierungen (crates/tauri-runtime/src/lib.rs:303-335). Die wichtigsten Methoden umfassen:

Methode	Beschreibung	Rückgabewert
`primary_monitor()`	Liefert den primären Monitor	`Option<Monitor>`
`available_monitors()`	Liste aller verfügbaren Monitore	`Vec<Monitor>`
`cursor_position()`	Aktuelle Cursor-Position	`Result<PhysicalPosition<f64>>`
`set_theme()`	Setzt das App-Theme	`void`

rust
1// Runtime-Methoden (crates/tauri-runtime/src/lib.rs:303-315)
2fn primary_monitor(&self) -> Option<Monitor>;
3fn monitor_from_point(&self, x: f64, y: f64) -> Option<Monitor>;
4fn available_monitors(&self) -> Vec<Monitor>;
5fn cursor_position(&self) -> Result<PhysicalPosition&lt;f64&gt;>;
6fn set_theme(&self, theme: Option<Theme>);

WRY-Implementierung

tauri-runtime-wry implementiert die Runtime-Traits spezifisch für WRY und ermöglicht direkte Systeminteraktionen wie Drucken, Monitor-Erkennung und Window-Management (crates/tauri-runtime-wry/src/lib.rs:1018-1060). Die Window-Builder-Methoden setzen die plattformspezifischen Eigenschaften:

rust
1// Window-Builder-Implementierung (crates/tauri-runtime-wry/src/lib.rs:1018-1037)
2fn maximizable(mut self, maximizable: bool) -> Self {
3  self.inner = self.inner.with_maximizable(maximizable);
4  self
5}
6
7fn title<S: Into<String>>(mut self, title: S) -> Self {
8  self.inner = self.inner.with_title(title.into());
9  self
10}

Asynchrone Runtime-Verwaltung

Das async_runtime-Modul verwaltet die asynchrone Ausführung von Tasks und unterstützt sowohl Tokio als auch async-std (crates/tauri/src/async_runtime.rs:30-68).

rust
1// GlobalRuntime-Struktur (crates/tauri/src/async_runtime.rs:31-43)
2struct GlobalRuntime {
3  runtime: Option<Runtime>,
4  handle: RuntimeHandle,
5}
6
7impl GlobalRuntime {
8  fn handle(&self) -> RuntimeHandle {
9    if let Some(r) = &self.runtime {
10      r.handle()
11    } else {
12      self.handle.clone()
13    }
14  }
15}

Fehlerbehandlung in der async_runtime:

spawn() und spawn_blocking() prüfen auf vorhandene Runtime-Instanz
Bei fehlender Runtime wird der Handle direkt verwendet
block_on() ermöglicht synchrone Ausführung asynchroner Tasks

Datenfluss und Kommunikationssequenz

Der folgende Sequenzdiagramm zeigt den typischen Datenfluss von einem Frontend-Event bis zur Systemoperation:

正在加载图表渲染器...

Erklärung der Datenflussphasen:

Event-Auslösung: Benutzerinteraktion im Webview löst JavaScript-Event aus
IPC-Kommunikation: @tauri-apps/api serialisiert Daten und sendet über Message Passing an Rust-Backend
Command-Processing: Tauri Core deserialisiert und ruft registrierte Command-Handler auf
Runtime-Delegation: Trait-basierte Abstraktion ermöglicht Plattform-Unabhängigkeit
System-Execution: WRY und TAO führen die tatsächlichen Betriebssystem-Aufrufe durch

Tooling und Entwicklungsworkflow

CLI-Architektur

Das Tauri-Tooling besteht aus zwei Hauptkomponenten:

@tauri-apps/cli: JavaScript-Wrapper für NPM-Pakete, verwendet napi-rs für plattformübergreifende Binaries
tauri-cli: Rust-Executable mit vollständiger CLI-Funktionalität (ARCHITECTURE.md:53-74)

Entwicklungsworkflow

Der Entwicklungsprozess startet mit npm create tauri-app, das ein vollständiges Projektgerüst erstellt (ARCHITECTURE.md:120-157). Der tauri dev-Befehl führt folgende Schritte aus:

Start des JS-Framework-Devservers
Download und Kompilierung der Rust-Bibliotheken
Öffnen eines Anwendungsfensters mit aktivierten DevTools
Hot-Module-Replacement für Frontend-Änderungen

Bei Änderungen an Rust-Code oder Cargo.toml schließt das Fenster während der Rekompilierung und lädt danach neu.

Release- und Update-Mechanismen

Der Release-Flow beginnt mit der Konfiguration in tauri.conf.json, die sowohl Basisverhalten als auch Signing- und Update-Einstellungen definiert (ARCHITECTURE.md:165-188). Der Build-Prozess mit pnpm tauri build erstellt plattformspezifische Binaries im ./src-tauri/target/release-Verzeichnis.

Update-Flow:

Entwickler veröffentlicht signierte Artefakte auf konfiguriertem Server
Anwendung pollt den Server auf neue Releases
Bei neuer Version: Download, Verifikation (Checksum & Signatur)
Update, Schließen und Neustart der Anwendung

Konfiguration und Utilities

Konfigurationsstruktur

Die Konfiguration erfolgt über tauri.conf.json mit Unterstützung für verschiedene Bundle-Formate und Plattformen (crates/tauri-utils/src/config.rs:690-733). Die WiX-Konfiguration für Windows-Installer unterstützt beispielsweise:

rust
1// WiX-Language-Konfiguration (crates/tauri-utils/src/config.rs:700-722)
2pub struct WixLanguageConfig {
3  pub locale_path: Option<String>,
4}
5
6pub enum WixLanguage {
7  One(String),
8  List(Vec<String>),
9  Localized(HashMap<String, WixLanguageConfig>),
10}

MIME-Type-Handling

Das mime_type-Modul stellt Funktionen zum Parsen und Konvertieren von URI-Suffixen in korrekte MIME-Types bereit (crates/tauri-utils/src/mime_type.rs:13-51).

rust
1// MIME-Type-Definitionen (crates/tauri-utils/src/mime_type.rs:13-26)
2pub enum MimeType {
3  Css,
4  Csv,
5  Html,
6  Ico,
7  Js,
8  Json,
9  Jsonld,
10  Mp4,
11  OctetStream,
12  Rtf,
13  Svg,
14  Txt,
15}

Die parse_from_uri-Methode konvertiert Dateierweiterungen in Web-kompatible MIME-Types mit Fallback auf text/html.

Environment-Erkennung

Das Env-Struct kapselt Umgebungsvariablen und bietet AppImage-Erkennung für Linux (crates/tauri-utils/src/lib.rs:263-314).

rust
1// Environment-Struktur (crates/tauri-utils/src/lib.rs:264-275)
2pub struct Env {
3  #[cfg(target_os = "linux")]
4  pub appimage: Option<std::ffi::OsString>,
5  #[cfg(target_os = "linux")]
6  pub appdir: Option<std::ffi::OsString>,
7  pub args_os: Vec<OsString>,
8}

AppImage-Validierung:

Prüft APPIMAGE und APPDIR Umgebungsvariablen
Validiert, ob die Anwendung tatsächlich von einem temporären Mount-Pfad läuft
Gibt Warnung aus, wenn Variablen ohne gültiges AppImage gefunden werden

Modulabhängigkeiten und Abstraktionsschichten

正在加载图表渲染器...

Abhängigkeitsrichtungen:

Abwärts: Anwendung → Runtime-Trait → Konkrete Implementierung → OS
Aufwärts: Utility-Module werden von allen Ebenen genutzt
Querbewegungen: Manager und Runtime kommunizieren über definierte Traits

Technologie-Stack und Design-Entscheidungen

Technologie	Verwendungszweck	Begründung	Alternativen
Rust	Backend-Logik	Speichersicherheit, Performance, kleine Binaries	C++, Go
Webview	Frontend-Rendering	OS-native Rendering, kleine Bundle-Größe	Electron (Chromium)
TAO	Window-Management	Fork von winit mit erweiterten Features	winit, glutin
WRY	Webview-Abstraktion	Plattformübergreifende API	WebKitGTK direkt
Tokio	Async Runtime	Industriestandard, Feature-Reichtum	async-std
serde	Serialisierung	Zero-Cost Abstraktion, Derive-Macros	miniserde
napi-rs	Node-Bindings	Typsichere FFI, Performance	neon
WiX	Windows-Installer	Weite Verbreitung, Anpassbarkeit	NSIS, Inno Setup

Kern-Design-Entscheidungen:

Keine Runtime-Mitlieferung: Rust-Kompilierung erzeugt native Binaries ohne zusätzliche Runtime-Abhängigkeiten
OS-Webview-Nutzung: Reduziert Bundle-Größe signifikant im Vergleich zu Chromium-basierten Lösungen
Trait-basierte Runtime-Abstraktion: Ermöglicht Austauschbarkeit der Backend-Implementierung
Message Passing für IPC: Sichere Kommunikation zwischen Frontend und Backend
Kompilierzeit-Konfiguration: Performance-Optimierung durch statische Einbettung von Assets

Kernmodule im Detail

Runtime-Trait-System

Das Runtime-Trait-System definiert die Schnittstelle zwischen Tauri Core und plattformspezifischen Implementierungen. Die Traits Runtime und RuntimeHandle abstrahieren die Event-Loop-Verwaltung und Window-Operationen (crates/tauri/src/lib.rs:270-275).

Verantwortlichkeiten:

Event-Loop-Management mit benutzerdefinierten Events
Window-Erstellung und -Konfiguration
Monitor- und Cursor-Abfragen
Theme- und Appearance-Einstellungen

Fehlerbehandlung:

Alle Methoden returnen Result<T> für explizite Fehlerbehandlung
Plattformspezifische Methoden sind mit #[cfg(target_os)] markiert
Fallback-Implementierungen für nicht unterstützte Plattformen

Context-Generierung

Die Context-Struktur wird entweder durch das generate_context!-Makro oder durch tauri-build erzeugt (crates/tauri/src/lib.rs:277-309).

rust
1// Context-Erstellung (crates/tauri/src/lib.rs:490-517)
2pub fn new(
3  config: Config,
4  assets: Box<dyn Assets&lt;R&gt;>,
5  default_window_icon: Option<image::Image<'static>>,
6  app_icon: Option<Vec&lt;u8&gt;>,
7  package_info: PackageInfo,
8  pattern: Pattern,
9  runtime_authority: RuntimeAuthority,
10  plugin_global_api_scripts: Option<&'static [&'static str]>,
11) -> Self

Kernkomponenten des Context:

config: Geparste Konfiguration aus tauri.conf.json
assets: Eingebettete und komprimierte Assets
runtime_authority: Berechtigungssystem für API-Aufrufe
pattern: Sicherheitspattern (z.B. Isolation)

Async-Runtime-Integration

Die asynchrone Runtime ermöglicht nicht-blockierende Operationen und unterstützt sowohl Tokio als auch async-std (crates/tauri/src/async_runtime.rs:30-68).

API-Methoden:

spawn(): Startet asynchronen Task
spawn_blocking(): Führt blockierenden Code in separatem Thread aus
block_on(): Blockiert aktuellen Thread bis Task abgeschlossen
handle(): Liefert Handle für Task-Spawning ohne Runtime-Ownership

Default-Runtime:

rust
1// Default-Runtime-Initialisierung (crates/tauri/src/async_runtime.rs:213-220)
2fn default_runtime() -> GlobalRuntime {
3  let runtime = Runtime::Tokio(TokioRuntime::new().unwrap());
4  let handle = runtime.handle();
5  GlobalRuntime {
6    runtime: Some(runtime),
7    handle,
8  }
9}

Startup-Sequenz und Initialisierung

正在加载图表渲染器...

Initialisierungsphasen:

Builder-Konfiguration: Registrierung von Plugins, State und Event-Handlern
Context-Generierung: Parsen der Konfiguration und Einbetten der Assets zur Kompilierzeit
Runtime-Instanziierung: Erstellung der plattformspezifischen Runtime
App-Erstellung: Initialisierung der App-Struktur mit Manager und Handle
Setup-Hook: Ausführung benutzerdefinierter Initialisierungslogik
Event-Loop-Start: Beginn der Haupt-Event-Verarbeitung