Electron: Headless-Version zum Testen

Durch die Verwendung eines versteckten Browserfensters kann Atom-Shell tatsächlich tun, was phantomjs tut, das Beispiel auf der Homepage von phantomjs könnte in Atom-Shell übersetzt werden:

BrowserWindow = require('browser-window');

console.log('Loading a web page');
var page = new BrowserWindow({show: false});
var url = 'http://www.phantomjs.org/';
page.on('loading-state-changed', (event, isLoading) {
  if (!isLoading)
    //Page is loaded!
    require('app').exit();
});
page.loadUrl(url);

Natürlich müssen wir möglicherweise einige weitere APIs für Automatisierungstests hinzufügen.

Das einzige Problem ist, anstatt in einen virtuellen Puffer zu zeichnen, zeichnet Atom-Shell die Seite tatsächlich in ein echtes Fenster, dies würde eine grafische Umgebung erfordern, unter Windows und OS X spielt es keine Rolle, aber unter Linux müssen wir xvfb verwenden einen X-Server für Atom-Shell bereitzustellen. Dies ist beabsichtigt in der Inhalts-API von Chromium, daher können wir nichts tun, um die Abhängigkeit von der Grafikumgebung zu beseitigen.

Ich hatte damit in letzter Zeit Erfolg (mit Xvfb auf einem Ubuntu-Server). Mein Anwendungsfall ist das Aufnehmen von Screenshots von Seiten mit Vorlagen. Tatsächlich habe ich festgestellt, dass Atom-Shell über Xvfb auf dem Server (ein m3-groß) eine bessere Leistung hat als auf meinem lokalen Macbook Pro. Dies führte dazu, dass ich Atomshell auch in osx über Xvfb zum Laufen bringen wollte.

Da osx mit Xvfb ausgeliefert wird, ist dieser Teil einfach. Kann ich Atom-Shell dazu bringen, ein Xvfb-Display in osx zu verwenden? Die Verwendung der standardmäßigen env-Variablen DISPLAY , wie ich es unter Linux mache, funktioniert nicht. Vielleicht weiß libchromiumcontent nicht, wie man X11 verwendet, wenn es in Darwin läuft?

Xvfb funktioniert nur für Anwendungen, die für die X11-Umgebung geschrieben wurden, unter OS X verwendet Atom-Shell Cocoa für die Anzeige, was meiner Meinung nach nicht mit Xvfb funktionieren kann.

Ja, füge das irgendwie zusammen. Wahrscheinlich nicht wirklich eine Möglichkeit, stattdessen aus dem Quellcode für X11 zu kompilieren?

@zcbenz es ist derzeit nicht möglich, ein BrowserWindow zu erstellen, das größer ist als die aktuelle Auflösung unter OS X, selbst wenn Sie new BrowserWindow({show: false});

@FWeinb können Sie ein separates spezifisches Ticket für das oben genannte öffnen?

Erstellt #475

Ich schließe dies, weil es keine Möglichkeit gibt, eine Seite zu zeichnen, ohne tatsächlich ein natives Widget in Chromium zu erstellen, und ich glaube nicht, dass sie dies jemals zulassen werden.

Für automatische Tests unterstützen wir Selenium.

Das CEF- Projekt unterstützt das Rendern außerhalb des Bildschirms , sodass Sie den Bildschirm in einen Puffer anstelle eines Fensters zeichnen können. In Bezug auf den X-Server für Linux scheint es eine Möglichkeit zu geben, ohne ihn zu arbeiten, indem ein Ziel namens Ozone hinzugefügt wird (siehe Diskussion hier ).

@etiktin Danke für die Informationen! Ich öffne dies wieder, da es eine vorhandene Implementierung dafür gibt.

Dafür könnten wir wirklich Unterstützung gebrauchen. Wir haben vor kurzem Phantom in Nightmare durch Electron ersetzt und lieben es bisher, aber es funktioniert nicht sofort unter Linux.

Folgendes müssen wir jetzt tun, damit es funktioniert: https://github.com/segmentio/nightmare/issues/224#issuecomment -141575361

