Electron: 예상 앱 번들 크기는?

예상 크기입니다. 더 작게 만들 방법이 없습니다.

정말 그렇게 클 것으로 예상됩니까? 번들로 제공되는 Windows 및 Linux 빌드는 훨씬 더 작으며 Electron Framework 폴더를 살펴보면 Electon Framework 파일의 사본이 각각 하나씩 있습니다.

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

이것들이 심볼릭 링크라고 해야 할까요?

Windows 및 Linux 빌드는 얼마나 작습니까?

저도 이게 궁금합니다. 내 전자 앱의 크기는 다음과 같습니다.

OSX - 117.3MB
 linux32 - 60.3MB
 linux64 - 55.2MB
 승리 ia32 - 47.8MB
 승리 x64 - 66.2MB

감사 해요!

향후 릴리스에서 프레임워크의 크기를 줄이려는 계획이 있습니까? 이것은 작은 앱에 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 모듈도 심볼릭 링크를 존중하지 않았습니다. 생각보다 쉽지 않았다. 문제에 대한 Google 솔루션을 검색하면 실제 설명보다 마술에 가까운 이상한 구현이 포함된 몇 가지 기사를 찾을 수 있습니다. zip 심볼릭 링크를 준수하는 데 필요한 플래그가 있는 CLI 명령.

FWIW, OS X에 배포하기 위해 Linux에서 zip을 만들 때 심볼릭 링크를 올바르게 처리하려면 -y 매개변수를 사용해야 합니다.

$ zip -r -y app.zip app

#SLACK은 무엇을 했는가? 왜 그들의 앱이 그렇게 작습니까?
zip 아카이브 파일은 24.6MB입니다.

Windows 및 Linux 버전은 내가 예상한 것과 거의 비슷합니다. 어떻게 OSX 버전이 그렇게 작은지 궁금합니다.

마지막으로 slack이 Mac 측에서 MacGap 을 사용하고 있는지 확인했습니다.

http://electron.atom.io/#built -on-electron Slack이 목록에 있습니다.

예, Slack의 Windows 및 Linux 앱은 Electron을 기반으로 하지만 Mac 앱은 MacGap을 사용합니다.

@joshaber 나는 당신이 옳다고 생각합니다. Slack mac 앱은 ~36MB에 불과합니다.

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 Framework입니다.

@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 생태계에서 단지 일시적인 것이기 때문에 NPM이 Electron을 염두에 두고 설계될지는 의심스럽습니다.

예, 웹 개발자에게 최상위 전자를 처리하도록 지시하는 것은 거의 불가능합니다. 둘 다 될 수있는 환경에 대해 생각하고 있습니다 ... 현재 나는 사전 배포 된 서버에 전자 앱을 기반으로합니다. 왜냐하면 다른 모든 사람들을 위해 이상적으로 동일한 종속성을 공유 할 수 있기 때문입니다. asar가 실제 사용자 fs가 될 수 있다면, 특히 기본 확장을 사용하여 해결된 크기 및 복사 문제를 고려할 것입니다.

@baconface 당신은 그것에 대해 걱정할 필요가 없습니다. 일반( dependencies prod deps 및 devDependencies dev deps )과 같은 종속성을 설치한 다음 패키징 단계( electron-packager 가 자동으로 수행) 동안 앱 폴더를 복사하기만 하면 됩니다. 임시 디렉토리로 이동하여 실행합니다.

npm prune --production

그러면 NPM 버전에 관계없이 모든 개발 종속성이 파괴되어 가능한 최소 크기가 됩니다.

--production을 사용하는 것보다 40-80% 이상 더 삭제할 수 있습니다.

--production을 사용하는 것보다 40-80% 이상 더 삭제할 수 있습니다.

이 경우 종속성이 잘못 구성되어 있고 모듈을 삭제해야 하는데 prune --production 가 모듈을 삭제하지 않으면 프로덕션 종속성으로 인식되었음을 의미합니다. devDependencies 이동하면 삭제됩니다.

