Electron: 预期的应用程序包大小？

这是预期的大小，没有办法让它更小。

真的有那么大吗？ 我捆绑的 windows 和 linux 版本要小得多，查看 Electron Framework 文件夹，有 Electon Framework 文件的三个副本，每个副本一个：

ContentsFrameworksElectron Framework.framework
ContentsFrameworksElectron Framework.frameworkVersionsA
ContentsFrameworksElectron Framework.frameworkVersionsCurrent

这些应该是符号链接吗？

Windows 和 Linux 版本有多小？

我也在想这个问题。 以下是我的电子应用程序的尺寸：

osx - 117.3 mb
 linux32 - 60.3 mb
 linux64 - 55.2 mb
 赢得 ia32 - 47.8 mb
 赢 x64 - 66.2 mb

谢谢！

是否有计划在未来版本中尝试减小框架的大小？ 这使得很难证明将 Electron 用于小型应用程序的合理性（应用程序本身的大小将与 Electron 的大小相形见绌）。

我可以确认我的电子应用程序包与@davefedele 的大小大致相同。

你可以压缩你的应用程序，如果你使用electron-packager你可以忽略一些你在应用程序运行时不需要的节点模块，这使它更小一些。 例如，我有一个 37MB 的压缩 Electron 应用程序（注意 Windows 版本要大得多，因为它包含一个 Git 副本）。

但是 Electron 中总会有很大一部分 Chrome，所以能做的只有这么多。 Electron 本身现在约为 33MB。

OS X 压缩的大小与其他平台相似，这可能意味着您用来测量大小的应用程序可能会误解符号链接？

就我而言，我使用的是不使用electron-packager的电子样板，我的电子应用程序文件夹使用 python 脚本压缩并通过 aws s3 分发。 所以我的第一个想法是在压缩时没有遵守符号链接（而不是文件大小被误解）。

我必须研究一下，是否有任何存在的符号链接列表？ 我对 mac 计算机的访问非常有限（我使用 CI 服务器为每个平台打包我的应用程序）。

paul<strong i="5">@psamathe</strong>:/Applications/Slack.app% find . -type l
./Contents/Frameworks/Electron Framework.framework/Electron Framework
./Contents/Frameworks/Electron Framework.framework/Libraries
./Contents/Frameworks/Electron Framework.framework/Resources
./Contents/Frameworks/Electron Framework.framework/Versions/Current
./Contents/Frameworks/Mantle.framework/Headers
./Contents/Frameworks/Mantle.framework/Mantle
./Contents/Frameworks/Mantle.framework/Modules
./Contents/Frameworks/Mantle.framework/Resources
./Contents/Frameworks/Mantle.framework/Versions/Current
./Contents/Frameworks/ReactiveCocoa.framework/Headers
./Contents/Frameworks/ReactiveCocoa.framework/Modules
./Contents/Frameworks/ReactiveCocoa.framework/ReactiveCocoa
./Contents/Frameworks/ReactiveCocoa.framework/Resources
./Contents/Frameworks/ReactiveCocoa.framework/Versions/Current
./Contents/Frameworks/Squirrel.framework/Headers
./Contents/Frameworks/Squirrel.framework/Modules
./Contents/Frameworks/Squirrel.framework/Resources
./Contents/Frameworks/Squirrel.framework/Squirrel
./Contents/Frameworks/Squirrel.framework/Versions/Current

昨天我终于能够调查这个问题，确实我的问题是由符号链接没有保留引起的。 所以我的应用程序大小从 ~110Mbs 急剧缩小到 ~45Mbs。

@carlosperate你能描述一下你是如何修复符号链接的吗？

好吧，重要的是要强调我没有使用electron-packager 。 我有一个 python“构建脚本”（在 windows、linux 和 os x 中运行相同的脚本），它可以构建独立于我的电子应用程序的其他东西，然后如果在 mac 上运行，它会将所有内容复制到一般的 OS X 应用程序包目录中，并且最后将所有内容压缩到一个文件中。

所以，在我的特定情况下，我的脚本有两个问题，我在不尊重符号链接的情况下复制电子文件（很容易修复），然后 Python 中的zipfile模块也不尊重符号链接，这并不像我预期的那么容易。 如果你用谷歌搜索这个问题的解决方案，你会发现一些奇怪的实现比真正的解释更接近魔术的文章，所以在尝试让它工作一段时间失败后，我最终只运行了一个执行 os x 的子进程zip CLI 命令，带有尊重符号链接所需的标志。