Ich habe die Aufgabe, das Benutzerverhalten für eine unserer Webanwendungen zu automatisieren, die in eine eigenständige Desktop-Elektron-Anwendung umgewandelt wird. Bevor sich unser Unternehmen für diesen Schritt entschied, haben wir mit dem Chrome-Webtreiber Seitenobjekte erstellt und mit der Webanwendung interagiert, indem wir Schaltflächen/Dropdowns/Textfelder mit den CSS-Selektoren aufgerufen haben. Gibt es eine Möglichkeit, dies mit einer Webanwendung zu tun, die mit der Electron-Shell umschlossen ist? Das Unternehmen plant, die Menüleistenoptionen zu verwenden, um bestimmte Funktionen aufzurufen, und ich habe versucht, ohne Erfolg zu den Standardmenüleistenoptionen wie Datei/Bearbeiten/Hilfe mit dem JavaScript-Treiber zu gelangen. Gibt es Beispiele dafür, wie das geht?

https://github.com/segmentio/nightmare/issues/224#issuecomment -141575361 es scheint, dass @matthewmuellers Snippet unter Linux funktioniert :+1:

Hat jemand Headless-Tests mit SuSE gemacht? Speziell SLES?

@fritx Das gleiche gilt für SlimerJS, aber das ist KEIN Headless-Modus.

@fritx das hat @zcbenz gesagt, Xvfb muss laufen. Sowohl CEF3 als auch Chromium Content Shell hängen derzeit von Xlib ab. Aber mit Fertigstellung von Ozone: https://www.chromium.org/developers/design-documents/ozone
Sie könnten in der Lage sein, beliebige E/A auf niedriger Ebene bereitzustellen.

Anscheinend gibt es in Chromium selbst einen Master-Bug: https://code.google.com/p/chromium/issues/detail?id=546953

Das ist interessant:

Datum: Mi 02. Dez. 15:35:21 2015

[kopflos] Anfangsskelett von kopflos/öffentlich/

Erstellen Sie einen Überblick über die zukünftige Headless-API.

Funktioniert ChromeDriver mit Elektron?

Eine kopflose Binärdatei, die kein xvfb erfordert, würde neue Umgebungen wie AWS Lambda eröffnen – melden Sie sich an!

@Vanuan Hast du schon von Albtraum gehört ? Das könnte Ihnen helfen, wenn Sie nichts speziell von ChromeDriver benötigen.

Hat es einen Capybara/Selenium-Treiber?

+1

Ich bin ein wenig verwirrt. Gibt es einen Headless-Modus? Können wir dies effektiv mit BrowserWindow({show: false}) tun? Dies wäre für mich sehr nützlich, ich versuche, dies zum Laufen zu bringen, damit wir serverseitige Webkomponenten erstellen können: https://github.com/scramjs/scram-markup-engine

Ich glaube, ich habe meine eigene Frage beantwortet, als ich mich umgesehen habe. Electron unterstützt nativ keinen ausgeklügelten Headless-Modus. Nightmare scheint so etwas zuzulassen, aber Sie müssen noch einige Konfigurationen vornehmen, damit es auf bestimmten Systemen ohne grafische Umgebung funktioniert. Electron kann dies auch tun, wenn Sie BrowserWindow({show: false}) verwenden, aber Sie müssen xvfb verwenden, um eine grafische Umgebung auf kopflosen Linux-Systemen bereitzustellen (was eigentlich nicht schlecht aussieht). Korrigieren Sie mich, wenn ich falsch liege, und geben Sie +1 für diese Funktion.

Wäre es mit dem neuen Chrom-Headless-Projekt [1] möglich, Elektron Headless zu machen, ohne xvfb zu verwenden?

Ich glaube, die aktuelle Einschränkung lag bei libchromium? Haben die Chrom-Jungs das behoben?

1: https://chromium.googlesource.com/chromium/src/+/master/headless/README.md

Es gibt ein verwandtes Forum: https://groups.google.com/a/chromium.org/forum/#!forum/headless -dev

Gibt es diesbezüglich Fortschritte? Das wäre wirklich nützlich zum Testen

segmentio/nightmare ist dafür perfekt. Einfach:

const nightmare = Nightmare({
  show: true
});

@amilajack Für einfache Fälle wie das kopflose Ausführen einfacher Mocha-Einheitentests wäre Nightmare so, als würde man einen 20-Pfund-Vorschlaghammer verwenden, um einen kleinen Nagel