오 죄송합니다, 잊어버렸습니다: readme, license, ...를 삭제하는 파일 마스크를 빌드하고 node-gyp 단독으로 100배 더 생성하는 경우

@xblox 이러한 추가 정보/라이센스가 몇 킬로바이트의 최고 용량과 같다는 것만 상상할 수 있습니다. 멋진 새 트릭은 yarn clean 를 실행하여 이러한 항목을 자동으로 지우는 것입니다.

@MarshallOfSound 특히 기본 모듈을 사용할 때 놀랄 것입니다. 많은 쓰레기가 주위에 흩어져 있습니다. yarn clean 접근 방식이 좋은 방법일 수 있습니다.

@MarshallOfSound 는 모든 페니 가치가 있는 자신의 파일 마스크를 수행합니다. 일부 패키지 안에 무엇이 들어 있는지 항상 놀랍습니다. 그리고 그것은 단지 몇 킬로바이트 이상이지만 실이 깨끗한지 확인하겠습니다. 포인터 주셔서 감사합니다.

@MarshallOfSound, @paulcbetts는 : 함께 연주 후 yarn clean : 그것은 가능 무엇의 약 70 % 청소 언급 한 파일 마스크를

노드 모듈 종속성 없이 Hello World 응용 프로그램을 작성하려는 경우 패키지 프로그램이 여전히 모든 것을 왜곡하는 이유는 무엇입니까? 최첨단 솔루션은 yarn clean 를 사용하는 것입니다.

내 node_modules는 40MB이고 전자는 140MB입니다.

전자 빌더와 이 파일을 사용하여 데스크탑 앱에서 약 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"

단순한 앱의 경우 번들 크기가 132Mb인지 궁금합니다.
번들 크기를 줄이는 방법이 있습니까?