FWIW，在 Linux 上创建 zip 以分发到 OS X 时，您必须使用-y参数来正确处理符号链接：

$ zip -r -y app.zip app

#SLACK 做了什么？ 为什么他们的应用这么小？
zip 存档文件为 24.6 MB。

Windows 和 linux 版本或多或少是我所期望的，我想知道他们的 OSX 版本怎么这么小。

最后我检查了 slack 在 Mac 端使用MacGap

http://electron.atom.io/#built -on-electron Slack 在列表中。

是的，Slack 的 Windows 和 Linux 应用程序是基于 Electron 构建的，但 Mac 应用程序使用 MacGap。

@joshaber我认为你是对的。 Slack mac 应用程序只有 ~36 MB。

你们知道 Electron 是否有任何减少最终包大小的计划吗？ 那太不可思议了。

你们知道 Electron 是否有任何减少最终包大小的计划吗？ 那太不可思议了。

你可以从 Chromium、Node.js、V8 等中取出这么多，并且仍然有一个可以工作的产品。 不幸的是，由于所有内容都经过修补才能正常工作，因此它并不像使用每个版本的独立版本来减少大小那么容易。 我相信 Electron 团队想要更小的尺寸。 但你就是无法计划并实现它。 认为您可以删除甚至 10-20 兆的代码和资源并期望一切运行稳定，这对整个项目来说太苛刻了。

如此真实的@baconface ......不过有一件事帮助了我：我将诸如电子预建、电子构建器和电子打包器之类的模块以及它们的所有依赖项放在“应用程序”文件夹中。 将它们从应用程序的 package.json 中删除并再次构建为我节省了很多大小。 我使用了电子构建器的two-package.json 结构。

@leonelcbraz随意借用或从我的忽略正则表达式中获取想法electron-packager 。 我在 bin 目录中创建了可执行文件，有一个 src 目录来存放未压缩的源文件，使用 Grunt 进行构建，并在那里放了我不需要的其他东西。 如果我在一个项目上工作，我不需要使用节点上下文，我只需将nodeIntegration为false并忽略整个 node_modules 目录。 这大大减少了我的分布大小。

(^(/bin|/src)$|[Gg]runt(.*)|node_modules/grunt-(.*)|node_modules/electron-(.*))

此外，无需使用 two-package.json 结构。 NPM 支持开发者依赖。 您可以通过npm install <package name> --save-dev安装一个。 然后你会注意到在你的 package.json 你有一个dependencies和devDependencies ，你的依赖关系整齐地分开。 像我上面所做的那样修改electron-packager的忽略正则表达式，您可以将它们与您的应用程序完全隔离，但可以在正常的 node.js 环境中工作。

编辑：这比这更容易！

听起来不错。 谢谢你的分享 ：）

Slack 现在有 Mac 客户端的 Electron 测试版。 旧的 Mac 二进制文件（使用 MacGap）在磁盘上为 36MB。 新的 Mac 二进制文件（使用 Electron）是 175MB。 其中 124MB 是 Electron 框架。

@NelsonMinar这

同意。

使用@baconface ignore regex 对减少应用程序大小有很大帮助，我还手动忽略了更多的 node_modules，如果没有，我的应用程序可以正常运行，这使我的 Mac 应用程序总大小达到了大约 50MB，Windows 大约为 60MB。

@pierreraii很高兴它有所帮助。 一个重要的注意事项是NPM3 改变了 node_module 目录的工作方式。 因此，此技巧可能无法达到您的预期。 不过，您可以使用npm i npm<strong i="7">@2</strong> -g将 NPM 降级到版本 2。

将来，我们工作中项目的解决方案是使用 NPM3，但将我们不希望的所有内容都作为开发依赖项发布。 我们在全球范围内安装我们的 Electron 构建工具，而不是项目级别。 然后使用npm install --only=production安装只需要的模块。 然而，这对于开源项目并不理想，但它适用于我们的办公室。 不幸的是，我们必须有这样一个奇怪的设置，但很怀疑 NPM 是否会在设计时考虑到 Electron，因为它只是 NPM 生态系统中的一个昙花一现。

是的，告诉网络开发人员在顶部处理电子几乎是不可能的。 只是考虑一个可以两者兼而有之的环境......目前我将我的电子应用程序建立在预先部署的服务器上，因为它们之前和所有其他服务器都可以，理想情况下共享相同的依赖项。 如果 asar 可以成为真正的 fs 用户，那么我会考虑解决大小和复制问题，尤其是使用本机扩展