@isiahmeadows @mcolyer sagte, dass er eine kopflose Version der Atom-Shell wollte, die als Ersatz verwendet werden könnte. Electron ist ziemlich genau das mit zusätzlichen Funktionen.

Ja, aber warum brauchst du Zucker für das, was du nicht verwendest? (Ich bezog mich auf den ganzen Zucker - Sie könnten Electron theoretisch vollständig mit nur Vanille-Node + OpenGL-Bindungen neu implementieren).

Der häufigste Anwendungsfall für Headless-Browser sind Dinge, für die es Mocha-Phantomjs und Karma bereits gibt - das Ausführen von Browser-Unit-Tests über die CLI. Die meisten Leute verwenden xvfb, einen kopflosen X-Server, auf Travis, wenn sie Firefox/Chrome testen müssen, da dieser keinen laufenden X-Server hat und Sie sogar Electron damit ausführen könnten, aber kopflose Browser wie PhantomJS und SlimerJS tun dies nicht. Ich brauche keinen X-Server. Electron + Nightmare benötigt immer noch einen X-Server (auch wenn es xvfb ist), um zu laufen, und dieses Problem erfordert, dass diese Abhängigkeit entfernt wird, aber es wird höchstwahrscheinlich nicht passieren, bis Chromium selbst kopflos werden kann und diese Änderungen verbreitet werden zum Libchromgehalt .

Headless ist jetzt in Chrome 59: https://www.chromestatus.com/features/5678767817097216

@sindresorhus @zcbenz Wird diese Änderung in Chrom hier einen Unterschied machen?

Electron ist schon wunderbar, und ein Headless-Modus würde es noch besser machen!

(Es wäre auch nützlich für Nightmare , das auf Electron basiert)

Ich konnte Xvfb an Lambda arbeiten lassen, was für Lambda-basierte Tests hilfreich sein könnte ... https://github.com/nisaacson/aws-lambda-xvfb

Gibt es ein Wort darüber, wann Electron True Headless unterstützen wird? Können wir damit rechnen? Ich kann es kaum erwarten, xvfb fallen zu lassen.

@lastmjs haben Sie es geschafft, Electron auf AWS Lambda basierend auf xvfb zum Laufen zu bringen?

@schickling See https://github.com/nisaacson/aws-lambda-xvfb

Danke für deinen Kommentar @MrSaints. Ich debugge dieses Repo tatsächlich seit mehreren Stunden, da ich es nicht schaffen kann, nightmare zum Laufen zu bringen. Funktioniert es bei dir?

@zcbenz FYI https://www.chromestatus.com/features/5678767817097216

@schickling siehe https://github.com/JohannesHoppe/nightmare-html2pdf -- Alptraum im Docker, mit Xvfb

Danke @JohannesHoppe , ich habe Nightmare in Docker mit Xvfb arbeiten lassen, möchte es aber stattdessen auf AWS Lambda ausführen.

Ich habe ein Problem geöffnet, um Electron in Nightmare durch kopfloses Chrome zu ersetzen: https://github.com/segmentio/nightmare/issues/1092

@schickling versuch das: https://github.com/dimkir/nightmare-lambda-tutorial

Entschuldigung, wenn dies an anderer Stelle beantwortet wird, aber ich kann keine konkrete Antwort finden. In seinem obigen Kommentar mit der höchsten Note +1 wies

Wird die Headless-Flagge von Chrome in der Entwicklungs-Roadmap für Electron unterstützt? Es scheint, dass dies ein potenziell großer "Gewinn" für Electron ist, da es eine echte Headless-Nutzung ermöglicht.

Ich stimme @rinogo zu. Eine Headless-Option für Elektron zu haben, ist sehr nützlich, um Tests in CI-Systemen und auf einer Entwicklungsbox durchzuführen, ohne dass eine virtuelle Anzeige erforderlich ist und die Maschine übernommen wird. Ich bin auch daran interessiert, die Roadmap für Elektron zu kennen und möglicherweise einen Beitrag zu leisten.

Xvfb ist nervig, es wäre toll, wenn Electron echtes Headless unterstützt!

xvfb-vielleicht in der Zwischenzeit

Es gibt einen neuen Artikel von Google: https://developers.google.com/web/updates/2017/04/headless-chrome

