Per Default schaltet das System Display und CPU nach inaktivität ab. Für Apps, bei denen das stört — Video-Player, Audio-Renderer, lang laufende Encoder — bietet powerSaveBlocker eine API, das gezielt zu blockieren.

01 · Abschnitt

Zwei Modi

ModeVerhindertUse-Case
prevent-display-sleepDisplay-SleepVideo-Wiedergabe, Präsentation
prevent-app-suspensionApp-Suspension durch OSBackground-Encoding, Downloads

prevent-display-sleep impliziert prevent-app-suspension — strikteres Mode. Schwächere Variante reicht für reine Background-Tasks.

02 · Abschnitt

Grundbeispiel

JavaScript 
import { powerSaveBlocker } from 'electron';

// Beim Start des Videos
const id = powerSaveBlocker.start('prevent-display-sleep');

// Status prüfen
const isActive = powerSaveBlocker.isStarted(id);

// Beim Ende stoppen
powerSaveBlocker.stop(id);

start gibt eine Block-ID zurück. Mit der ID stoppst du gezielt — wichtig, weil mehrere Blocks parallel aktiv sein können.

03 · Abschnitt

Pattern: Video-Player

JavaScript 
let blockerId = null;

ipcMain.on('video:play', () => {
    if (blockerId === null) {
        blockerId = powerSaveBlocker.start('prevent-display-sleep');
    }
});

ipcMain.on('video:pause', () => {
    if (blockerId !== null) {
        powerSaveBlocker.stop(blockerId);
        blockerId = null;
    }
});

// Cleanup beim Quit
app.on('will-quit', () => {
    if (blockerId !== null) powerSaveBlocker.stop(blockerId);
});

Wichtig: die ID merken und stop aufrufen — sonst bleibt das System wach, bis die App stirbt.

04 · Abschnitt

Mehrere parallele Blocks

JavaScript 
// Blocker für Encoding-Job
const encodeId = powerSaveBlocker.start('prevent-app-suspension');

// Zusätzlich beim Vollbild-Video noch Display-Sleep verhindern
const displayId = powerSaveBlocker.start('prevent-display-sleep');

// Beim Encoding-Ende nur den einen stoppen
powerSaveBlocker.stop(encodeId);
// displayId bleibt aktiv, bis das Video pausiert

Jeder Block ist unabhängig. Erst wenn alle stops gerufen sind, schaltet das System wieder normal.

05 · Abschnitt

Plattform-Verhalten

macOSWindowsLinux
prevent-display-sleepIOPMAssertionSetThreadExecutionStateDBus zu org.freedesktop.ScreenSaver
prevent-app-suspensionNSProcessInfoES_SYSTEM_REQUIREDDBus zu Login1
Funktioniert headlessJaJaDistro-abhängig

Auf manchen Linux-Headless-Setups (Server ohne Window-Manager) gibt es keine entsprechende DBus-Service — powerSaveBlocker läuft durch, hat aber keinen Effekt.

06 · Abschnitt

Aus dem Renderer

JavaScript main.js 
let displayBlockId = null;

ipcMain.handle('power:keep-display-awake', (_event, enable) => {
    if (enable && displayBlockId === null) {
        displayBlockId = powerSaveBlocker.start('prevent-display-sleep');
    } else if (!enable && displayBlockId !== null) {
        powerSaveBlocker.stop(displayBlockId);
        displayBlockId = null;
    }
});
JavaScript preload.js 
contextBridge.exposeInMainWorld('api', {
    keepDisplayAwake: (enable) => ipcRenderer.invoke('power:keep-display-awake', enable)
});

Pattern: Renderer toggelt — der Main verwaltet die Block-ID, weil die im Renderer-Lifetime nicht überlebt.

07 · Abschnitt

FAQ

Wann prevent-display-sleep, wann prevent-app-suspension?

Display-Sleep: für visuelle Anwendungen, die User aktiv anschauen (Video, Präsentation, Live-Dashboard). App-Suspension: für unsichtbare Background-Operationen (Encoding, Sync, Downloads). Wer beides will: prevent-display-sleep ist die obere Stufe.

Beeinflusst der Blocker den Akku-Verbrauch?

Ja — wenn das Display nicht ausgeht, läuft der Backlight-Strom weiter. User sollte das wissen: bei einer „immer wach"-Funktion einen klaren Toggle anbieten und nicht heimlich aktivieren.

Stoppt das System die App trotzdem irgendwann?

macOS und Windows respektieren den Block, solange die App läuft. Nur „App im Hintergrund + macOS App Nap"-Logik kann manchmal eingreifen, falls die App keine sichtbaren Renderer hat. Tray-Apps mit Background-Encoding: prevent-app-suspension reicht.

Was passiert wenn ich stop nie rufe?

Block bleibt aktiv bis App-Quit. Bei Crash oder unsanftem Tod räumt das OS das nach kurzer Zeit auf. Trotzdem: explizit cleanen ist guter Stil — User-Akku dankt dir.

Funktioniert das mit Hibernation?

prevent-app-suspension blockt nur Sleep, nicht Hibernation. Wenn der User aktiv „Hibernate" wählt, geht die App schlafen. Das ist korrekt — Hibernation ist explizite User-Aktion, nicht passive Inaktivität.

Auf macOS: caffeinate als Alternative.

Wer keine Electron-Logik hat, kann child_process.spawn('caffeinate', ['-d']) nutzen — externes macOS-CLI-Tool. Macht das gleiche, aber ohne API-Abhängigkeit. Selten nötig, da powerSaveBlocker portable ist.

08 · Abschnitt

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Main-Prozess

Zur Übersicht