@baconface您无需担心任何这些。 只需像平常一样安装您的依赖项（ dependencies prod deps 和devDependencies dev deps），然后在打包阶段（ electron-packager为您执行此操作）只需复制您的应用程序文件夹到临时目录并运行。

npm prune --production

无论您的 NPM 版本如何，这都会破坏所有开发依赖项，从而导致可能的最小大小。

与仅使用 --production 相比，您可以再删除 40-80+ %

与仅使用 --production 相比，您可以再删除 40-80+ %

如果是这种情况，您的依赖项配置不正确，如果您需要删除一个模块而prune --production没有删除它，则意味着它已被识别为生产依赖项。 将它移动到devDependencies将导致它被删除。

哦对不起，忘了说：如果你构建一个文件掩码，它会删除自述文件、许可证……而仅 node-gyp 就会产生 100 倍的结果

@xblox我只能想象那些自述文件/许可证之类的东西就像几千字节一样，很酷的新技巧是运行yarn clean它会自动为你擦除这些东西。

@MarshallOfSound您会感到惊讶，尤其是当您使用本机模块时。 周围堆满了垃圾。 yarn clean方法可能是一个不错的方法

@MarshallOfSound做你自己的文件掩码值得每一分钱，它总是令人惊讶一些包里面的东西。 它不仅仅是几千字节，但我会检查纱线是否干净。 谢谢指点。

@MarshallOfSound ， @paulcbetts ：在玩过yarn clean ：它只清理了提到的文件掩码可能的 70% 左右

如果我们只想编写一个没有任何 node 模块依赖项的 hello world 应用程序，为什么打包器仍然扭曲一切？ 最先进的解决方案是使用yarn clean ，不是吗？

我的 node_modules 是 40 MB，electron 是 140MB

使用电子生成器和这个文件 glob 我在我的桌面应用程序上获得了大约 80%

files:[
"**/*",
                "!**/.*",
                '!buildResources{,/**/*}',
                '!**/node_modules/**/{CONTRIBUTORS,License,CNAME,AUTHOR,TODO,CONTRIBUTING,COPYING,INSTALL,NEWS,PORTING,Makefile,license,LICENCE,LICENSE,htdocs,CHANGELOG,ChangeLog,changelog,README,Readme,readme,test,sample,example,demo,composer.json,tsconfig.json,jsdoc.json,tslint.json,typings.json,gulpfile,bower.json,package-lock,Gruntfile,CMakeLists,karma.conf,yarn.lock}*',
                "!**/node_modules/**/{man,benchmark,node_modules,spec,cmake,browser,vagrant,doxy*,bin,obj,obj.target,example,examples,test,tests,doc,docs,msvc,Xcode,CVS,RCS,SCCS}{,/**/*}",
                "!**/node_modules/**/*.{conf,png,pc,coffee,txt,spec.js,ts,js.flow,html,def,jst,xml,ico,in,ac,sln,dsp,dsw,cmd,vcproj,vcxproj,vcxproj.filters,pdb,exp,obj,lib,map,md,sh,gypi,gyp,h,cpp,yml,log,tlog,Makefile,mk,c,cc,rc,xcodeproj,xcconfig,d.ts,yaml,hpp}",
                "!**/node_modules/**!(dom-to-image).min.js",
                "!**/node_modules/!(serialport|xpc-connection|unix-dgram|mraa)/build{,/**/*}", //prevent duplicate .node
                "!**/node_modules/**/node-v*-x64{,/**/*}", //prevent duplicate .node
                "!**/node_modules/contextify{,/**/*}",
                "!**/node_modules/jsdom{,/**/*}",
                "!**/node_modules/babe-runtime{,/**/*}",
                "!**/node_modules/bluebird/js/browser{,/**/*}",
                "!**/node_modules/xterm/dist{,/**/*}",
                "!**/node_modules/source-map/dist{,/**/*}",
                "!**/node_modules/lodash/fp{,/**/*}",
                "!**/node_modules/moment/src{,/**/*}",
                "!**/node_modules/moment/min{,/**/*}",
                // "!**/node_modules/moment/locale/!(fr.js|en.js|ja.js)",
                "!**/node_modules/async/!(dist|package.json)",
                "!**/node_modules/async/internal{,/**/*}",
                "!**/node_modules/ajv/dist{,/**/*}",
                "!**/node_modules/ajv/scripts{,/**/*}",
                "!**/node_modules/asn1/tst{,/**/*}",
                "!**/node_modules/axios/lib{,/**/*}",
                "!**/node_modules/axios/!(index.js|package.json)",
                "!**/node_modules/axios/dist/axios.min.js",
                "!**/node_modules/bluebird/js/browser{,/**/*}",
                "!**/node_modules/dom-to-image/src{,/**/*}",
                "!**/node_modules/xterm/src{,/**/*}",
                "!**/node_modules/qs/dist{,/**/*}",
                "!**/node_moduleslog4js/logs{,/**/*}",
                "!**/node_modulesi18next/!(index.js|package.json|dist)",
                "!**/node_modulesi18next/dist/!(commonjs)",
                "!**/node_modules/viewport-dimensions/dist{,/**/*}",
                "!**/node_modules/validator/!(lib|index.js|package.json|validator.js)",
                "!**/node_modules/moment-timezone/builds{,/**/*}",
                "!**/node_modules/moment-timezone/data/meta{,/**/*}",
                "!**/node_modules/moment-timezone/data/unpacked{,/**/*}",
                "!**/node_modules/node-pre-gyp/!(lib|package.json)",
                "!**/node_modules/node-pre-gyp/lib/!(util|pre-binding.js|node-pre-gyp.js)",
                "!**/node_modules/node-pre-gyp/lib/util/!(versioning.js|abi_crosswalk.json)",
                "!**/node_modules/ssh2/util{,/**/*}",
                "!**/node_modules/source-map-support/browser-source-map-support.js",
                "!**/node_modules/usb/!(package.json|src)",
                "!**/node_modules/opencv/!(package.json|lib)",
                "!**/node_modules/json-schema/!(package.json|lib)",
                "!**/node_modules/hawk/dist/{,/**/*}",
                "!**/node_modules/hawk/lib/browser.js",
]

