Electron: 用于测试的无头版本

通过使用隐藏的浏览器窗口 atom-shell 实际上可以做 phantomjs 所做的事情，phantomjs 主页中的示例可以转换为 atom-shell：

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);

当然，我们可能需要添加更多的 API 用于自动化测试。

唯一的问题是不是绘制到虚拟缓冲区中，而是 atom-shell 实际上将页面绘制到真实窗口中，这需要图形环境，在 Window 和 OS X 上没有关系，但是在 Linux 上我们必须使用xvfb为 atom-shell 提供 X 服务器。 这是在 Chromium 的内容 API 中设计的，所以我们不能做任何事情来消除图形环境的依赖。

我最近在这方面取得了成功（在 Ubuntu 服务器上使用 Xvfb）。 我的用例是捕获模板化页面的屏幕截图。 事实上，我发现通过 Xvfb 在服务器（一个 m3-large）上的 atom-shell 比我本地的 Macbook pro 具有更好的性能。 这让我想要让 atom-shell 也通过 osx 中的 Xvfb 工作。

由于 osx 附带 Xvfb，这部分很容易。 我可以让 atom-shell 在 osx 中使用 Xvfb 显示吗？ 像我在 linux 中那样使用标准的DISPLAY env 变量是行不通的。 也许 libchromiumcontent 在达尔文中运行时不知道如何使用 X11？

Xvfb 仅适用于为 X11 环境编写的应用程序，在 OS X atom-shell 上使用 Cocoa 进行显示，我认为不能与 Xvfb 一起使用。

是的，把它放在一起。 可能不是真正的从 X11 的源代码编译的方法？

@zcbenz目前无法在 OS X 上创建大于当前分辨率的BrowserWindow ，即使您使用new BrowserWindow({show: false});

@FWeinb您可以为上述单独开一张特定的票吗？

已创建 #475

我要关闭它，因为没有在 Chromium 中实际创建本机小部件的情况下无法绘制页面，我认为他们永远不会允许它。

对于自动测试，我们确实支持 Selenium。

CEF项目支持离屏渲染，因此您可以将屏幕绘制到缓冲区而不是窗口中。 关于 Linux 的 X 服务器，似乎有一种方法可以在没有它的情况下通过添加一个名为 Ozone 的目标来工作（请参阅此处的讨论）。

@etiktin感谢您提供信息！ 我正在重新打开这个，因为有一个关于如何做的现有实现。

我们真的可以为此使用支持。 我们最近在Nightmare中用 Electron 替换了 Phantom 并且到目前为止

这是我们现在需要做的才能让它工作： https :

我的任务是为我们的一个 Web 应用程序自动化用户行为，该应用程序将转换为独立的桌面 Electron 应用程序。 在我们公司决定采取这一举措之前，我们使用 chrome Web 驱动程序创建了页面对象，并通过使用 css 选择器调用按钮/下拉菜单/文本框与 Web 应用程序进行交互。 有没有办法用一个用 Electron shell 包装的 web 应用程序来做到这一点？ 该公司计划使用菜单栏选项来调用某些功能，我尝试使用 JavaScript 驱动程序访问默认菜单栏选项，如文件/编辑/帮助，但没有成功。 有没有关于如何做到这一点的例子？

https://github.com/segmentio/nightmare/issues/224#issuecomment -141575361 似乎@matthewmueller的代码段在 Linux 上有效：+1：

有人在 SuSE 上进行过无头测试吗？ 特别是SLES？

@fritx与

@fritx这就是@zcbenz所说的，你必须让 Xvfb 运行。 CEF3 和 Chromium Content Shell 目前都依赖于 Xlib。 但随着臭氧的完成： https :
您可以提供任何低级 I/O。

显然，Chromium 本身存在一个主要错误： https : =546953

这很有趣：

日期：2015 年 12 月 2 日星期三 15:35:21

[headless] headless/public/的初始骨架

创建未来 Headless API 的大纲。

ChromeDriver 是否与电子一起使用？

不需要 xvfb 的无头二进制文件将打开新环境，例如AWS Lambda - 注册我！

@Vanuan你听说过噩梦吗？ 如果 ChromeDriver 没有您特别需要的东西，这可能会对您有所帮助。

它有 Capybara/Selenium 驱动程序吗？

+1

我有点困惑。 有无头模式吗？ 我们可以使用 BrowserWindow({show: false}) 有效地做到这一点吗？ 这对我来说非常有用，我正在尝试让它工作，以便我们可以创建服务器端 Web 组件： https :