크로스 플랫폼이고 많은 아키텍처를 지원하며 사용하기 쉬운 실행 파일에 UPX 를 사용하도록 제안했지만 불행히도 Electron의 팀은 이에 굴하지 않는 것을 선호하는 것 같습니다.
(이미 이전에 요청: https://github.com/electron/electron/issues/5506)

그렇지 않으면 NW.js 를 UPX(최종 크기가 ~60% 더
크기가 중요하다면 대신 이 제품으로 개발에 집중할 수 있습니까?

electron 및 거의 모든 다른 비-런타임 패키지를 devDependencies 에서 package.json 로 이동하여 압축된 OSX 배포 크기를 52MB로 얻을 수 있었습니다 rm -rf node_modules 그리고 npm install --production .

앱을 패키징할 때 electron-packager 는 프로젝트의 node_modules 에서 electron 종속성이 누락되었다고 불평합니다. electron-packager 다음 플래그를 제공하여 이 문제를 해결할 수 있습니다.

--electron-version=1.7.11

1.7.11 를 원하는 electron-packager 버전으로 대체하십시오.

@eladnava 정보를 제공

이전 메시지를 모두 읽지 않았는지/모르지 않았습니까? 이미 말한 것이 있으면 알려주세요.

Electron 프레임워크 자체를 분리하고 앱만 배송할 수 있나요?

내가 이해하는 한, Electron 앱이 배송되는 방식은 fw가 포함되어 있습니다. JRE가 포함된 Java 앱을 제공하는 것처럼 들립니다.

해당 버전을 사용할 수 있는 모든 앱이 사용하도록 Electron 프레임워크를 OS에 설치할 수 있습니까?

@eladnava 전자가 대상 머신에 설치되어 있지 않으면 앱이 실행되지 않는다는 것을 알고 계셨습니까?

@fab1an : @yasinaydin이 이해하고 있다고 생각합니다. 그는 사용자가 Electron을 사용하는 모든 애플리케이션에 설치할 수 있는 Electron 공통 런타임을 원합니다. 이것은 이미 전자/전자#673에서 논의되고 있으며 현재 해결 방법이 없습니다.

@js-choi @fab1an 어떻게 작동하는지 완전히 확신할 수 없지만 Electron이 패키지 앱에 포함된 Electron Framework.framework 내에서 electron-packager 에 미리 번들로 제공 된다는 느낌이 듭니다 .

따라서 앱의 node_modules 내에서 electron 도 함께 묶을 이유가 없습니다. 또한 내 접근 방식이 작동하기 위해 대상 시스템에 npm electron 패키지를 설치할 필요가 없습니다.

electrino는 그들의 기술을 사용하여 115MB Electron 앱을 167kB로 만들 수 있었습니다. 이 기술은 전자에 통합되어야 한다고 생각합니다. 100MB hello world 앱은 "Hello World"를 표시하는 일반적인 크기가 아닙니다.+1:

@spaceywolfi Electrino는 실제로 Chrome/V8 엔진을 실행하여 앱을 렌더링하는 것이 아니라 OSX의 기본 웹 브라우저 엔진(WebKit)을 사용하기 때문에 특히 Electron 앱을 사용하여 Electrino로 빌드할 수는 없습니다. Electron API는 사용할 수 없기 때문입니다. 적어도 아직은 아니다.

내가 언급한 트릭을 사용하여 기본 바이너리 크기를 ~50MB로 줄이려고 할 수 있습니다.

@eladnava 설명

@eladnava

어떻게 작동하는지 완전히 확신할 수 없지만 Electron이 패키지 앱에 포함된 Electron Framework.framework 내에서 전자 패키지로 미리 번들로 제공된다는 느낌이 듭니다.

따라서 앱의 node_modules 내에서도 전자를 번들로 묶을 이유가 없습니다. 일에 대한 접근.

내 devDependencies electron 및 electron-packager 가 있습니다. 내가 할당 할 수있는이 방법 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 가 최종 바이너리에서 이러한 종속성을 자동으로 제거하지 않아 바이너리 크기가 ~100MB라는 것을 알았습니다. 이 두 패키지를 전역적으로 설치한 후 바이너리 크기는 ~50MB로 떨어졌습니다.

@eladnava 이것은 개발자 종속성이 아니라 종속성으로 사용했기 때문에 발생했을 수 있습니다. 당신이 사용하는 경우 npm install packagename --save-dev 이 당신의 적절한 영역에 저장됩니다 package.json . node_modules 폴더에 표시되지만 패키지되면 제거됩니다.

@baconbrad

이것은 실제로 가능합니다. 그러나 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)" 무시 옵션에 있는지 확인합니다. 이 모든 단계를 수행하면 기본적으로 과도한 종속성 벌크가 제거되거나 소스 파일 또는 빌드 폴더가 잘못 포함됩니다.

@baconbrad

팁 친구를 위해 건배!

안녕하세요 여러분,

모든 사람을 위한 앱 크기를 대폭 줄이려면 모든 사람을 위한 대역폭을 절약하고 모든 사람이 빌드 프로세스를 더 쉽게 만들 수 있도록 하는 등 최적화/사고는 일부 node_modules를 무시하는 것과는 다르게 수행되어야 합니다.

Java 및 Java 앱이 수십 년 동안 성공적으로 사용해 온 것과 동일한 아이디어를 사용하는 것은 어떻습니까? "JRE"(이 경우 "ERE"가 됨)에 대한 종속성이 있어야 합니다.

그렇게 하면 ERE가 필요한 첫 번째 앱의 컴퓨터에 전역적으로 설치되고(ERE를 요구하는 프로세스는 각 플랫폼의 앱 설치 프로그램에 의해 자동화될 수 있음) 모든 새 앱은 이 기존 ERE만 사용하게 됩니다. .

ERE가 작동하려면 자동 업데이트 기능과 이전 버전과의 호환성(bcb 없음!)이 필요하지만 이것이 사소한 일이라고 확신합니다.

그러면 모든 Electron 앱의 가중치는 몇 MB에 불과합니다. 사용자의 시간을 절약합니다. 개발자의 시간과 대역폭을 절약하고 복잡성을 구축합니다.

이전에 제안된 적이 있습니까? 그렇다면 어떨까요? 저는 이것이 유일하고 최선의 방법이라고 생각합니다.

@RenaudParis 이전에 제안했고 몇 개 더 있을 수도 있지만 지금까지 진지한 작업은 들어본 적이 없습니다.

@yasinaydin 나도 그 정도 생각했는데, 사람들이 예전에 그런 생각을 했을

그럼 개발팀의 의견이 있습니까? @zcbenz 이것은 많은 사람들을 행복하게 만들고 Electron의 미래 경쟁력을 크게

JRE는 여기에서 따라야 할 좋은 예가 아닙니까?

@RenaudParis 와 @yasinaydin , 전자의 글로벌 설치가 일어나지 않는 데에는 많은 이유가 있습니다.

첫째, 야생에 있는 모든 생산 전자 앱 중에서 20개 이상의 다른 버전의 전자가 사용 중일 수 있습니다. 전 세계적으로 어떤 버전을 선택하시겠습니까? 전자는 릴리스 주기가 빠르고 개발자는 최신 Chrome 기능에 액세스하기를 원하기 때문에 이렇게 단편화되어 있습니다.

우리 앱은 전자의 단일 버전으로만 테스트되었으며 40MB 다운로드를 위해 테스트되지 않은 다른 임의 버전에서 실행할 수 있도록 허용하는 위험과 지원 비용을 감수해야 하는 이유는 무엇입니까?

모든 사람이 빌드 프로세스를 더 쉽게 만들 수 있습니다.

많은 전자 앱은 대부분의 경우 사용 중인 특정 전자 버전에 대해 빌드해야 하는 기본 모듈을 사용합니다. 이 문제를 어떻게 해결하시겠습니까?

개발자가 사용할 수 있는 전자의 글로벌 버전을 자유롭게 만들 수 있지만 위의 이유로 거의 아무도 사용하지 않을 것이라고 생각합니다!

@팀피쉬
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는 필요한 경우 한 번 사용하기 위해 누락된 구성 요소를 다운로드할 수 있습니다. 또한 별도의 Node.js 9.0, 9.1 등 대신 Node.js 9.x와 같은 전역 ERE에 대해 일부 번들 논리를 구현할 수 있습니다.

잘은 모르지만 하는 자세는 아닌 것 같은데... "아, 안 돼. 아, 불가능해. 말이 안 돼." 대신 "이 x를 어떻게 달성/해결할 수 있습니까?"여야 합니다.

@timfish 이것은 안타까운 소식입니다... 저는 개인적으로 40MB 파일에 대해 별로 신경 쓰지 않지만(내가 들은 대로) 120MB는 hello world에는 너무 많습니다.

첫째, 야생에 있는 모든 생산 전자 앱 중에서 20개 이상의 다른 버전의 전자가 사용 중일 수 있습니다. 전 세계적으로 어떤 버전을 선택하시겠습니까?

내가 말했듯이, 이전 버전과의 호환성이 필요할 것입니다.

개발자는 최신 Chrome 기능에 대한 액세스를 원합니다.

따라서 점진적인 향상 ... 맞습니까? 어떤 경우든 앱이 특정 버전의 ERE를 요구할 수 있는 경우 점진적 개선도 필수는 아니며, 이로 인해 글로벌 ERE의 업데이트가 트리거됩니다.

이 문제를 어떻게 해결하시겠습니까?

어떤 사람들은 특별히 컴파일된 모듈이 필요한 경우 모듈의 사용자 정의 버전(어쨌든 ERE 내부에서 사용할 수 없는 경우)을 자유롭게 포함하고 ERE의 최소 버전을 지정할 수 있습니다. ERE가 최신 버전으로 업데이트되면 두 가지 확실한 솔루션이 있는 것 같습니다. 즉, 모듈을 업데이트하거나(현재 Node의 종속성과 동일) ERE의 여러 글로벌 버전 (JRE와 동일)을 허용할 수도 있습니다. 이것은 문제가 되지 않는다고 생각합니다.

전자는 방출 주기가 빠름

이것은 의심의 여지없이 훌륭합니다. 그러나 사람들은 월간 릴리스로 생존할 수 있으므로 ERE 버전의 양이 제한됩니다.

글로벌 버전을 자유롭게 만드십시오.

그래... 그렇게 하지 않을거야. 저는 능력이 없지만 있으면 하고 싶습니다.

나는 관련이 있다고 생각하는 제안을 제안할 수 있고 전문가가 자신의 일을 하도록 할 수 있습니다. 그들은 내가 제안하는 것이 바보 같다고 말하거나(그럴 수 있음) 그것이 좋은 결과로 이어질 수 있다고 생각합니다. . 무엇이든 :)