问题是它真的依赖于你使用的模块，这使得维护起来很痛苦！

@farfromrefug如果您使用的是开源库，请小心运送您的应用程序，您使用的库有可能要求许可证文件随所有应用程序一起提供，而您却盲目地将它们全部删除。

@OmgImAlexis其实你是对的，我应该保留许可证文件。 谢谢！

只是抬头。 electron-packager足够聪明，可以清除devDependencies列出的依赖项。 所以我把我的大部分包移到那个地方，并使用 Grunt 将我使用的脚本捆绑在一个 JS 文件中。 所以现在我忽略的正则表达式看起来像这样"(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|build.js)" 。 给我相同的结果，但更容易，我不必手动添加依赖路径到我的正则表达式。 甚至可以使用 Yarn 存储依赖项的方式。

我最近从https://github.com/electron/simple-samples.git克隆了用于学习目的的示例项目
电子包装器 C:userlearningnodeclonedAppsimple-samplesactivity-monitor cpu --platform=win32 --arch=x64 --ignore="node_modules"

我想知道一个简单的应用程序的包大小是 132 Mb。
有没有办法减少捆绑包的大小？

我会建议在你的可执行文件上使用UPX ，它是跨平台的，支持许多架构并且非常容易使用，但不幸的是，Electron 的团队似乎不想屈服于此。
（之前已经请求：https://github.com/electron/electron/issues/5506）

否则，我的测试通过使用 UPX 压缩NW.js （最终大小降低约 60%）而运行良好，尽管我没有尝试过它是否仍然适用于最新版本......
因此，如果大小很重要，也许您可​​以专注于使用这个进行开发？

通过将electron和几乎任何其他非运行时包移动到devDependencies中的package.json ，运行rm -rf node_modules我能够将我的压缩 OSX 分发大小设置为 52MB npm install --production 。

在打包应用程序时， electron-packager会抱怨项目的node_modules缺少electron依赖项。 您可以通过向electron-packager提供以下标志来解决这个问题：

--electron-version=1.7.11

用您想要的electron-packager版本替换1.7.11 。

@eladnava感谢您提供信息。 我会检查你提供的步骤。 当我将应用程序转换为 dmg 时，它的大小为 53 MB。

我不知道/没有阅读所有以前的消息，所以请告诉我是否已经说过。

是否可以将 Electron 框架本身分开并只发布应用程序？

据我了解，Electron 应用程序的交付方式是包含 fw。 这听起来像是发布一个包含 JRE 的 Java 应用程序。