我想我已经回答了我自己的问题，因为我一直在环顾四周。 Electron 本身不支持复杂的无头模式。 Nightmare 似乎允许类似的事情，但是您仍然需要进行一些配置才能使其在没有图形环境的某些系统上工作。 如果您使用 BrowserWindow({show: false})，Electron 也可以做到，但是您必须使用 xvfb 在无头 Linux 系统上提供图形环境（实际上看起来并不算太糟糕）。 如果我错了，请纠正我，并为此功能 +1。

使用新的铬无头项目 [1] 是否可以在不使用 xvfb 的情况下使电子无头？

我相信当前的限制是 libchromium 吗？ 铬人解决了吗？

1： https :

有一个相关的论坛： https: //groups.google.com/a/chromium.org/forum/#!forum

这方面有什么进展吗？ 这对测试非常有用

segmentio/nightmare是一个完美的选择。 简单地：

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

@amilajack对于像无头运行简单的 Mocha 单元测试这样的简单情况，Nightmare 就像使用 20 磅重的大锤敲入一个小钉子（阅读：大量矫枉过正）。 这是一个完全成熟的、包含电池的浏览器自动化库，不仅可以执行基本的导航和输入，甚至可以将 HTML 和 PDF 文件保存到磁盘或截取屏幕截图。 这个库的 0% 应该是运行简单单元测试所必需的。

@isiahmeadows @mcolyer说他想要一个可以用作替代品的无头版本的 atom-shell。 Electron 几乎就是这样，具有额外的功能。

是的，但是你为什么要为你不用的东西加糖呢？ （我指的是所有的糖 - 从理论上讲，您可以仅使用 vanilla Node + OpenGL 绑定来重新实现整个 Electron）。

无头浏览器最常见的用例是mocha-phantomjs和 Karma 已经存在的东西——从 CLI 运行浏览器单元测试。 大多数人在需要测试 Firefox/Chrome 时会在 Travis 上使用 xvfb，一个无头 X 服务器，因为它没有运行的 X 服务器，你甚至可以用它运行 Electron，但是像 PhantomJS 和 SlimerJS 这样的无头浏览器不会不需要 X 服务器。 Electron + Nightmare 仍然需要某种类型的 X 服务器（即使它是 xvfb）才能运行，并且这个问题要求删除该依赖项，但它很可能不会发生，直到Chromium 本身可以无头并传播这些更改到libchromiumcontent 。

Headless 现在在 Chrome 59 中： https :

@sindresorhus @zcbenz Chromium 中的这种变化在这里有什么不同吗？

Electron 已经很棒了，无头模式会让它变得更好！

（它对基于 Electron 的Nightmare也

我能够让Xvfb在 lambda 上工作，这可能有助于基于 lambda 的测试...... https://github.com/nisaacson/aws-lambda-xvfb

关于 Electron 何时支持真正的无头有什么说法吗？ 我们可以指望这会发生吗？ 我等不及要放弃 xvfb。

@lastmjs您是否设法让 Electron 在基于 xvfb 的 AWS Lambda 上运行？

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

感谢您的评论@MrSaints。 我现在确实在调试这个 repo 几个小时，因为我无法让nightmare运行。 对你起作用吗？

@zcbenz FYI chrome 59 将获得无头模式支持https://www.chromestatus.com/features/5678767817097216

@schickling见https://github.com/JohannesHoppe/nightmare-html2pdf——docker 中的噩梦，与 Xvfb

谢谢@JohannesHoppe ，我让 Nightmare 在 Docker 中使用 Xvfb 工作，但想在 AWS Lambda 上运行它。

我已经打开了一个问题，用 Nightmare 中的无头 Chrome 替换 Electron： https :

@schickling试试这个： https :

如果在其他地方回答了这个问题，我很抱歉，但我找不到具体的答案。 在上面高度 +1 的评论中， @sandstrom指出 Chrome 59 现在可以使用 headless。

Electron 的开发路线图是否支持 Chrome 的无头标志？ 对于 Electron 来说，这似乎是一个潜在的巨大“胜利”，因为它使真正的无头使用成为可能。

我同意@rinogo。 拥有电子的无头选项对于在 ci 系统和开发箱中运行测试非常有用，而无需虚拟显示和接管机器。 我也有兴趣了解电子的路线图并可能做出贡献。

Xvfb 很烦人，如果 Electron 支持真正的 headless 就太好了！

xvfb-也许在此期间