나는 여전히 글로벌 ERE가 최고의 솔루션이 될 것이라고 생각합니다. 비록 그것이 다른 앱의 다양한 요구에 대해 여러 ERE를 갖는 것을 의미하더라도 말입니다. 그러나 다시 말하지만 이것은 JRE와 비교하면서 얻은 아이디어일 뿐입니다.

@RenaudParis

이것은 슬픈 소식입니다... 저는 개인적으로 40MB 파일에 대해 별로 신경 쓰지 않지만 120MB(내가 들은 대로) 그러나 hello world에는 너무 많습니다.

120MB는 비압축, 압축하면 40MB 정도입니다. 예를 들어 Windows 설치 EXE용 VSCode 64비트는 약 42.8MB입니다.

개인적으로 사용자로서 10MB 대신 200MB를 다운로드해야 하는 경우에도 글로벌 JRE(또는 ERE)를 관리할 필요 없이 항상 자체 포함된 응용 프로그램을 사용하고 싶습니다.

120mb가 아니라 웹 서버에서 ~1mb, OS X에서 Electron 앱으로 ~300mb인 간단한 웹 애플리케이션을 만들었습니다.

또한 동일한 컴퓨터에서 실행 중인 Electron 앱이 많을 때 이는 더욱 중요해집니다.
그러면 10배, 20배가 됩니다.
이제 Slack, VSCode 등과 같은 Electron으로 구축된 컴퓨터에 여러 표준 앱이 있습니다. 그리고 NodeOS와 같은 더 큰 프로젝트도 있습니다.