是否可以在操作系统上安装一个 Electron 框架，以便所有可以使用该版本的应用程序都可以使用？

@eladnava您确实意识到如果目标机器上没有安装电子，您的应用程序将无法运行？

@fab1an ：我认为@yasinaydin明白这一点。 他想要一个用户可以为所有使用 Electron 的应用程序安装的 Electron 公共运行时。 这已经在电子/电子#673 中讨论过，目前没有解决方案。

@js-choi @fab1an我不完全确定它是如何工作的，但我有一种感觉，Electron 预先捆绑在electron-packager ，在打包的应用程序中包含的Electron Framework.framework中。

因此，没有理由在您的应用程序的node_modules捆绑electron node_modules 。 此外，我的工作方法不需要在目标机器上安装 npm electron包。

使用他们的技术，electrino 能够将一个 115 MB 的 Electron 应用程序制作成只有 167 kB。 我认为这项技术必须集成到电子中，一个 100MB 的 hello world 应用程序不是显示“Hello World”的正常大小：+1：

@spaceywolfi由于 Electrino 实际上并没有运行 Chrome / V8 引擎来渲染您的应用程序，而是使用 OSX 的本机 Web 浏览器引擎 (WebKit)，因此您不能真正使用 Electron 应用程序并使用 Electrino 构建它，尤其是如果您使用Electron API，因为它们在那里不可用。 至少现在还没有。

您可以尝试使用我提到的技巧将基本二进制大小降低到 ~50MB。

@eladnava谢谢你的解释！

@eladnava

我不完全确定它是如何工作的，但我有一种感觉，Electron 预先捆绑在电子打包器中，在打包应用程序中包含的 Electron Framework.framework 中。

因此，没有理由在应用程序的 node_modules 中捆绑电子。 工作方法。

我的electron有electron-packager devDependencies 。 这样我可以分配electron ./dist/js/main.js在我的脚本package.json 。 因此，例如运行npm run launch将快速启动一个未打包的准备测试我的 Electron 应用程序实例。 此外， electron-packager将使用为electron列出的版本，因此您的打包版本与您的 Electron 测试版本相同。 它还应该自动从输出中去除electron和electron-packager 。

@培根布拉德

谢谢你的提示。 我最终在全局安装了electron和electron-packager以避免它们被打包到最终二进制文件的node_modules文件夹中。 我发现electron-packager没有从最终的二进制文件中自动去除这些依赖项，这导致我的二进制文件大小约为 100MB。 全局安装这两个包后，二进制大小下降到~50MB。

@eladnava这可能是因为您将它们作为依赖项而不是开发依赖项。 如果您使用npm install packagename --save-dev这会将其保存在您的package.json的适当区域。 它将显示在您的node_modules文件夹中，但打包后将被删除。

@培根布拉德

这确实是完全可能的。 但我确实认为，由于新版本的npm将所有依赖项的依赖项安装在根项目node_modules/文件夹中，因此这些可能已被electron-packager捆绑到最终的二进制文件中.

你知道electron-packager是否足够聪明，可以忽略那些devDependencies的依赖关系吗？

@eladnava

你知道电子包装器是否足够聪明，可以忽略那些 devDependencies 的依赖关系吗？

可以确认它省略了devDependencies依赖项。 即使您使用的是最新版本的 NPM 或 Yarn。

此外，您应该使用像 Gulp 或 Grunt 这样的构建系统来捆绑前端依赖项，并使它们也列在devDependencies中。 这是因为它们可能带有额外的源文件或其devDependencies 。 我唯一一次在dependencies有东西是因为我绝对需要发货。 您的脚本仍然希望在节点上下文中运行，因此您需要在加载浏览器上下文中的捆绑脚本之前调用window.module = module; module = undefined; 。 然后我确保我的打包程序在忽略选项"(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)"有这个。 完成所有这些步骤基本上可以消除过度依赖批量或错误地包含源文件或构建文件夹。

@培根布拉德

为小贴士干杯！

嗨，大家好，

为了大大减少每个人的应用程序大小，为每个人节省带宽，使每个人的构建过程更容易等，优化/思考必须以不同的方式完成，而不仅仅是忽略一些 node_modules。

如何使用 Java 和 Java 应用程序已经成功使用了几十年的相同想法：依赖于“JRE”（在我们的例子中将是“ERE”）。