谷歌有一篇新文章： https :

快到了。

看起来 Chrome 59 现在在稳定频道上。 在 Electron 中支持 Headless 的下一步是什么？

拜托，请让这成为现实——通过这样做并让 NightmareJS 运行无头 Electron，你最终会消除所有 Selenium 用例中的三分之一。*

* 双曲线但也不是真的

@aendrew我认为 NightmareJS 可能会被_重写_以使用/包含一个 CDP 后端，而不是为了使 Electron（其理念：_build 跨平台桌面应用程序_）无头而大吵大闹。 请参阅： https :

@MrSaints我不羡慕维护者； 他们 _just_ 就像一年前一样完成了从 PhantomJS 的转换。 虽然如果有的话，也许是让 Nightmare 的浏览器层可插入的一个很好的动机......

无论如何，Electron 面向桌面的观点是公认的。

@aendrew @MrSaints冒着传播我的无知的风险...实施此更改（支持headless标志）有多困难？ 我不确定 Electron 如何与 Chromium 接口/扩展，但在我看来，实现这一点的步骤是：

1. 将 Electron 的 Chromium 升级到 59+ 版本。
2. 提供headless命令行标志/配置参数。
3. 其他我显然没有考虑的东西。 :)

我想我要说的是，现在headless在 Chromium 中可用，实现无头模式（例如用于 NightmareJS）似乎相对简单。 诚然，Electron 的通用版本可能需要一些时间来解决某些用例。 但是，要生成为 NightmareJS 之类的东西设计的构建，应该非常简单，对吧？

如果我迫切需要提高速度，我会跳进去试一试。 然而，我们仍然按原样使用 NightmareJS，所以我们暂时没问题。

无论如何，感谢所有这些项目的维护者的贡献和辛勤工作！ :)

关于 NightmareJS：我们目前正在开发一个基于无头 Chrome 的 Nightmare 版本，甚至能够在无服务器环境（例如 AWS Lambda）中运行。 我们很快就会开源它@graphcool。 🚀

@schickling那会很棒！

在 chrome 中使用--headless记住的一件事是它禁用了对所有插件的支持。 所以，如果你需要 flash（可以使用电子/噩梦）或 PDF 查看器等， --headless不适合你，你会想要使用 xvfb。

我迫不及待地想在 AWS Lambda 中运行 Electron ......我想

阿门@lastmjs阿门

这个解决方案怎么样？
https://github.com/dimkir/nightmare-lambda-tutorial

虽然还没试过

@xplodedthemes使用

无耻的插件： https :

我欢迎任何 PR/问题/反馈！

嘿大家！ 抱歉让大家久等了...💤

我们刚刚开源了Chromeless 。 它基于无头 Chrome，可在本地和 AWS Lambda 上运行。 API 与 NightmareJS 非常相似。

你可以在这里试试： https :

Chromeless 刚刚取代了 Nightmare 吗？ Chromeless 在赶上 Nightmare 之前还有很长的路要走。

我们使用它作为 Nightmare 的替代品，因为我们需要能够同时运行多个测试。

问题（可能不适合此线程）：您是否正在考虑使 pdf 功能正常工作？ 如果是这样，这可以为我们节省大量的头痛（和成本）。

哇，太不可思议了。 干得好伙计们！

@zcbenz似乎已经出现了解决方案：可以关闭吗？

嗯这个问题仍然非常有效。 “解决方案”都涉及完全摆脱 Nightmare。

完全同意@keithkml——这些解决方案虽然是善意的（谢谢！），但在提供实际解决方案之前，更多的是“替代方案”。 沿着这些思路，这里有人有足够的专业知识来回答我在之前的评论中提出的问题吗？ （再次，请原谅我的无知！:)）

我仍然没有得到回应的重点。 有人可以澄清一下，我们是否有用于在 CI 中运行的电子应用程序的 NATIVE Headless 模式？

@hitliubo Chrome 有一个--headless标志，但它仅在您不使用 Flash 或 PDF 阅读器等插件时才有效。 如果您是，那么目前的答案是肯定的“否”。 如果不是，则可以在创建浏览器上下文时传递该标志（如果需要，还可以传递--disable-gpu - 他们在较新的 Chrome 版本 IIRC 中修复了此缺失的含义）并查看是否有效。 （请注意，如果您使用的是 Nightmare 之类的东西并且属于第二类，那么您真的应该在该项目的相应 repo 中提交问题，如果还没有的话。）