Node.js에는 500,000개 이상의 모듈이 있습니다. Electron이 더 좋아지고 더 빨라지고 대중화되고 더 작아지면 데스크톱에는 GB의 불필요한 Electron 파일이 있는 더 많은 앱이 있을 것입니다.

Electron은 최고의 프레임워크가 아닙니다.

Flash 등과 같은 Chrome 프레임워크의 불필요한 부분을 분리하는 것이 좋습니다.

@yasinaydin

웹 서버에서 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은 훌륭합니다. 저는 더 나은 방법을 생각하고 있습니다.

Electron은 최고의 프레임워크가 아닙니다.

@fab1an , 사람들이 필요로 하는 것에 달려 있습니다. 저에게는 PWA가 충분히 성숙하지 않았기 때문에 제 요구에 완벽하게 맞습니다. 그러나 다시 다른 사람들에게는 Qt가 더 적합할 수 있습니다. 당신이 옳습니다.

런타임은 이전에 제안 및 논의되었으며 여전히 공개 토론 입니다. 그러나 이것은 말보다 쉬운 일 중 하나입니다. 보시다시피 모든 사람이 동일한 페이지에 도달하거나 프로덕션 환경에서 안정적으로 작동할 수 있도록 제대로 시작하는 방법을 알아낼 수 있는 것은 아닙니다. 토론에 기여할 수 있거나 토론을 시작하는 데 도움이 될 수 있다고 생각한다면 아무도 추가 도움을 꺼릴 것이라고 생각하지 않습니다.