Es kommt bald.

Sieht so aus, als ob Chrome 59 jetzt auf dem stabilen Kanal ist. Was sind die nächsten Schritte, um Headless in Electron zu unterstützen?

Bitte lassen Sie dies Wirklichkeit werden – indem Sie dies tun und NightmareJS ermöglichen, kopfloses Electron auszuführen, würden Sie letztendlich etwa ein Drittel aller Selenium-Anwendungsfälle eliminieren.*

* Hyperbolisch sein, aber auch nicht wirklich

@aendrew Ich Desktop-Apps erstellen _) kopflos zu machen. Siehe: https://github.com/cyrus-and/chrome-remote-interface

@MrSaints Ich beneide die Betreuer nicht; sie _nur_ die Konvertierung von PhantomJS wie vor einem Jahr abgeschlossen. Wenn überhaupt, ist es vielleicht eine gute Motivation, die Browserebene von Nightmare steckbar zu machen ...

Unabhängig davon ist der Punkt, dass Electron Desktop-orientiert ist, gut getroffen.

@aendrew @MrSaints Auf die Gefahr hin, meine Unwissenheit zu verbreiten... Wie schwierig ist diese Änderung (die das headless Flag unterstützt) umzusetzen? Ich bin mir nicht sicher, wie Electron sich mit Chromium verbindet/erweitert, aber es scheint mir, dass die Schritte zur Implementierung dies sind:

1. Aktualisieren Sie Electrons Chromium auf Version 59+.
2. Geben Sie den Befehlszeilen-Flag/Konfigurationsparameter headless .
3. Andere Dinge, die ich offensichtlich nicht berücksichtige. :)

Ich schätze, was ich sagen will, ist, da headless jetzt in Chromium verfügbar ist, scheint die Implementierung eines Headless-Modus (zB für NightmareJS) relativ einfach zu sein. Zugegeben, eine Allzweckversion von Electron kann einige Zeit in Anspruch nehmen, um bestimmte Anwendungsfälle auszubügeln. Es sollte jedoch ziemlich einfach sein, einen Build zu generieren, der für so etwas wie NightmareJS entwickelt wurde, oder?

Wenn ich die Geschwindigkeitsverbesserungen sofort brauche, würde ich einspringen und es versuchen. Wir kommen jedoch immer noch mit NightmareJS so wie es ist aus, also sind wir vorerst in Ordnung.

Trotzdem danke ich den Betreuern all dieser Projekte für ihre Beiträge und ihre harte Arbeit! :)

Bezüglich NightmareJS: Wir arbeiten derzeit an einer Version von Nightmare, die auf Headless Chrome basiert und sogar in serverlosen Umgebungen wie AWS Lambda ausgeführt werden kann. Wir werden es bald als Open Source @graphcool veröffentlichen. 🚀

@schickling das wird

Beachten Sie bei --headless in Chrome, dass die Unterstützung für alle Plugins deaktiviert wird. Wenn Sie also Flash (was mit Elektron/Albtraum machbar ist) oder den PDF-Viewer usw. benötigen, ist --headless nichts für Sie und Sie sollten xvfb verwenden.

Ich kann es kaum erwarten, Electron in AWS Lambda auszuführen ... denke ich

Amen @lastmjs Amen

Was ist mit dieser Lösung?
https://github.com/dimkir/nightmare-lambda-tutorial

Habe es aber noch nicht probiert

@xplodedthemes verwendet eine vorkompilierte Version von xvfb

Schamloser Stecker: https://github.com/joelgriffith/navalia. Dies wurde auf kopflosem Chrome für Funktionstests und mehr aufgebaut. Enthält einige nette Funktionen wie die Parallelisierung mehrerer Aufgaben, ein GraphQL-Frontend und mehr.

Ich freue mich über alle PRs/Probleme/Feedback!

Hallo allerseits! Tut mir leid, dass Sie alle warten müssen...

Wir haben Chromeless gerade als Open-Source-Software

Hier kannst du es ausprobieren: https://chromeless.netlify.com

Hat Chromeless gerade Nightmare ersetzt? Chromeless hat noch einen langen Weg vor sich, bis es Nightmare einholt.

Wir verwenden es als Ersatz für Nightmare, da wir die Möglichkeit benötigen, mehrere Tests gleichzeitig durchzuführen.

