HarmonyOS: Was es ist, Systemarchitektur und Entwicklung mit ArkUI

Was ist HarmonyOS?

HarmonyOS ist ein verteiltes Betriebssystem, das von Huawei entwickelt und erstmals 2019 als Reaktion auf die eingeschränkte Verfügbarkeit von Google-Diensten auf neuen Geräten des Unternehmens angekündigt wurde. HarmonyOS basiert auf einem eigenen Mikrokernel (nicht Linux) und ist für die nahtlose Zusammenarbeit zwischen Geräten konzipiert: Smartphones, Tablets, Smartwatches, Fernseher, Fahrzeugsysteme und IoT-Geräte.

Laut Huawei (HarmonyOS Ecosystem Report, 2026) ist das System auf über 700 Millionen Geräten installiert, darunter 300 Millionen Smartphones. Der chinesische Markt macht 95% der Installationen aus. Ab HarmonyOS 5.0 (NEXT, 2024) hat das System die Android-AOSP-Kompatibilität vollständig aufgegeben — alle Anwendungen müssen in ArkTS oder C++ mit ArkUI geschrieben werden.

Das Hauptmerkmal von HarmonyOS ist seine verteilte Architektur: Eine Anwendung kann gleichzeitig auf mehreren Geräten ausgeführt werden und die Benutzeroberfläche zwischen Bildschirmen verschieben. Beispielsweise startet ein Benutzer die Navigation auf dem Telefon, während die Benutzeroberfläche auf dem Auto-Bildschirm angezeigt wird — ohne Neukompilierung oder zusätzlichen Code.

Versionsgeschichte von HarmonyOS

HarmonyOS 1.0 (2019) — erste Version für Smart Screen, nicht für Smartphones. HarmonyOS 2.0 (2021) — für Smartphones, Tablets und Uhren geöffnet, Unterstützung für AOSP-Anwendungen. HarmonyOS 3.0 (2022) — verbesserte verteilte Architektur, Super Device, Multiscreen Collaboration. HarmonyOS 4.0 (2023) — ArkUI 3.0, Live View, verbesserte Leistung. HarmonyOS NEXT (5.0, 2024) — vollständige Aufgabe von AOSP, nur native HarmonyOS-Anwendungen.

HarmonyOS-Architektur: Verteilter Mikrokernel

Die HarmonyOS-Architektur unterscheidet sich grundlegend von Android und iOS. Anstelle des monolithischen Linux-Kernels verwendet HarmonyOS einen eigenen Mikrokernel, der einen minimalen Satz privilegierter Funktionen implementiert: Speicherverwaltung, Prozessplanung und Interprozesskommunikation. Alle anderen Dienste laufen im Benutzermodus.

Mikrokernel und Sicherheit

Der HarmonyOS-Mikrokernel umfasst etwa 10.000 Codezeilen (der Linux-Kernel hat über 20 Millionen). Eine kleinere Codebasis bedeutet eine kleinere Angriffsfläche. Das System verwendet formale Verifikation — den mathematischen Nachweis der Korrektheit des Kernel-Codes. HarmonyOS unterstützt Trusted Execution Environment (TEE) auf Hardwareebene für Biometrie, Zahlungen und Verschlüsselungsschlüssel. Die Interprozesskommunikation erfolgt über IPC, das 5-mal leistungsfähiger ist als Binder in Android.

Vier Architekturebenen

Die HarmonyOS-Architektur besteht aus vier Ebenen: Kernel Subsystem (Mikrokernel + Treiber), System Service Layer (Systemdienste: verteilte Daten, Dateisystem, Sicherheit), Framework Layer (ArkUI, Multimedia, Telefonie, KI-Dienste) und Application Layer (Benutzeranwendungen). Jede Ebene ist über IPC von der darunterliegenden Ebene isoliert.

Verteiltes Dateisystem

HarmonyOS bietet ein verteiltes Dateisystem (DFS), das den Speicher aller Benutzergeräte in einem einzigen virtuellen Raum vereint. Eine Anwendung greift über URI auf Dateien zu, ohne ein Gerät anzugeben — das System leitet die Anfrage an das Gerät weiter, auf dem die Datei physisch gespeichert ist. DFS unterstützt Ende-zu-Ende-Verschlüsselung und automatische Replikation häufig genutzter Daten.

// Arbeiten mit dem verteilten Dateisystem von HarmonyOS
#include <dfs/storage_manager.h>
#include <uri/uri_helper.h>