这样，ERE 将在机器上为第一个需要它的应用程序全局安装（需要 ERE 的过程可以由每个平台的应用程序安装程序自动执行），然后每个新应用程序将只使用这个现有的这个 ERE .

ERE 需要一个自动更新功能和向后兼容性（没有 bcb！）才能工作，但我很确定这是微不足道的。

然后，每个 Electron 应用程序的重量都只有几 MB。 节省用户时间。 节省开发人员的时间和带宽以及构建复杂性。

之前有人提出过吗？ 如果是这样，那又如何？ 我认为这是唯一也是最好的方法。

@RenaudParis我之前提出过它，也许还有更多，但到目前为止我还没有听说过任何严肃的作品。

@yasinaydin我想了很多，人们以前肯定已经考虑过这一点。

那么，开发团队有什么意见吗？ @zcbenz这会让很多人感到高兴，并使 Electron 面向未来的大发展（因为让我们面对现实：在每个应用程序中嵌入两个框架严重限制了小型应用程序的使用，这是一个经常发生的咆哮多年来）

JRE 不是一个很好的例子吗？

@RenaudParis和@yasinaydin ，有很多原因让全球安装电子永远不会发生。

首先，在野外的所有生产电子应用程序中，可能有 20 多个不同版本的电子在使用。 您会选择在全球范围内使用哪个版本？ 它之所以如此分散是因为 Electron 的发布周期很快，而且开发人员希望访问最新的 Chrome 功能。

我们的应用程序仅使用单一版本的电子进行测试，为了 40MB 的下载量，我们为什么要冒风险和支持成本，让它在任何其他未经测试的随机版本上运行？

使每个人的构建过程更容易

许多电子应用程序使用本机模块，在大多数情况下必须针对正在使用的特定版本的电子构建这些模块。 你会如何解决这个问题？

随意创建一个开发人员可以使用的全球版本的电子，但我想你会发现由于上述原因，几乎没有人会使用它！

@timfish
there are so many reasons having a global install of electron will never happen.
这听起来像是其中之一： https :

由于 Node/v8 或电子二进制文件不是那么大，如果需要，全局 ERE 可以下载丢失的组件以供使用一次。 还可以为这些全局 ERE 实现一些捆绑逻辑，例如 Node.js 9.x 而不是单独的 Node.js 9.0、9.1 等。

我不知道，但我不认为这就是做事的态度......“哦，这不可能完成。哦，这是不可能的。没有任何意义。” 相反，它应该是“我们如何完成/解决这个 x？”

@timfish这是个悲伤的消息...我个人不太关心 40MB 的文件，但是 120MB（据我所知）对于 hello world 来说有点太多了。

首先，在野外的所有生产电子应用程序中，可能有 20 多个不同版本的电子在使用。 您会选择在全球范围内使用哪个版本？

正如我所说，需要向后兼容。

开发人员希望访问最新的 Chrome 功能

因此渐进增强...对吗？ 在任何情况下，如果应用程序可能需要特定版本的 ERE，这将触发全局 ERE 的更新，那么即使是渐进式增强也不是强制性的。

你会如何解决这个问题？

如果某些人需要专门编译的模块，他们可以自由地嵌入他们自己的模块的自定义版本（无论如何在 ERE 中都不可用）并指定 ERE 的最低版本。 如果 ERE 更新到更新的版本，我想有两个明显的解决方案：要么更新他们的模块（与今天的 Node 中的依赖项相同），要么我们也可以允许ERE 的多个全局版本（与 JRE 相同）。 我认为这不是问题。

电子有一个快速的释放周期

这很棒，毫无疑问。 但也许人们可以通过每月发布来生存，因此限制了 ERE 版本的数量。

随意创建一个全球版本

是的...不会那样做。 我没有技能，但如果我有，我会的。

我只能提供我认为相关的建议，让专家做他们的工作：要么他们告诉我我的建议是个白痴（很可能是这种情况），要么他们认为这可能会带来一些好的结果. 任何 ：）

我仍然认为全局 ERE 将是最好的解决方案，即使这意味着有多个 ERE 来满足不同应用程序的各种需求。 但是，同样，这只是我与 JRE 比较时的一个想法。

@雷诺巴黎

这是个悲伤的消息...我个人不太关心 40MB 的文件，但是 120MB（据我所知）对于 hello world 来说有点太多了。

120MB 是未压缩的，如果你压缩它大约是 40MB。 例如，用于 Windows 安装 EXE 的 VSCode 64 位约为 42.8 MB。