Frage (vielleicht nicht gut für diesen Thread): Erwägen Sie, die PDF-Funktionalität zum Laufen zu bringen? Wenn ja, könnte uns dies eine TONNE Kopfschmerzen (und Kosten) ersparen.

Wow, das ist unglaublich. Gute Arbeit Jungs!

@zcbenz es scheint, als ob hierfür Lösungen aufgetaucht sind:

Ähm, dieses Thema ist immer noch äußerst gültig. Die "Lösungen" beinhalten alle, sich vollständig von Nightmare zu entfernen.

Völlig mit @keithkml einverstanden - die Lösungen, obwohl gut gemeint (danke!), waren eher "Alternativen", bis eine tatsächliche Lösung bereitgestellt wird. Hat in diesem Sinne jemand hier genügend Fachwissen, um die Fragen zu beantworten, die ich in meinem vorherigen Kommentar gestellt habe ? (Und bitte entschuldige meine Unwissenheit! :))

Ich verstehe immer noch nicht den Sinn der Antworten. Könnte mir bitte jemand klarstellen, ob wir den NATIVE Headless-Modus haben, damit die Electron-App im CI ausgeführt wird oder nicht?

@hitliubo Chrome hat ein --headless Flag, aber es funktioniert nur, wenn Sie keine Plugins wie Flash oder den PDF-Reader verwenden. Wenn Sie sind, dann ist die Antwort eine bejahende nicht im Moment. Wenn dies nicht der Fall ist, können Sie dieses Flag (zusammen mit --disable-gpu falls erforderlich - sie haben diese fehlende Implikation in neueren Chrome-Versionen IIRC behoben) beim Erstellen des Browserkontexts übergeben und prüfen, ob dies funktioniert. (Beachten Sie, dass Sie, wenn Sie so etwas wie Nightmare verwenden und in die zweite Kategorie fallen, wirklich ein Problem im jeweiligen Repository dieses Projekts einreichen sollten, falls noch keins vorhanden ist.)

Auch wenn Sie --headless nicht verwenden können (oder wenn es nicht funktioniert), gibt es Optionen:

• Windows: Sofern Sie nicht etwas Unverständliches verwenden, haben Sie immer einen Fensterkontext zum Rendern. Windows Server 2016 hat die standardmäßige GUI-Unterstützung eingestellt, aber es unterstützt weiterhin das Erstellen von GUI-Fenstern, und AFAICT sollte das Nötigste für Selenium-Tests unterstützen.
• macOS: Sie haben hier immer eine GUI (und somit einen Fensterkontext zum Rendern). Apple bietet keine Version an, die dies nicht tut.
• Linux: xvfb ist ein Headless-X-Server, der für fast jede gängige Linux-Distribution verfügbar ist (und ich meine hier ziemlich locker "gemeinsam"). Wenn Sie Travis verwenden, finden Sie dort Anweisungen zum Hinzufügen zu Ihrem Projekt .

@isiahmeadows Danke für deine Informationen. Derzeit habe ich eine Web-App im Browser und mit Chrome/Firefox könnte ich immer --headless für die Headless-Tests hinzufügen. Vor kurzem möchten wir es in die Electron-App konvertieren und ich habe es mit --headless versucht, was in meinem macOS nicht funktioniert. Jetzt kenne ich deinen Grund. Vielen Dank!

Eigentlich mag ich die Lösung von xvfb nicht, da sie nicht nativ ist. Da wir jedoch natives Headless nicht unterstützen, muss ich es wohl versuchen.

Zu Ihrer Information - Jetzt verwende ich Capybara zum Testen.

Das wäre toll (ja)

Gibt es dazu ein Update?

Ich wurde von einem Beitrag über das direkte Rendern in einen Linux-Framebuffer hierher umgeleitet, aber dies scheint sich auf Headless-Tests zu konzentrieren. Wurden Fortschritte beim direkten Rendern in einen _realen_ Framebuffer erzielt?

@quinn Ich bin mir ziemlich sicher, dass Sie einen X-Server benötigen werden, obwohl Sie X11 (Xorg) auf einem Frame-Puffer ausführen können, wenn Sie

_Bearbeiten:_

