Electron: Ожидаемый размер пакета приложений?

Это ожидаемый размер, уменьшить его невозможно.

Неужели ожидается, что он будет таким большим? мои связанные сборки Windows и linux намного меньше, и, глядя в папку Electron Framework, есть три копии файла Electon Framework, по одной на каждую:

СодержаниеFrameworksElectron Framework.framework
СодержаниеFrameworksElectron Framework.frameworkVersionsA
СодержаниеFrameworksElectron Framework.frameworkVersionsCurrent

Это должны быть символические ссылки?

Насколько малы сборки Windows и Linux?

Мне тоже интересно об этом. Вот размеры моего электронного приложения:

osx - 117,3 мб
 linux32 - 60,3 МБ
 linux64 - 55,2 МБ
 win ia32 - 47,8 мб
 win x64 - 66,2 мб

Спасибо!

Есть ли план попытаться уменьшить размер фреймворка в будущих выпусках? Это затрудняет оправдание использования Electron для небольших приложений (где размер самого приложения будет меньше размера Electron).

Я могу подтвердить, что мои пакеты электронных приложений примерно такого же размера, как @davefedele.

Вы можете заархивировать свое приложение, и если вы используете electron-packager вы можете игнорировать некоторые модули узлов, которые вам не нужны, когда приложение работает, это делает его немного меньше. Например, у меня есть заархивированное приложение Electron объемом 37 МБ (обратите внимание, что версия для 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

Вчера я наконец смог разобраться в этом, и действительно, моя проблема была вызвана несохранением символических ссылок. Таким образом, размер моего приложения резко сократился с ~ 110 Мбайт до ~ 45 Мбайт.

@carlosperate Можете ли вы описать, как вы исправляли свои символические ссылки?

Что ж, важно подчеркнуть, что я не использую electron-packager . У меня был скрипт сборки python (тот же скрипт работает в Windows, Linux и OS X), который будет строить другие вещи, независимые от моего электронного приложения, затем, если он работает на Mac, он копирует все в общие каталоги пакетов приложений OS X и наконец, заархивируйте все в один файл.

Итак, в моем конкретном случае с моим скриптом было две проблемы: я копировал электронные файлы без учета символических ссылок (очень легко исправить), а затем модуль zipfile в Python также не соблюдал символические ссылки, что оказалось не так просто, как я ожидал. Если вы решите проблему с помощью Google, вы найдете несколько статей со странными реализациями, которые были ближе к волшебству, чем к реальному объяснению, поэтому после некоторого времени безуспешных попыток заставить его работать, я закончил тем, что просто запустил подпроцесс, который выполняет os x zip CLI-команда с необходимыми флагами для соблюдения символических ссылок.

FWIW, при создании zip-архива в Linux для распространения в OS X вам нужно будет использовать параметр -y для правильной обработки символических ссылок:

$ zip -r -y app.zip app

Что сделал #SLACK? Почему их приложение такое маленькое?
Размер файла архива zip составляет 24,6 МБ.

Версии для Windows и linux более или менее соответствуют моим ожиданиям. Интересно, откуда у них такая маленькая версия для OSX.

Последний раз, когда я проверял, в Slack использовался

http://electron.atom.io/#built -on-electronics Slack есть в списке.

Да, приложения Slack для Windows и Linux построены на Electron, но приложение для Mac использует MacGap.

@joshaber Думаю, ты прав. Размер приложения Slack для Mac составляет всего ~ 36 МБ.

Вы, ребята, знаете, есть ли у Electron какие-нибудь планы по уменьшению окончательного размера пакета? Это было бы невероятно.

Вы, ребята, знаете, есть ли у Electron какие-нибудь планы по уменьшению окончательного размера пакета? Это было бы невероятно.

Вы можете извлечь из Chromium, Node.js, V8 и т. Д. Так много всего, и при этом иметь рабочий продукт. К сожалению, поскольку все исправлено для работы, это не так просто, как использовать отдельные версии каждого из них, чтобы сократить размер. Я уверен, что команда Electron хотела бы меньшего размера. Но вы просто не можете спланировать и осуществить это. Это слишком едко для всего проекта, чтобы думать, что можно удалить даже 10-20 мегабайт кода и ресурсов и ожидать, что все будет работать стабильно.

Так что правда @baconface ... Одна вещь, хотя и помогла мне здесь: я помещал такие модули, как electronic-prebuilt, electronic-builder и electronic-packager, и все их зависимости в папку "app". Отрезав их из package.json приложения и снова построив, я значительно сэкономил. Я использовал структуру two-package.json от electronics-builder.

@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 теперь есть бета-версия Electron клиента Mac. Старый двоичный файл Mac (с использованием MacGap) занимал 36 МБ на диске. Новый двоичный файл Mac (с использованием Electron) составляет 175 МБ. 124 МБ из них - это Electron Framework.

@NelsonMinar Это отстой, ребята. Нужно что-то сделать с размером приложения.

Согласовано.

Использование @baconface ignore regex очень помогло с уменьшением размера приложения, я также вручную проигнорировал больше node_modules, которые были там, и мое приложение могло нормально работать без, что дало мне около 50 МБ от общего размера приложения Mac и около 60 МБ для Windows.

@pierreraii Рад, что это помогло. Важное замечание: NPM3 изменяет способ работы каталога node_module . В результате этот трюк может не оправдать ваши ожидания. Вы можете понизить NPM до версии 2, используя npm i npm<strong i="7">@2</strong> -g .

В будущем наше решение для нашего рабочего проекта будет использовать NPM3, но все, что нам не нужно, будет помещено в зависимость от разработчика. Мы устанавливаем наши инструменты сборки Electron по всему миру, а не на уровне проекта. Затем выполняем установку только необходимых модулей с помощью npm install --only=production . Однако это не идеально для проектов с открытым исходным кодом, но работает для нашего офиса. К сожалению, у нас должна быть такая странная настройка, но сомнительно, что NPM когда-либо будет разрабатываться с учетом Electron, поскольку это всего лишь небольшая ошибка в экосистеме NPM.

да, указать веб-разработчикам, чтобы они занимались электроном в топе, почти невозможно. просто думаю о env, который может быть и тем, и другим ... в настоящее время я базирую свои электронные приложения на предварительно развернутых серверах, поскольку они могут раньше и для всех остальных, в идеале разделяя одни и те же зависимости. если бы asar мог быть настоящим пользователем fs, я бы решил, что проблемы с размером и копированием решены, особенно с собственными расширениями.

@baconface Ни о чем из этого не беспокойтесь. Просто установите свои зависимости, как обычно (prod deps в dependencies и dev deps в devDependencies ), а затем на этапе упаковки ( electron-packager делает это за вас) просто скопируйте папку вашего приложения во временный каталог и запустите.

npm prune --production

Это уничтожит все зависимости разработчиков независимо от вашей версии NPM, что приведет к минимально возможному размеру.

вы можете получить еще 40-80 +% больше удаленных, чем просто с --production

вы можете получить еще 40-80 +% больше удаленных, чем просто с --production

Если это так, ваши зависимости настроены неправильно, если вам нужно удалить модуль, и prune --production не удаляет его, это означает, что он был распознан как производственная зависимость. Перемещение в devDependencies приведет к его удалению.

о, извините, забыл сказать: если вы создадите маску файла, которая удаляет readme, license, ... и только node-gyp дает в 100 раз больше

@xblox Я могу только представить, что эти readmes / лицензии и тому подобное - это как несколько килобайт, новый крутой трюк - запустить yarn clean который автоматически стирает эти вещи за вас.

@MarshallOfSound Вы будете удивлены, особенно если будете использовать собственные модули. Вокруг много мусора. Подход yarn clean может быть хорошим

@MarshallOfSound делает свою собственную маску файла, стоящую каждого пенни, всегда удивительно, что внутри некоторых пакетов. И это намного больше, чем несколько килобайт, но я проверю пряжу на чистоту. спасибо за указатель.

@MarshallOfSound , @paulcbetts : после игры с yarn clean : очищает только около 70% того, что возможно с указанной маской файла

Если мы просто хотим написать приложение hello world без каких-либо зависимостей узловых модулей, почему упаковщик все еще искажает все? Современное решение - использовать yarn clean , не так ли?

Мои node_modules 40 МБ, а электрон 140 МБ

Используя электронный конструктор и этот глобус файлов, я получаю около 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. Я создал приложение для монитора активности win32 x64, которое находится внутри клонированной папки, с помощью следующей команды:
электронный упаковщик C: userlearningnodeclonedAppsimple-samplesactivity-monitor cpu --platform = win32 --arch = x64 --ignore = "node_modules"

Я подумал, что размер пакета составляет 132 Мб для простого приложения.
Есть ли способ уменьшить размер пакета?

Я бы предложил использовать UPX в вашем исполняемом файле, который является кроссплатформенным, поддерживает множество архитектур и чрезвычайно прост в использовании, но, к сожалению, похоже, что команда Electron предпочитает не преклоняться перед этим.
(Уже запрашивалось ранее: https://github.com/electron/electron/issues/5506)

В остальном мое тестирование прошло хорошо, сжав
Итак, если размер имеет значение, может, вы могли бы сосредоточиться на разработке с этим?

Мне удалось увеличить размер моего заархивированного дистрибутива OSX до 52 МБ, переместив electron и почти любой другой пакет, не являющийся рабочим, в devDependencies в package.json , запустив rm -rf node_modules а затем npm install --production .

При упаковке приложения electron-packager будет жаловаться на отсутствие зависимости electron в node_modules проекта. Вы можете обойти это, установив следующий флаг для electron-packager :

--electron-version=1.7.11

Замените 1.7.11 желаемой версией electron-packager .

@eladnava Спасибо за информацию. Я проверю предоставленные вами шаги. Когда я конвертирую приложение в dmg, его размер составляет 53 МБ.

Я не знаю / не читал все предыдущие сообщения, поэтому, пожалуйста, скажите мне, было ли это уже сказано.

Можно ли отделить сам фреймворк Electron и просто отправлять приложения?

Насколько я понимаю, приложение Electron поставляется с встроенной прошивкой. Похоже на поставку приложения Java с включенной в него JRE.

Можно ли установить платформу Electron в ОС, чтобы все приложения, которые могут использовать эту версию, использовали ее?

@eladnava Вы понимаете, что ваше приложение не будет работать, если на целевой машине не установлен электрон?

@ fab1an : Думаю, @yasinaydin это понимает. Ему нужна общая среда выполнения Electron, которую пользователи могут установить для всех своих приложений, использующих Electron. Это уже обсуждается в электронном / электронном № 673, в настоящее время без разрешения.

@ js-choi @ fab1an Я не совсем уверен, как это работает, но у меня такое ощущение, что Electron поставляется в пакете electron-packager в пакете Electron Framework.framework который включен в пакет приложения.

Следовательно, нет причин также объединять electron в node_modules вашего приложения. Кроме того, для моего подхода к работе нет необходимости устанавливать пакет npm electron на целевой компьютер.

Компания electrino смогла сделать приложение Electron объемом 115 МБ до 167 КБ, используя свою технологию. Я думаю, что эта технология должна быть интегрирована в электрон, приложение hello world размером 100 МБ - это не нормальный размер для отображения «Hello World»: +1:

@spaceywolfi Поскольку Electrino на самом деле не использует движок Chrome / V8 для рендеринга вашего приложения, но использует собственный движок веб-браузера OSX (WebKit), вы не можете просто взять свое приложение Electron и создать его с помощью Electrino, особенно если вы используете Электронные API, поскольку они там недоступны. По крайней мере, пока.

Вы можете попробовать использовать упомянутый мною трюк, чтобы уменьшить базовый двоичный размер до ~ 50 МБ.

@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 из вывода.

@baconbrad

Спасибо за отзыв. Я закончил тем, что установил electron и electron-packager глобально, чтобы избежать их упаковки в папку node_modules финального двоичного файла. Я обнаружил, что electron-packager не удалял эти зависимости автоматически из окончательного двоичного файла, что привело к двоичному размеру ~ 100 МБ для меня. После глобальной установки этих двух пакетов размер двоичного файла упал до ~ 50 МБ.

@eladnava Скорее всего, это произошло потому, что они были у вас как зависимость, а не как зависимость разработчика. Если вы используете npm install packagename --save-dev это сохранит его в нужной области вашего package.json . Он появится в вашей папке node_modules но будет удален после упаковки.

@baconbrad

Это действительно возможно. Но я действительно думаю, что, поскольку более новые версии npm устанавливают все зависимости ваших зависимостей в корневой папке проекта node_modules/ , они могли быть объединены electron-packager в окончательный двоичный файл. .

Знаете ли вы, достаточно ли умен electron-packager , чтобы опустить эти devDependencies зависимости?

@eladnava

Знаете ли вы, достаточно ли умен electronic-packager, чтобы опустить зависимости этих devDependencies?

Могу подтвердить, что в нем отсутствуют зависимости devDependencies . Даже если вы используете последнюю версию NPM или Yarn.

Также вам следует использовать систему сборки, такую ​​как Gulp или Grunt, для объединения зависимостей внешнего интерфейса и включения их в список devDependencies . Это потому, что они могут поставляться с дополнительными исходными файлами или их devDependencies . Единственный раз, когда у меня что-то есть в моем dependencies это потому, что мне это абсолютно необходимо отправить. Ваши сценарии по-прежнему хотят запускаться в контексте узла, поэтому вам нужно будет вызвать window.module = module; module = undefined; перед загрузкой связанных сценариев в контексте браузера. Затем я убеждаюсь, что мой упаковщик имеет это в опции игнорирования "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)" . Выполнение всех этих шагов в основном устраняет чрезмерное увеличение количества зависимостей или ошибочное включение исходных файлов или папок сборки.

@baconbrad

Приветствую за чаевые, дружище!

Привет, народ,

Чтобы радикально уменьшить размер приложения для всех, сэкономить трафик для всех, упростить процесс сборки для всех и т. Д., Оптимизация / мышление должны выполняться иначе, чем просто игнорировать некоторые node_modules.

Как насчет того, чтобы использовать ту же идею, которую Java и приложения Java успешно использовали на протяжении десятилетий: иметь зависимость от «JRE» (которая в нашем случае будет «ERE»).

Таким образом, ERE будет установлен глобально на машине для первого приложения, которое в нем нуждается (процесс запроса ERE может быть автоматизирован установщиком приложения для каждой платформы), и тогда каждое новое приложение будет использовать только этот существующий этот ERE .

ERE потребуется функция автоматического обновления и обратная совместимость (без bcb!), Чтобы это работало, но я почти уверен, что это тривиально.

Тогда каждое приложение Electron будет весить всего пару МБ. Экономия времени пользователей. Экономия времени и ресурсов разработчиков, а также сложность сборки.

Предлагалось ли это раньше? Если да, то как насчет этого? Я думаю, что это единственный и лучший способ.

@RenaudParis Я предлагал это раньше и, может быть, еще несколько, но пока я не слышал серьезных работ.

@yasinaydin Я так и думал, люди, должно быть, думали об этом раньше.

Что ж, тогда какой вклад от команды разработчиков? @zcbenz Это сделало бы так много людей счастливыми и сделало бы Electron

Разве JRE не является отличным примером для подражания здесь?

@RenaudParis и @yasinaydin , есть так много причин, по которым глобальной установки электрона никогда не произойдет.

Во-первых, из всех существующих в мире производственных электронных приложений существует около 20+ различных версий электронных приложений. Какую версию вы бы выбрали глобально? Он так фрагментирован, потому что у Electron быстрый цикл выпуска, а разработчикам нужен доступ к последним функциям Chrome.

Наши приложения тестируются только с одной версией electronic, и ради загрузки 40 МБ зачем нам рисковать и платить за поддержку, позволяя запускать его на любой другой случайной непроверенной версии?

сделать процесс сборки проще для всех

Многие электронные приложения используют собственные модули, которые в большинстве случаев должны быть построены на основе конкретной версии используемого электронного устройства. Как бы вы решили эту проблему?

Не стесняйтесь создавать глобальную версию electronic, которую могут использовать разработчики, но я думаю, вы обнаружите, что вряд ли кто-то будет использовать ее по указанным выше причинам!

@timfish
there are so many reasons having a global install of electron will never happen.
Это похоже на одно из следующих: https://www.pcworld.com/article/155984/worst_tech_predictions.html

Поскольку исполняемые файлы Node / v8 или электронных файлов не так уж велики, глобальный ERE может при необходимости загрузить недостающие компоненты для однократного использования. Также для этих глобальных ERE может быть реализована некоторая групповая логика, например Node.js 9.x вместо отдельных Node.js 9.0, 9.1 и т. Д.

Я не знаю, но я не думаю, что такое отношение к делу ... «О, это невозможно. О, это невозможно. В этом нет никакого смысла». Вместо этого должно быть: «Как мы можем решить эту проблему / обойти эту проблему?»

@timfish, это печальные новости ... Мне лично не важен файл размером 40 МБ, но 120 МБ (как я слышал), тем не менее, слишком много для привет, мир.

Во-первых, из всех существующих в мире производственных электронных приложений существует около 20+ различных версий электронных приложений. Какую версию вы бы выбрали глобально?

Как я уже сказал, потребуется обратная совместимость.

разработчикам нужен доступ к последним функциям Chrome

Отсюда прогрессивное улучшение ... Верно? В любом случае даже прогрессивное улучшение не является обязательным, если приложению может потребоваться определенная версия ERE, которая вызовет обновление глобального ERE.

Как бы вы решили эту проблему?

Если кому-то нужны специально скомпилированные модули, они могут встраивать свою собственную версию модулей (которая в любом случае не будет доступна внутри ERE) и указать минимальную версию ERE. Если ERE обновляется до более новой версии, я предполагаю, что есть 2 очевидных решения: либо они обновляют свои модули (так же, как и зависимости в Node сегодня), либо мы могли бы также разрешить несколько глобальных версий ERE (так же, как JRE). Думаю, это не проблема.

электрон имеет быстрый цикл выпуска

Здесь, без сомнения, это здорово. Но, возможно, люди смогут выжить с ежемесячным выпуском, следовательно, ограничив количество версий ERE.

Не стесняйтесь создавать глобальную версию

Да ... Не буду этого делать. У меня нет навыков, но я бы стал, если бы имел.

Я могу просто предлагать предложения, которые считаю актуальными, и позволять экспертам делать свою работу: либо они говорят мне, что я идиот со своими предложениями (что вполне может быть так), либо они считают, что это может привести к чему-то хорошему. . Что бы ни :)

Я по-прежнему считаю, что глобальный ERE был бы лучшим решением, даже если это означает наличие нескольких ERE для различных нужд различных приложений. Но, опять же, это просто идея, которую я пришла из сравнения с JRE.

@RenaudParis

Это печальные новости ... Мне лично не важен файл размером 40 МБ, но 120 МБ (как я слышал), тем не менее, многовато для приветственного мира.

120 МБ в несжатом виде, если сжать, получается около 40 МБ. Например, размер EXE для 64-разрядной версии VSCode для Windows составляет около 42,8 МБ.

Лично я, как пользователь, всегда предпочитаю иметь автономное приложение без необходимости управлять глобальной JRE (или ERE), даже если мне придется загрузить 200 МБ вместо 10 МБ.

Это не просто 120 МБ, я создал простое веб-приложение, которое было ~ 1 МБ на веб-сервере, но ~ 300 МБ как приложение Electron на OS X

Кроме того, это становится более важным, когда на одном компьютере работает много приложений Electron.
Тогда будет в 10, 20 раз больше.
Сейчас на компьютере есть несколько стандартных приложений, созданных с помощью Electron, таких как Slack, VSCode и т. Д. И есть еще более крупные проекты, такие как NodeOS.

Node.js имеет> 500 тыс. Модулей. Если бы Electron стал лучше, быстрее, популярнее и меньше, на рабочем столе было бы гораздо больше приложений с гигабайтами ненужных файлов Electron.

Электрон просто не лучший фреймворк.

Я бы предпочел разделить ненужные части фреймворка Chrome, такие как Flash и т. Д.

@yasinaydin

1 МБ на веб-сервере, но ~ 300 МБ в качестве приложения Electron на OS X

Вам необходимо очистить ваше приложение перед распространением (подсказка: проверьте свои node_modules). Например, VSCode в Windows после установки занимает 228 МБ (размер загружаемой установки составляет всего 42,8 МБ).

Но размер установки - это только одна проблема. Другая проблема заключается в том, сколько ОЗУ использует приложение и время запуска. По моему опыту, после запуска приложения скорость приложения не является проблемой.

Electron не подходит для небольших приложений, но для больших приложений, таких как VSCode, он работает.

Другая проблема заключается в том, сколько ОЗУ использует приложение и время запуска.

@mvladic тебе не кажется, что это еще две проблемы, которые исправит ERE? Уже загружены и поделены между приложениями, и все.

Хорошо, может быть, у людей не работает одновременно 10 приложений Electron ... Но, может быть, они будут! Важна максимально возможная факторизация зависимостей.

Я понимаю, что Electron сначала был запущен как POC, а затем потребовались очень частые выпуски, чтобы угодить разработчикам. Но, возможно, теперь, когда Electron стал более зрелым, необходимо принять некоторые меры для обеспечения наилучшего возможного {время загрузки, использование оперативной памяти, размер загрузки}.

Опять же, я просто предлагаю (возможно, наивное, я не знаю) решение проблем, о которых пользователи Electron, кажется, разглагольствуют с самого начала. Но что касается меня, я действительно не возражаю против текущего состояния Electron для моих небольших нужд. Electron великолепен, я просто думаю о том, как сделать его еще лучше.

Электрон просто не лучший фреймворк.

@ fab1an , зависит от того, что нужно людям. Для меня это идеально подходит для моих нужд, потому что я не уверен, что PWA достаточно зрелые. Но опять же, может быть, для других лучше подошел бы Qt, в этом вы правы.

Среда выполнения была предложена и обсуждена ранее и до сих пор остается открытым обсуждением . Но это одна из тех вещей, которые легче сказать, чем сделать. Как видите, не всем удавалось попасть на одну и ту же страницу или понять, как правильно начать работу, чтобы она надежно работала в производственной среде. Если вы думаете, что можете внести свой вклад в обсуждение или помочь в его начале, я не думаю, что кто-то будет возражать против дополнительной помощи.

Многие разработчики, включая меня, очень довольны тем, что выложили 40-мегабайтную загрузку и обновили ее с помощью небольших дельта-обновлений. Сегодня у людей нет проблем с загрузкой программы на 40 мегабайт. И даже небольшие программы, содержащие пару мегафайлов, могут загрузить и установить 40 мегабайт - 2 гига, и, похоже, ни у кого нет проблем. с этим. Даже если бы была доступна опция времени выполнения, скорее всего, у пользователя ее не будет, и ему все равно придется загрузить 40+ мегабайт для запуска вашего проекта.

Если это предостережение не ваша чашка чая, при необходимости попробуйте другой вариант. Я не имею в виду это прямо, иногда вам нужно исключить технологии, чтобы достичь цели и условий, которым вы хотите соответствовать. Но это не делает Electron плохой технологией и не делает ее непригодной для многих других. Электрон не предназначен для решения всех задач. И этого реально никогда не будет.

@baconbrad, если ваш комментарий нацелен на меня, я не понимаю почему, поскольку я несколько раз прямо сказал, что я и так очень доволен, и что Electron был именно той технологией, которая подходила для моих (конкретных) потребностей.

Я только сказал, что я видел, как много людей повсюду жаловались на размер пакета, и я просто предлагал (опять же наивное) решение этой проблемы, которое мне показалось идеальным. Но я вполне могу ошибаться и в любом случае это абсолютно не помешает мне использовать Electron для своих будущих нужд :)