저를 포함한 많은 개발자들이 40메가 다운로드를 제공하고 더 작은 델타 업데이트를 사용하여 업데이트하는 데 매우 만족하고 있습니다. 오늘날 사람들은 40메가 프로그램을 다운로드하는 데 아무런 문제가 없습니다. 그리고 몇 메가 파일인 작은 프로그램도 40 메가를 다운로드하여 설치할 수 있습니다. 그것으로. 런타임 옵션을 사용할 수 있는 경우에도 사용자에게 옵션이 없을 수 있으며 어쨌든 프로젝트를 실행하려면 40개 이상의 메가를 다운로드해야 합니다.

이 경고가 차가 아닌 경우 필요한 경우 다른 옵션을 살펴보십시오. 뻔뻔하게 말해서, 때로는 당신이 달성하고자 하는 목표와 조건을 충족시키기 위해 기술을 제거해야 한다는 뜻이 아닙니다. 그러나 이것이 Electron을 나쁜 기술로 만들거나 다른 많은 사람들이 사용할 수 없게 만드는 것은 아닙니다. 전자가 모든 솔루션을 해결하는 것은 아닙니다. 그리고 실제로는 절대 그렇지 않을 것입니다.

@baconbrad 귀하의 의견이 저를 대상으로 하는 것이라면 저는 그 자체로 꽤 만족 맞는 기술 이었다고 여러 번 명시적으로 말했듯이 왜 그런지 이해가 되지 않습니다.

나는 많은 사람들이 패키지 크기에 대해 도처에서 불평하는 것을 보았고 나는 그 문제에 대한 (다시 순진한) 해결책을 제공했을 뿐이라고 말했습니다. 그것은 나에게 이상적이라고 보였습니다. 그러나 나는 매우 잘 착각할 수 있으며 어떤 경우에도 내 미래의 필요를 위해 Electron을 사용하는 것을 절대적으로 방해하지 않을 것입니다 :)

런타임 옵션을 사용할 수 있는 경우에도 사용자에게 옵션이 없을 수 있으며 어쨌든 프로젝트를 실행하려면 40개 이상의 메가를 다운로드해야 합니다.

네, 하지만 여기 파리 중심부에서도 인터넷 연결이 5Mbps밖에 안되는 사람들을 많이 알고 있습니다. 그런 사람들에게 각 앱에 대해 40MB(즉, 320Mb)를 절약한다는 것은 앱이 업데이트될 때마다 몇 분을 절약하는 것을 의미합니다. 인터넷 연결이 사용되지 않는다는 점을 감안할 때 첫 번째 설치뿐만 아니라 각 업데이트에

특히 노트북의 경우 RAM 절약을 고려하지도 않습니다. 다시 말하지만, 나는 32GB RAM을 가진 비교적 좋은 기계를 가지고 있기 때문에 개인적으로 걱정하지 않습니다. 그러나 나는 여기서 나 자신에 대해 생각하지 않고 오히려 불평하고 그들을 위한 해결책을 찾기를 바라는 사람들에 대해 생각하고 있습니다.

마지막으로 중요한 것은 연결 상태가 양호할 수 있고 저도 마찬가지이며(원한다면 번개처럼 빠른 것입니다! :)) 우리 둘 다 RAM이 16GB 또는 32GB 또는 64GB일 수 있습니다. 각 업데이트에 대해 40MB를 다운로드해도 상관없지만 사용자는 어떻습니까(앱을 사람들에게 배포하는 경우)?

어쨌든, 나는 이것에 대해 싸우지 않을 것입니다, 나는 단지 도움을 구하고 있었고, 말했듯이 나는 그 자체로 매우 행복하고 신경 써야 할 일이 많습니다.