就我个人而言，作为用户，即使我必须下载 200MB 而不是 10MB，我也总是宁愿拥有独立的应用程序，而无需管理全局 JRE（或 ERE）。

它不仅仅是 120mb，我创建了一个简单的 Web 应用程序，它在 Web 服务器上约为 1mb，但在 OS X 上作为 Electron 应用程序约为 300mb

另外，当在同一台机器上运行许多 Electron 应用程序时，这一点变得更加重要。
然后它将是 10 倍，20 倍大。
现在在用 Electron 构建的计算机上有多个标准应用程序，如 Slack、VSCode 等。还有更大的项目，如 NodeOS。

Node.js 有超过 50 万个模块。 如果 Electron 变得更好、更快、更受欢迎、更小，那么桌面上就会有更多的应用程序，以及 GB 不必要的 Electron 文件。

Electron 并不是最好的框架。

我宁愿考虑拆分 Chrome 框架中不需要的部分，如 Flash 等。

@yasinaydin

在 Web 服务器上为 1mb，但在 OS X 上作为 Electron 应用程序约为 300mb

您需要在分发前清理您的应用程序（提示：检查您的 node_modules）。 例如，Windows 上的 VSCode 安装后为 228MB（可下载安装只有 42.8MB）。

但是，安装大小只是一个问题，另一个问题是应用程序使用了多少 RAM 和启动时间。 根据我的经验，一旦应用程序启动，应用程序的速度就不是问题。

Electron 不太适合小型应用程序，但对于像 VSCode 这样的大型应用程序来说，它是有效的。

另一个问题是使用了多少 RAM 应用程序和启动时间

@mvladic你不认为 ERE 可以解决另外两个问题吗？ 已经在应用程序之间加载和共享，等等。

好吧，也许人们不会同时运行 10 个 Electron 应用程序……但也许他们会！ 尽可能多地分解依赖关系很重要。

我知道 Electron 最初是作为 POC 推出的，然后需要非常频繁的发布来取悦开发人员。 但也许现在 Electron 更成熟了，必须采取一些措施来确保最佳的{加载时间、内存使用、下载大小}。

同样，我只是针对 Electron 用户似乎从一开始就在咆哮的问题提出一个（可能是幼稚的，我不知道）解决方案。 但就我而言，我真的不介意电子的当前状态以满足我自己的小需求。 Electron 很棒，我只是在想办法让它变得更好。

Electron 并不是最好的框架。

@fab1an ，取决于人们的需求。 对我来说，它非常适合我的需求，因为我不确定 PWA 是否足够成熟。 但也许对于其他人来说 Qt 会更适合，你是对的。

之前已经提出并讨论过运行时，现在仍然是一个公开的讨论。 但这是说起来容易做起来难的事情之一。 正如您所看到的，并非每个人都能够达成一致或弄清楚如何正确地将其启动，使其在生产中可靠地工作。 如果你认为你可以为讨论做出贡献或帮助开始讨论，我认为没有人会介意额外的帮助。

包括我自己在内的许多开发人员都对发布 40 兆的下载量并使用较小的增量更新进行更新感到非常满意。 今天的人们下载 40 兆的程序没有问题。 即使是有几个 meg 文件的小程序也可能下载并安装 40 megs - 2 gigs，而且似乎没有人有问题。 用它。 即使运行时选项可用，用户也可能不会拥有它，并且无论如何都必须下载 40 多个 megs 才能运行您的项目。

如果此警告不适合您，请在需要时寻找另一种选择。 我的意思不是直截了当地说，有时您必须消除技术才能满足您希望满足的目标和条件。 但这并不会使 Electron 成为一项糟糕的技术或使其无法用于许多其他技术。 Electron 并不意味着解决所有解决方案。 它实际上永远不会。

@baconbrad如果您的评论是靶向我，我不明白为什么，因为我明确地说了好几次，我是很高兴，因为它是，并且电子正是适合我的（特定的）需求的技术。

我只是说我看到很多人到处抱怨包裹的大小，而我只是为这个问题提供了一个（再次天真的）解决方案，这对我来说似乎是理想的。 但我很可能会弄错，无论如何它绝对不会阻止我使用 Electron 来满足我未来的需求:)

即使运行时选项可用，用户也可能不会拥有它，并且无论如何都必须下载 40 多个 megs 才能运行您的项目。