Даже если бы была доступна опция времени выполнения, скорее всего, у пользователя ее не будет, и ему все равно придется загрузить 40+ мегабайт для запуска вашего проекта.

Да, но я знаю множество людей, даже здесь, в центре Парижа, у которых подключение к Интернету только 5 Мбит / с, и для этих людей экономия 40 МБ (т.е. 320 МБ) для каждого приложения означает экономию пары минут при каждом обновлении приложения (не забудьте, что 40 МБ будут приходиться на каждое обновление, а не только на первую установку), учитывая, что их подключение к Интернету не используется.

Это даже без учета экономии оперативной памяти, особенно для ноутбуков. Опять же, я не чувствую себя лично обеспокоенным, поскольку у меня относительно хорошая машина с 32 ГБ ОЗУ, но я думаю здесь не о себе, а о людях, которые жалуются и надеются найти для них решение.

И последнее, но не менее важное: у вас может быть хорошее соединение, и я тоже (молниеносный, если хотите! :)), и у нас обоих может быть 16, 32 или 64 ГБ ОЗУ, поэтому вы (сами) не Я не возражаю загружать 40 МБ для каждого обновления, но как насчет ваших пользователей (учитывая, что вы распространяете свое приложение среди людей)?

В любом случае, я не буду ссориться из-за этого, я всего лишь хотел помочь, и, как я уже сказал, я очень счастлив, и у меня есть много вещей, которыми нужно заняться.