using namespace OHOS::Storage;

// Abrufen einer Datei-URI auf einem verteilten Gerät
Uri GetDistributedFileUri(const std::string& localPath) {
    DistributedFileManager manager;
    auto deviceList = manager.GetOnlineDevices();

    for (const auto& device : deviceList) {
        Uri uri = manager.GetFileUri(device.deviceId, localPath);
        if (uri.IsValid()) {
            return uri;  // Datei auf einem der Geräte gefunden
        }
    }
    return Uri::Empty();
}

// Lesen von Daten von einem entfernten Gerät
std::string ReadDistributedFile(const Uri& uri) {
    DistributedFile file(uri);
    if (!file.Open(OpenMode::READ_ONLY)) {
        return "";
    }

    char buffer[4096];
    size_t bytesRead = file.Read(buffer, sizeof(buffer));
    file.Close();

    return std::string(buffer, bytesRead);
}

Im Beispiel sucht DistributedFileManager eine Datei auf allen Online-Geräten des Benutzers und gibt eine verteilte URI zurück. DistributedFile öffnet die Datei physisch auf dem entfernten Gerät über IPC, transparent für die Anwendung. Der Entwickler muss nicht wissen, wo die Daten gespeichert sind — das System leitet die Anfrage automatisch weiter.

ArkUI und ArkTS: Schnittstellenentwicklung

ArkUI ist das deklarative UI-Framework von HarmonyOS, entwickelt von Huawei. Die Benutzeroberfläche wird als Hierarchie von Komponenten mit reaktiver Datenbindung beschrieben, ähnlich wie SwiftUI (iOS) oder Jetpack Compose (Android). ArkTS ist eine auf TypeScript basierende Entwicklungssprache mit zusätzlicher statischer Typisierung und Integration mit ArkUI über die Decorators @Component, @State, @Prop, @Link.

Grundlegende ArkTS-Konzepte

ArkTS erweitert TypeScript durch Harmonisierung mit dem UI-Framework: @Component — ein Decorator zur Deklaration einer UI-Komponente, build() — eine obligatorische Methode, die einen Baum von UI-Elementen zurückgibt, @State — eine reaktive Variable, deren Änderungen die Komponente automatisch neu zeichnen, @Prop — eine Eingabeeigenschaft vom übergeordneten Element, @Link — bidirektionale Bindung. Alle ArkUI-Komponenten verwenden eine Verkettungssyntax mit Modifikatoren (.width, .height, .backgroundColor).

// ArkTS — Benutzerprofilbildschirm auf ArkUI
@Component
struct ProfileScreen {
    @State userName: string = "Anna Petrova";
    @State avatarUrl: Resource = $r("media.avatar_default");
    @State isLoading: boolean = false;
    @Prop onEditClick: () => void;

    aboutToAppear(): void {
        this.loadUserData();
    }

    async loadUserData(): Promise<void> {
        this.isLoading = true;
        try {
            const data = await UserService.getProfile();
            this.userName = data.name;
            this.avatarUrl = data.avatarUrl;
        } catch (error) {
            console.error("Ladefehler", error);
        } finally {
            this.isLoading = false;
        }
    }

    build(): void {
        Column() {
            if (this.isLoading) {
                LoadingProgress()
                    .width('50%')
                    .height('50%');
            } else {
                Stack({ alignContent: Alignment.Center }) {
                    Image(this.avatarUrl)
                        .width('100%')
                        .height('100%')
                        .objectFit(ImageFit.Cover);

                    Column() {
                        Text(this.userName)
                            .fontSize('24fp')
                            .fontWeight(FontWeight.Bold)
                            .fontColor(Color.White);

                        Button("Bearbeiten", {
                            type: ButtonType.Capsule,
                            stateEffect: true
                        })
                            .onClick(() => {
                                this.onEditClick();
                            })
                            .margin({ top: '12vp' });
                    }
                    .alignItems(HorizontalAlign.Center)
                    .width('100%');
                }
                .width('100%')
                .height('300vp');
            }
        }
        .padding('16vp')
        .width('100%')
        .height('100%');
    }
}

// Anwendungseinstiegspunkt
@Entry
@Component
struct MainApp {
    build(): void {
        Column() {
            ProfileScreen({
                onEditClick: () => {
                    console.info("Profileditor öffnen");
                }
            });
        }
        .width('100%')
        .height('100%');
    }
}