即使您不能使用--headless （或者它不起作用），也有选项：

• Windows：除非你使用一些晦涩的东西，否则你总是有一个窗口上下文来渲染。 Windows Server 2016 删除了默认的 GUI 支持，但它仍然支持创建 GUI 窗口，并且 AFAICT应该支持 Selenium 测试的最低要求。
• macOS：您将始终在此处拥有一个 GUI（因此有一个要渲染的窗口上下文）。 Apple 不提供不支持的版本。
• Linux：xvfb 是一个无外设的 X 服务器，几乎可用于所有常见的 Linux 发行版（这里我的意思是“常见”非常松散）。 如果您使用 Travis，他们会提供有关如何将其添加到您的项目的说明。

@isiahmeadows感谢您提供信息。 目前我有一个在浏览器中运行的网络应用程序，并且使用 chrome/firefox 我总是可以添加 --headless 进行无头测试。 最近我们想将它转换为 Electron 应用程序，我尝试使用 --headless ，它在我的 macOS 中不起作用。 现在我知道你的原因了。 谢谢！

实际上我不喜欢 xvfb 的解决方案，因为它不是原生的。 但是，鉴于我们不支持原生无头，所以我想我需要尝试一下。

仅供参考 - 现在我使用水豚进行测试。

那太好了（y）

有任何更新吗？

我从一篇关于直接渲染到 linux 帧缓冲区的帖子重定向到这里，但这似乎专注于无头测试。 直接渲染到 _real_ 帧缓冲区是否取得了任何进展？

@quinn我很确定你会需要一个 X 服务器，尽管你可以在帧缓冲区上运行 X11 (Xorg)，如果你愿意的话（见：https://www.x.org/releases/current/ doc/man/man4/fbdev.4.xhtml）。

_编辑：_

其实在稍微研究一下之后，这也可以通过使用臭氧来实现。 ( https://github.com/jakwu/ozone-fb )

添加臭氧还可以支持wayland，这是电子缺少的另一个功能，因为大多数 Linux 发行版已迁移到此功能。

根据臭氧-fb的描述和

@trusktr那是 2 年前的评论。 我建议不要将我的评论视为权威，因为这可能会改变（从那时起我就没有检查过）。

我将 headless lib 添加到电子并调用 HeadlessShellMain。
跑：

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

然后它显示：

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.

这是否意味着已经实施了无头？

@bigben0123这很有趣也很令人兴奋！ 所以你已经编译了你自己的电子版本，结合了铬的无头壳？

你有没有在 Linux 上没有 X 的环境中测试过它是否有效？

当chromium 在headless 模式下运行时，渲染子进程以传递的-headless 标志启动（你可以看到这是你从内存中使用'ps args'）。 这是否发生在你身上？

（如果您尝试使用-headless 启动它，那么当前的电子很奇怪，该标志不会传递给渲染进程，而是传递给 GPU 进程。）

@bigben0123这很有趣也很令人兴奋！ 所以你已经编译了你自己的电子版本，结合了铬的无头壳？

你有没有在 Linux 上没有 X 的环境中测试过它是否有效？

当chromium 在headless 模式下运行时，渲染子进程以传递的-headless 标志启动（你可以看到这是你从内存中使用'ps args'）。 这是否发生在你身上？

（如果您尝试使用-headless 启动它，那么当前的电子很奇怪，该标志不会传递给渲染进程，而是传递给 GPU 进程。）

是的，我在 ubuntu 上运行它，它只是在用户命令模式下启动。
Headless 已通过：

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你有什么地方有改动吗？ 即使由于某种原因这不能使其成为电子核心，我也希望能够使用它。

此提交仅将 chrome headless lib 合并到电子，您可以像使用 chrome 一样使用它。
https://github.com/bigben0123/electron/commit/b6cad8993d68d39f1732aa6ed5ece0135b9ae0c8

就我而言，chrome 和 headless 具有不同的内容层实现。 就像两个浏览器外壳一样，如果您以无头方式开始，则与 chrome 无关，除非您以“chrome --headless”开头。

Headless 的目标之一是“最大限度地减少对 Chromium 代码库的侵入性或无头特定更改（例如，#ifdefs）的数量”。

因此，很难实现电子无头去除xvfb。 我们可以让电子支持无头，但你不能执行电子应用程序。

我们可以使用 headless 的实现来代替电子的实现来获得一个新的 headless 分支。

去除电子/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" ]

用。。。来代替：
"//用户界面/显示",
"//ui/事件/设备",