是的，但我认识很多人，即使在巴黎市中心，他们也只有 5Mbps 的互联网连接，对于这些人来说，为每个应用程序节省 40MB（即 320Mb）意味着每次应用程序更新时节省几分钟（不要忘记 40MB 将用于每次更新，而不仅仅是第一次安装），因为他们没有使用互联网连接。

它甚至没有考虑到 RAM 的节省，尤其是对于笔记本电脑。 再说一次，我个人并不担心，因为我有一台配备 32GB RAM 的相对较好的机器，但我在这里考虑的不是我自己，而是那些抱怨的人，并希望为他们找到解决方案。

最后但并非最不重要的一点是，您可能拥有良好的连接，我也是如此（如果您愿意，可以快速连接！:)），而且我们可能都有 16、32 或 64GB 的 RAM，这就是您（您自己）不这样做的原因不介意为每次更新下载 40MB，但是您的用户呢（假设您将应用分发给人们）？

无论如何，我不会为此争吵，我只是寻求帮助，正如我所说，我很高兴，而且我有很多事情要处理。

如果有人认为我可以帮助他们想出解决方案，我很乐意伸出援手，否则我会回去工作:)

干杯，

当将更多依赖项移动到 devDependencies 时，我看到的一件事是，它需要更多的时间来构建它。

````
✔ 构建主进程

• 构建渲染器过程
  ````

它在“构建渲染器进程”上花费了更多时间，动画图标像崩溃一样停止，但没有。 然后它从渲染器报告中显示 203778ms。

将 devDependencies 移回依赖项，构建时间再次正常但应用程序很大。

如果我在构建过程中没有出现任何错误，则表示一切正常，对吗？

@karimhossenbux这对我来说很正常。 electron-packager中有一个 walk 函数，它遍历所有依赖项以确定它们是否应该存在。 使用新的平面样式依赖项而不是嵌套依赖项，确定不需要的依赖项需要更长的时间。 据我所知，没有办法避免额外的构建时间。

@baconbrad谢谢！ 我正在使用electron-builder但我想它的工作方式相同。

当用户第一次运行您的应用程序时，是否有任何电子包生成器仅包含您的源并下载其他源（仅对当前运行的操作系统用户而言是必需的）？ 这将使分发变得容易，并且应该会大大减少您的应用程序大小。

Electron，请不要走“ERE”路线。 是的，我知道你很臃肿，但我喜欢人们下载我的应用程序的方式，它运行良好，无需安装 deps、更新运行时环境或任何我认为我们在 2003 年左右摆脱的废话.

好吧，下载捆绑包仍然是一种选择。 没什么可抱怨的
关于这里:)

勒文。 2018 年 1 月 25 日 à 21:03，Luke Pighetti通知@github.com
评论：

Electron，请不要走“ERE”路线。 是的，我知道你很臃肿，
但我喜欢人们如何下载我的应用程序并且它运行良好
无需安装 deps，更新运行时
环境，或者任何我认为我们摆脱了大约的废话
2003 年。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/electron/electron/issues/2003#issuecomment-392151709 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AApUIBjAeVZ7T4SKo8LyW6RT65XnpiKgks5t2FWfgaJpZM4FGGer
.

我只是在等待微软工程师改进 Electron。
https://news.ycombinator.com/item?id=17229973

我只是在等待微软工程师改进 Electron。
https://news.ycombinator.com/item?id=17229973

@zcmgyu自从他们开始将 Electron 用于 VS Code 以来，微软已经聘请开发人员在 Electron 上工作了几年。 他们是一些最大的贡献者，并对其进行了相当多的改进。

如果您的应用程序超过 100MB，
可能是您的 exe 包含您的 node_modules 文件夹的很大一部分。
请注意，依赖项中 package.json 中声明的所有内容都将重新导入到最终的可执行文件中。
（验证很简单：反编译可执行文件就够了）
所以请记住只在依赖项（电子日志、电子更新程序）中定义必要的库，并在 devDependencies 中添加所有其他库。

然后，您的应用程序将“仅”50MB ...

我的应用程序很小 - 这是回购。 最新实验版重约700mb
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

我也在想这个问题。 以下是我的电子应用程序的尺寸：

  osx - 117.3 mb

linux32 - 60.3 mb
linux64 - 55.2 mb
赢得 ia32 - 47.8 mb
赢 x64 - 66.2 mb
谢谢！

惊人的！ 你能分享一下如何将电子应用程序缩小到如此小的尺寸吗？