Tatsächlich kann dies nach etwas genauerer Betrachtung auch durch die Verwendung von Ozon erreicht werden. ( https://github.com/jakwu/ozone-fb )

Das Hinzufügen von Ozon würde auch Wayland-Unterstützung ermöglichen, eine weitere Funktion, die Electron fehlt, da die meisten Linux-Distributionen seitdem darauf migriert sind.

Basierend auf der Beschreibung von oze -fb und

@trusktr Das ist ein 2 Jahre alter Kommentar. Ich würde empfehlen, meinen Kommentar nicht als maßgeblich zu betrachten, da sich dies hätte ändern können (ich habe es seitdem nicht überprüft).

Ich füge die Headless-Lib zu Electron hinzu und rufe die HeadlessShellMain。 auf.
Lauf:

e run  --headless --enable-logging --v=2 --disable-gpu --screenshot  http://192.168.50.206

dann zeigt es:

Running "/home/a/dev0/e9.2.1/src/out/ReleaseSym0/electron --headless --enable-logging --v=2 --disable-gpu --screenshot http://192.168.50.206:8889"
[1028/172650.483932:INFO:cpu_info.cc(53)] Available number of cores: 4
[1028/172650.484061:VERBOSE1:zygote_main_linux.cc(217)] ZygoteMain: initializing 0 fork delegates
[1028/172650.484400:INFO:cpu_info.cc(53)] Available number of cores: 4
[1028/172650.484465:VERBOSE1:zygote_main_linux.cc(217)] ZygoteMain: initializing 0 fork delegates
[1028/172650.493514:VERBOSE1:webrtc_internals.cc(119)] Could not get the download directory.
[1028/172650.494623:VERBOSE1:proxy_config_service_linux.cc(500)] All gsettings tests OK. Will get proxy config from gsettings.
[1028/172650.494764:VERBOSE1:proxy_config_service_linux.cc(1261)] Obtained proxy settings from annotation hash code 11258689
[1028/172650.494873:VERBOSE1:proxy_config_service_linux.cc(500)] All gsettings tests OK. Will get proxy config from gsettings.
[1028/172650.494919:VERBOSE1:proxy_config_service_linux.cc(1261)] Obtained proxy settings from annotation hash code 11258689
[1028/172650.504033:VERBOSE1:sandbox_linux.cc(69)] Activated seccomp-bpf sandbox for process type: renderer.
[1028/172650.505596:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.511468:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.524408:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.524916:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.525173:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.525963:VERBOSE1:sandbox_linux.cc(69)] Activated seccomp-bpf sandbox for process type: gpu-process.
[1028/172650.526373:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.528735:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.531839:VERBOSE2:thread_state.cc(470)] [state:0x556bd75583a0] ScheduleGCIfNeeded
[1028/172650.535051:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[1028/172650.550076:VERBOSE1:configured_proxy_resolution_service.cc(873)] PAC support disabled because there is no system implementation
[1028/172650.550312:VERBOSE1:configured_proxy_resolution_service.cc(873)] PAC support disabled because there is no system implementation
[1028/172650.550923:VERBOSE1:network_delegate.cc(32)] NetworkDelegate::NotifyBeforeURLRequest: http://192.168.50.206:8889/
[1028/172650.575829:VERBOSE1:url_loader.cc(418)] To buffer: http://192.168.50.206:8889/
[1028/172650.580122:VERBOSE1:v8_context_snapshot.cc(153)] A context is created from snapshot for main world
[1028/172650.587399:VERBOSE1:v8_context_snapshot.cc(153)] A context is created from snapshot for main world
[1028/172650.595294:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[1028/172650.612295:ERROR:paint_controller.cc(646)] PaintController::FinishCycle() completed
[1028/172650.676553:INFO:headless_shell.cc(620)] Written to file screenshot.png.

Heißt das, dass Headless implementiert wurde?

@bigben0123 das ist interessant und sehr spannend! Sie haben also Ihre eigene Version von Elektronen zusammengestellt, die die kopflose Schale aus Chrom enthalten?

Haben Sie in einer Umgebung ohne X unter Linux getestet, ob es funktioniert?

Wenn Chromium im Headless-Modus ausgeführt wird, werden die Render-Unterprozesse mit dem übergebenen —headless-Flag gestartet (Sie können sehen, dass Sie 'ps args' aus dem Speicher verwenden). Passiert das bei dir?

(Seltsamerweise mit Electron derzeit, wenn Sie versuchen, es mit —headless zu starten, wird das Flag nicht an die Render-Prozesse übergeben, sondern an den GPU-Prozess.)

@bigben0123 das ist interessant und sehr spannend! Sie haben also Ihre eigene Version von Elektronen zusammengestellt, die die kopflose Schale aus Chrom enthalten?

Haben Sie in einer Umgebung ohne X unter Linux getestet, ob es funktioniert?

Wenn Chromium im Headless-Modus ausgeführt wird, werden die Render-Unterprozesse mit dem übergebenen —headless-Flag gestartet (Sie können sehen, dass Sie 'ps args' aus dem Speicher verwenden). Passiert das bei dir?

(Seltsamerweise mit Electron derzeit, wenn Sie versuchen, es mit —headless zu starten, wird das Flag nicht an die Render-Prozesse übergeben, sondern an den GPU-Prozess.)

Ja, ich führe es auf Ubuntu aus, das einfach im Benutzerbefehlsmodus startet.
Headless wurde bestanden:

electron --headless --enable-logging --v=2 --disable-gpu -print-to-pdf http://www.google.com
electron --type=zygote --no-zygote-sandbox --enable-logging --headless --v=2 --headless
electron --type=zygote --enable-logging --headless --v=2 --headless
electron --type=zygote --enable-logging --headless --v=2 --headless
electron --type=gpu-process --field-trial-handle=15536072708541054845,15522400966085077738,131072 --enable-logging --headless --v=2 --headless --gpu-preferences=MAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAQAAAAAAAAAAAAAAAAAAAACAAAAAAAAAA= --use-gl=swiftshader-webgl --override-use-software-gl-for-tests --enable-logging --v=2 --shared-files
electron --type=utility --field-trial-handle=15536072708541054845,15522400966085077738,131072 --lang=en-US --service-sandbox-type=network --enable-logging --use-gl=swiftshader-webgl --v=2 --headless --enable-logging --v=2 --shared-files=v8_snapshot_data:100
electron --type=renderer --allow-pre-commit-input --enable-logging --v=2 --field-trial-handle=15536072708541054845,15522400966085077738,131072 --disable-databases --disable-gpu-compositing --lang=en-US --headless --lang=en-US --num-raster-threads=2 --enable-main-frame-before-activation --renderer-client-id=4 --shared-files=v8_snapshot_data:100
electron --type=broker

@bigben0123 hast du deine Änderungen irgendwo? Auch wenn dies aus irgendeinem Grund nicht in den Elektronenkern gelangt, würde ich es gerne verwenden.

Dieser Commit führt nur die Headless-Bibliothek von Chrome mit Electron zusammen und Sie können sie genauso verwenden wie Chrome.
https://github.com/bigben0123/electron/commit/b6cad8993d68d39f1732aa6ed5ece0135b9ae0c8

Was mich betrifft, haben Chrome und Headless unterschiedliche Content-Layer-Implementierungen. Wie bei zwei Browser-Shells, wenn Sie headless starten, hat dies nichts mit Chrome zu tun, außer Sie starten mit "chrome --headless".

Das Ziel von Headless ist das „Minimieren der Anzahl invasiver oder Headless-spezifischer Änderungen (zB #ifdefs) an der Codebasis von Chromium“.

Daher ist es schwierig zu implementieren, dass das Elektron kopflos ist, um xvfb zu entfernen. Wir können Elektron einfach kopflos unterstützen lassen, aber Sie können keine Elektron-Apps ausführen.

Wir können die Headless-Implementierung verwenden, um Elektronen zu ersetzen, um einen neuen Headless-Zweig zu erhalten.

entferne die Abhängigkeit von electron/BUILD.gn:

      "//ui/events/devices/x11",
      "//ui/events/platform/x11",
      "//ui/gtk"  #all of gkt related

    if (use_x11) {
      deps += [
        "//ui/gfx/x",
        "//ui/gtk:x",
      ]
    }
    configs += [ ":gio_unix" ]
    configs += [ "//build/config/linux:x11" ]

ersetzen mit:
"//ui/display",
"//ui/events/geräte",