Если некоторые люди думают, что я могу помочь им придумать решение, я буду рад помочь, но в противном случае я вернусь к работе :)

Ваше здоровье,

Одна вещь, которую я заметил при переносе большего количества зависимостей в devDependencies, - тем больше времени требуется на его сборку.

`` ''
✔ построение основного процесса

• построение процесса рендеринга
  `` ''

Он потратил гораздо больше времени на «построение процесса рендеринга», и анимированный значок останавливался, как будто он вылетает, но этого не произошло. Затем он показывает 203778 мсек из отчета о рендерере.

Перемещение devDependencies обратно в зависимости, время сборки снова нормальное, но приложение велико.

Если во время сборки у меня нет ошибок, значит, все в порядке?

@karimhossenbux Для меня это нормально. В electron-packager есть функция

@baconbrad Спасибо! Я использую electron-builder но, думаю, работает так же.

Есть ли какой-либо конструктор электронных пакетов, который включает только ваш исходный код и загружает другие (необходимые только для текущего пользователя операционной системы), когда пользователь запускает ваше приложение в первый раз?. Это упростило бы распространение и значительно уменьшило бы размер вашего приложения.

Электрон, пожалуйста, не выбирай путь "ERE". Да, я знаю, что вы раздуты, но мне нравится, как люди могут загружать мое приложение, и оно просто отлично работает без необходимости возиться с установкой deps, обновлением среды выполнения или любой другой ерундой, от которой, как я думал, мы избавились примерно в 2003 году. .