Die ProfileScreen-Komponente in ArkTS demonstriert: @State für reaktive Variablen, @Prop für Eingabe-Callback, Column/Stack/Text/Image/Button als grundlegende UI-Komponenten, asynchrones Datenladen über async/await. LoadingProgress wird während des Ladens angezeigt. Alle Größen werden in vp (virtuellen Pixeln) angegeben — adaptiven Einheiten ähnlich pt in iOS oder dp in Android.

Anpassung an verschiedene Geräte

ArkUI unterstützt responsives Design durch ein Breakpoint-System (xs, sm, md, lg, xl), das der Bildschirmbreite entspricht. Komponenten werden beim Wechsel von Telefon zu Tablet oder Uhr automatisch neu angeordnet. GridRow und GridCol sind adaptive Container, die die Anzahl der Spalten je nach Breakpoint ändern. Größeneinheiten: vp (virtuelle Pixel), fp (Schriftpixel — skalieren mit Schriftarteinstellungen), lpx (logische Pixel für Uhren).

DevEco Studio und Entwicklungswerkzeuge

DevEco Studio ist die offizielle integrierte Entwicklungsumgebung (IDE) für HarmonyOS, basierend auf IntelliJ IDEA Community Edition. Sie enthält einen Code-Editor mit ArkTS- und C++-Unterstützung, einen visuellen ArkUI-Editor (Drag-and-Drop), einen HarmonyOS-Geräteemulator, Preview für die sofortige UI-Anzeige und Profiler für die Leistungsanalyse.

HarmonyOS-Emulator

DevEco Studio enthält einen auf QEMU basierenden Emulator, der Smartphones (verschiedene Bildschirmgrößen), Tablets, Uhren und Fernseher unterstützt. Der Emulator simuliert eine verteilte Umgebung: Sie können mehrere virtuelle Geräte ausführen und die geräteübergreifende Interaktion testen. Der Emulator benötigt Virtualisierung (Hyper-V unter Windows, KVM unter Linux).

Preview und Live Preview

ArkUI Preview ist eine Funktion zur sofortigen UI-Anzeige ohne Build oder Emulatorstart. Codeänderungen werden innerhalb von 1-2 Sekunden im Preview angezeigt. Alle Standardkomponenten und Animationen werden unterstützt. Preview arbeitet mit verschiedenen Breakpoints zur Überprüfung der Anpassungsfähigkeit. Live Preview verbindet sich über USB oder Wi-Fi mit einem echten Gerät zum Testen auf Hardware.

HarmonyOS SDK und API

Das HarmonyOS SDK umfasst: ArkUI (UI-Komponenten), Multimedia Kit (Audio-/Videoaufnahme und -wiedergabe), Connectivity Kit (Bluetooth, Wi-Fi, NFC), Location Kit (Geolokalisierung), Sensor Kit (Sensoren), AI Kit (ML Kit mit On-Device-Inferenz auf Huaweis NPU). API-Versionen: API 9 (HarmonyOS 3.x), API 10 (4.x), API 11 (NEXT).

// Initialisieren der Kamera auf HarmonyOS über Multimedia Kit
import multimedia.CameraManager;
import multimedia.CameraInput;
import multimedia.PreviewOutput;

@Component
struct CameraView {
    @State isPreviewActive: boolean = false;
    cameraManager: CameraManager = CameraManager.getInstance();
    cameraInput?: CameraInput;
    previewOutput?: PreviewOutput;

    async startPreview(): Promise<void> {
        try {
            // Kameraberechtigung anfordern
            const granted = await Permissions.request("ohos.permission.CAMERA");
            if (!granted) return;

            // Kamera abrufen (0 — hinten, 1 — vorne)
            const camera = await this.cameraManager.getCamera(0);

            // Kameraeingabe erstellen
            this.cameraInput = await this.cameraManager.createCameraInput(camera);
            await this.cameraInput.open();

            // Vorschau auf Surface starten (ArkUI XComponent)
            this.previewOutput = await this.cameraManager.createPreviewOutput({
                width: 1920,
                height: 1080
            });
            await this.previewOutput.start();
            this.isPreviewActive = true;
        } catch (error) {
            console.error("Camera error: " + error.message);
        }
    }

    async stopPreview(): Promise<void> {
        await this.previewOutput?.stop();
        await this.cameraInput?.close();
        this.isPreviewActive = false;
    }
}