어떤 사람들이 내가 해결책을 생각하는 데 도움을 줄 수 있다고 생각한다면 기꺼이 도움을 드리고 싶지만 그렇지 않으면 다시 일할 것입니다. :)

건배,

더 많은 종속성을 devDependencies로 이동할 때 본 한 가지는 빌드하는 데 더 많은 시간이 필요합니다.

````
✔ 주요 프로세스 구축

• 건물 렌더러 프로세스
  ````

"렌더러 프로세스 구축"에 더 많은 시간을 할애했으며 애니메이션 아이콘이 충돌하는 것처럼 중지되지만 충돌은 발생하지 않았습니다. 그런 다음 렌더러 보고서에서 203778ms를 표시합니다.

devDependencies를 종속성으로 다시 이동하면 빌드 시간이 다시 정상이지만 앱이 큽니다.

빌드하는 동안 오류가 발생하지 않으면 문제가 없는 것입니다.

@karimhossenbux 이것은 저에게 정상입니다. electron-packager 에는 모든 종속성을 살펴보고 있어야 하는지 여부를 결정하는 걷기 기능이 있습니다. 중첩 대신 새로운 플랫 스타일 종속성을 사용하면 불필요한 종속성을 결정하는 데 훨씬 더 오래 걸립니다. 내가 아는 한 추가 빌드 시간을 피할 방법이 없습니다.

@baconbrad 감사합니다! 나는 electron-builder 있지만 같은 방식으로 작동한다고 생각합니다.

사용자가 앱을 처음 실행할 때 소스만 포함하고 다른 것은 다운로드(현재 운영 체제 사용자가 실행하는 경우에만 필요)만 포함하는 전자 패키지 빌더가 있습니까? 배포하기 쉽게 만들고 앱 크기를 상당히 줄여야 합니다.

전자여, "ERE" 경로로 가지 마세요. 예, 당신이 부풀려진 것을 압니다. 하지만 사람들이 내 애플리케이션을 다운로드할 수 있는 방법이 마음에 듭니다. deps 설치, 런타임 환경 업데이트 또는 2003년경에 제거했다고 생각했던 말도 안되는 일을 하지 않고도 훌륭하게 실행됩니다. .

글쎄, 번들을 다운로드하는 것은 여전히 ​​옵션이 될 것입니다. 불평할 것이 없다
여기에 대해 :)

르 벤. 2018년 5월 25일 à 21:03, Luke Pighetti [email protected] a
에크리트 :

전자여, "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 Microsoft는 VS Code용으로 Electron을 사용하기 시작한 이후 몇 년 동안 개발자를 고용하여 Electron에서 작업했습니다. 그리고 그들은 가장 큰 기여자 중 일부이며 이를 상당히 개선했습니다.

애플리케이션이 100MB를 초과하는 경우,
exe에 node_modules 폴더의 상당 부분이 포함되어 있을 수 있습니다.
종속성에서 package.json에 선언된 모든 것은 최종 실행 파일로 다시 가져옵니다.
(확인이 매우 간단합니다. 실행 파일을 디컴파일하는 것으로 충분합니다)
따라서 종속성(electron-log, electron-updater)에 필수 라이브러리만 정의하고 devDependencies에 다른 모든 라이브러리를 추가하는 것을 잊지 마십시오.

그러면 앱은 50MB를 "만" ...

내 앱은 작습니다. 여기 저장소가 있습니다. 최신 실험 버전의 무게는 약 700MB입니다.
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

저도 이게 궁금합니다. 내 전자 앱의 크기는 다음과 같습니다.

  osx - 117.3 mb

linux32 - 60.3MB
linux64 - 55.2MB
승리 ia32 - 47.8MB
승리 x64 - 66.2MB
감사 해요!

놀라운! 전자 앱을 너무 작은 크기로 줄이는 방법에 대해 공유할 수 있습니까?