Что ж, загрузка пакета все равно будет вариантом. Не на что жаловаться
примерно здесь :)

Le ven. 25 мая 2018 г. в 21:03, Люк Пигетти [email protected] а
écrit:

Электрон, пожалуйста, не выбирай путь "ERE". Да, я знаю, что ты раздут,
но мне нравится, как люди могут скачать мое приложение, и оно просто отлично работает
без необходимости возиться с установкой deps, обновляя среду выполнения
окружающей среды, или любой другой ерунды, от которой, как я думал, мы избавились примерно
2003 г.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/electron/electron/issues/2003#issuecomment-392151709 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AApUIBjAeVZ7T4SKo8LyW6RT65XnpiKgks5t2FWfgaJpZM4FGGer
.

Я просто жду, когда инженеры Microsoft улучшат Electron.
https://news.ycombinator.com/item?id=17229973

Я просто жду, когда инженеры Microsoft улучшат Electron.
https://news.ycombinator.com/item?id=17229973

@zcmgyu Microsoft наняла разработчиков для работы над Electron уже несколько лет с тех пор, как они начали использовать его для VS Code. И они являются одними из самых крупных участников и немного улучшили его.

Если ваше приложение превышает 100 МБ,
возможно, ваш exe включает большую часть вашей папки node_modules.
Обратите внимание, что все, что объявлено в package.json в зависимостях, импортируется обратно в окончательный исполняемый файл.
(Очень просто проверить: достаточно декомпилировать исполняемый файл)
Поэтому не забудьте определить только основные библиотеки в зависимостях (электронный журнал, электронное обновление) и добавить все остальные библиотеки в devDependencies.

Тогда ваше приложение будет "только" 50 МБ ...

Моего приложения мало - вот репо. Последняя экспериментальная версия весит около 700 МБ.
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

Мне тоже интересно об этом. Вот размеры моего электронного приложения:

  osx - 117.3 mb

linux32 - 60,3 МБ
linux64 - 55,2 МБ
win ia32 - 47,8 мб
win x64 - 66,2 мб
Спасибо!

Удивительный! Не могли бы вы рассказать о том, как уменьшить электронное приложение до такого маленького размера.