Die CameraView-Komponente demonstriert die Arbeit mit Multimedia Kit: Anfordern der Berechtigung über Permissions.request, Abrufen der Kamera über CameraManager, Erstellen von CameraInput und PreviewOutput. ArkUI Surface (über XComponent) zeigt den Videostream an. Alle Operationen sind asynchron mit Fehlerbehandlung über try/catch.

Verteilte Anwendungen und geräteübergreifend

Die verteilte Architektur von HarmonyOS ist der Hauptunterschied zu Mitbewerbern. Eine Anwendung kann aus mehreren atomaren Diensten (Atomic Services) bestehen, die jeweils auf dem optimalen Gerät ausgeführt werden. Der Benutzer beginnt eine Aufgabe auf einem Gerät und setzt sie auf einem anderen fort, ohne den Kontext zu verlieren.

Atomic Services und Ability

Atomic Service ist die kleinste Bereitstellungseinheit in HarmonyOS. Jeder Dienst implementiert eine oder mehrere Ability (Analog zu Activity in Android). Page Ability — ein Bildschirm mit UI, Service Ability — eine Hintergrundaufgabe, Data Ability — Datenzugriff. Eine Anwendung kann eine Ability an ein anderes Gerät delegieren: Beispielsweise wird die UI auf dem Tablet angezeigt, während die KI-Verarbeitung auf einem Telefon mit NPU ausgeführt wird.

Verteiltes Datenmanagement

Das System für verteiltes Datenmanagement (DDM) synchronisiert den Anwendungsstatus zwischen Geräten. DDM verwendet verteilte Datenobjekte — reaktive Objekte, die automatisch auf alle Benutzergeräte repliziert werden. Datenänderungen auf einem Gerät werden sofort auf allen anderen Geräten widergespiegelt. DDM unterstützt Verschlüsselung und berücksichtigt die Netzwerkverbindung (Bluetooth, Wi-Fi, Mobilfunkdaten).

Super Device

Super Device ist eine HarmonyOS-Funktion, die es ermöglicht, bis zu 7 Huawei-Geräte in einer einzigen Computerumgebung zu vereinen. Der Benutzer zieht Gerätesymbole in der Super Device-Oberfläche: Lautsprecher werden zur Audioausgabe, das Tablet zum zweiten Bildschirm, die Uhr zum Herzfrequenzmesser für eine Fitness-App auf dem Telefon. Alle Geräte synchronisieren sich über einen verteilten Bus (Distributed Bus) mit einer Latenz von weniger als 5 ms.

AppGallery und Anwendungsveröffentlichung

Huawei AppGallery ist der offizielle App Store von HarmonyOS, der drittgrößte der Welt nach Google Play und App Store. Laut Huawei (2026) hat AppGallery über 580 Millionen monatlich aktive Benutzer. Die Entwicklerregistrierung ist für Privatpersonen kostenlos (im Gegensatz zu Apples 99 $).

Veröffentlichungsprozess

Der Entwickler erstellt die Anwendung in DevEco Studio (Format .hap — HarmonyOS Ability Package). Veröffentlichung über AppGallery Connect: HAP-Datei hochladen, Beschreibung ausfüllen (Name, Symbol, Screenshots), Preismodell konfigurieren. Die durchschnittliche Moderationszeit beträgt 1-3 Werktage. Huawei überprüft Sicherheit (statische Analyse), API-Kompatibilität und Richtlinienkonformität.

Monetarisierung

AppGallery unterstützt: kostenpflichtige Anwendungen (Huawei-Provision 15-30%), Abonnements (15% Provision), Werbung über Huawei Ads Kit und In-App-Käufe über IAP Kit. Huawei Pay ist ein Zahlungs-Gateway für den chinesischen Markt, das Alipay und WeChat Pay unterstützt. Internationale Entwickler erhalten Zahlungen per PayPal oder Banküberweisung.

Huawei Mobile Services (HMS)

HMS Core ist eine Reihe von Diensten, die Google Play Services auf Huawei-Geräten ohne Google ersetzen. Enthält: Push Kit (Push-Benachrichtigungen), Map Kit (Karten mit Navigation), Location Kit (Geolokalisierung), Ads Kit (Werbung), Analytics Kit (Analysen), Account Kit (Autorisierung über Huawei ID). HMS Core ist auf Geräten mit HarmonyOS und auf Huawei-Android-Geräten (über AppGallery) verfügbar.