Electron: حجم حزمة التطبيق المتوقع؟

هذا هو الحجم المتوقع ، ولا توجد طريقة لجعله أصغر.

هل من المتوقع حقًا أن تكون بهذا الحجم؟ تعد إصدارات windows و linux المجمعة أصغر بكثير ، وبالنظر إلى مجلد Electron Framework ، هناك ثلاث نسخ من ملف Electon Framework ، واحدة على كل منها:

المحتويات ، الأطر ، الإطار الإلكتروني
المحتويات ، الأطر ، الإطار الإلكتروني ، الإطارات ، الإصدارات أ
المحتويات ، الأطر ، الإطار الإلكتروني ، الإطارات ، الإصدارات الحالية

هل من المفترض أن تكون هذه روابط رمزية؟

ما مدى صغر حجم بنى Windows و Linux؟

أنا أيضا أتساءل عن هذا. فيما يلي أحجام تطبيق الإلكترون الخاص بي:

OSX - 117.3 ميغابايت
 لينكس 32 - 60.3 ميجا بايت
 لينوكس 64 - 55.2 ميغا بايت
 فوز ia32 - 47.8 ميغابايت
 win x64 - 66.2 ميجا بايت

شكرا!

هل هناك خطة لمحاولة تقليل حجم الإطار في الإصدارات المستقبلية؟ هذا يجعل من الصعب تبرير استخدام Electron للتطبيقات الصغيرة (حيث يتضاءل حجم التطبيق نفسه مقابل حجم Electron).

يمكنني أن أؤكد أن حزم تطبيقات الإلكترون الخاصة بي بنفس حجمdavefedele.

يمكنك ضغط تطبيقك وإذا كنت تستخدم electron-packager يمكنك تجاهل بعض وحدات العقد التي لا تحتاجها عند تشغيل التطبيق ، وهذا يجعله أصغر قليلاً. على سبيل المثال ، لديّ تطبيق إلكتروني مضغوط بسعة 37 ميغابايت (لاحظ أن إصدار Windows أكبر بكثير لأنه يحتوي على نسخة من Git).

لكن ستحتوي Electron دائمًا على جزء كبير من Chrome فيه ، لذا لا يوجد سوى الكثير الذي يمكن القيام به. يبلغ حجم الإلكترون نفسه الآن 33 ميغا بايت.

يتشابه حجم 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 ، فستجد بعض المقالات ذات التطبيقات الفردية التي كانت أقرب إلى السحر من التفسير الحقيقي ، لذلك بعد فترة من الوقت حاولت دون جدوى تشغيله ، انتهى بي الأمر إلى تشغيل عملية فرعية تنفذ نظام التشغيل x zip CLI مع الإشارات المطلوبة لاحترام ارتباطات الرموز.

FWIW ، عند إنشاء ملف مضغوط على Linux للتوزيع على OS X ، سيتعين عليك استخدام المعلمة -y للتعامل مع الارتباطات الرمزية بشكل صحيح:

$ zip -r -y app.zip app

ما الذي فعله #SLACK؟ لماذا تطبيقهم صغير جدًا؟
حجم ملف أرشيف مضغوط 24.6 ميغابايت.

تعد إصدارات Windows و Linux أكثر أو أقل مما كنت أتوقعه ، وأتساءل كيف حصلت على إصدار OSX صغير جدًا.

آخر مرة راجعت فيها Slack كانت تستخدم

http://electron.atom.io/#built -on-electron Slack موجود في القائمة.

نعم ، إن تطبيقات Slack's Windows و Linux مبنية على Electron ، لكن تطبيق Mac يستخدم MacGap.

@ joshaber أعتقد أنك على صواب. يبلغ حجم تطبيق Slack mac 36 ميغا بايت فقط.

هل تعلمون ما إذا كان لدى Electron أي خطة لتقليل حجم الحزمة النهائي؟ سيكون ذلك أمرًا لا يُصدق.

هل تعلمون ما إذا كان لدى Electron أي خطة لتقليل حجم الحزمة النهائي؟ سيكون ذلك أمرًا لا يُصدق.

لا يوجد سوى الكثير الذي يمكنك إزالته من Chromium و Node.js و V8 وما إلى ذلك ولا يزال لديك منتج فعال. لسوء الحظ ، نظرًا لأن كل شيء يتم تصحيحه من أجل العمل ، فإنه ليس سهلاً مثل جعله يستخدم إصدارات مستقلة لكل منها لتقليل الحجم. أنا متأكد من أن فريق Electron سيرغب في حجم أصغر. لكن لا يمكنك التخطيط وتحقيق ذلك. إنه أمر لاذع للغاية في المشروع ككل أن تفكر في أنه يمكنك إزالة حتى 10-20 ميغا من الأكواد والموارد وتتوقع أن يعمل كل شيء بشكل مستقر.

صحيح جدًاbaconface ... ساعدني شيء واحد على الرغم من ذلك: لقد كنت أضع وحدات مثل الإلكترون المُنشأ مسبقًا ، ومنشئ الإلكترون ، والرازم الإلكتروني وجميع تبعياتها في مجلد "التطبيق". أدى قطعها من package.json للتطبيق والبناء مرة أخرى إلى توفير الكثير من الحجم لي. لقد استخدمت بنية الحزمتين json من منشئ الإلكترون.

leonelcbraz لا تتردد في الاقتراض أو الحصول على أفكار من تجاهل regex الخاص بي مقابل 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 beta لعميل Mac. كان حجم نظام Mac القديم (باستخدام MacGap) 36 ميغا بايت على القرص. ثنائي Mac الجديد (باستخدام Electron) هو 175 ميغا بايت. 124 ميغا بايت من ذلك هو إطار عمل الإلكترون.

تضمين التغريدة تحتاج إلى فعل شيء مع حجم التطبيق.

متفق.

ساعد استخدام

pierreraii سعيد لأنه ساعد. ملاحظة مهمة هي أن NPM3 يغير طريقة عمل دليل node_module . نتيجة لذلك ، قد لا تعمل هذه الحيلة وفقًا لتوقعاتك. يمكنك الرجوع إلى إصدار أقدم من NPM إلى الإصدار 2 باستخدام npm i npm<strong i="7">@2</strong> -g بالرغم من ذلك.

في المستقبل ، يستخدم حلنا الخاص بمشروعنا في العمل NPM3 ولكن نضع كل شيء لا نريد شحنه على أنه تبعية للتطوير. نقوم بتثبيت أدوات بناء Electron الخاصة بنا عالميًا على عكس مستوى المشروع. ثم قم بتثبيت الوحدات المطلوبة فقط باستخدام npm install --only=production . ومع ذلك ، هذا ليس مثاليًا للمشاريع مفتوحة المصدر ولكنه يعمل مع مكتبنا. من المؤسف أن يكون لدينا إعداد غريب مثل هذا ولكن من المشكوك فيه أن NPM سيتم تصميمه مع وضع Electron في الاعتبار لأنه مجرد صورة في نظام NPM البيئي.

نعم ، إخبار مطوري الويب بالتعامل مع الإلكترون في المقدمة يكاد يكون مستحيلًا. مجرد التفكير في بيئة يمكن أن تكون على حد سواء ... حاليًا أقوم بتطبيقات الإلكترون الخاصة بي على خوادم تم نشرها مسبقًا ، حيث يمكنهم قبل ذلك ولجميع الآخرين ، مشاركة نفس التبعيات بشكل مثالي. إذا كان يمكن أن يكون asar مستخدمًا حقيقيًا ، فسأفكر في حل مشاكل الحجم والنسخ ، خاصةً مع الامتدادات الأصلية

baconface لا داعي للقلق بشأن أي من ذلك. ما عليك سوى تثبيت تبعياتك مثل العادي (توزيعات الإنتاج في dependencies و devs في devDependencies ) ثم أثناء مرحلة التجميع ( electron-packager يقوم بذلك نيابة عنك) ببساطة انسخ مجلد التطبيق الخاص بك إلى دليل مؤقت وتشغيل.

npm prune --production

سيؤدي ذلك إلى تدمير جميع تبعيات dev بغض النظر عن إصدار NPM الذي ينتج عنه الحد الأدنى للحجم الممكن.

يمكنك حذف 40-80 +٪ أخرى أكثر من مجرد - الإنتاج

يمكنك حذف 40-80 +٪ أخرى أكثر من مجرد - الإنتاج

إذا كانت هذه هي الحالة ، فقد تم تكوين تبعياتك بشكل غير صحيح ، إذا كنت بحاجة إلى حذف وحدة و prune --production لا تحذفها ، فهذا يعني أنه قد تم التعرف عليها على أنها تبعية إنتاج. سيؤدي نقله إلى devDependencies إلى حذفه.

آسف ، نسيت أن أقول: إذا قمت ببناء قناع ملف يحذف الملف التمهيدي ، والترخيص ، ... وتنتج node-gyp وحدها 100 ضعف أكثر

xblox يمكنني فقط تخيل تلك القراءات / التراخيص ، وكونها مثل بضعة كيلوبايت ، فإن الحيلة الجديدة الرائعة هي تشغيل yarn clean الذي يمسح هذه الأشياء تلقائيًا نيابة عنك.

MarshallOfSound ستندهش ، خاصة عند استخدام الوحدات الأصلية. الكثير من القمامة ملقاة حولها. قد يكون أسلوب yarn clean أسلوبًا جيدًا

MarshallOfSound تقوم بعمل قناع ملف خاص بك يستحق كل بنس ، من المفاجئ دائمًا ما يوجد داخل بعض الحزم. وهي أكثر من مجرد بضعة كيلوبايت ، لكنني سأتحقق من نظافة الخيوط. شكرا على المؤشر.

MarshallOfSound ، paulcbetts : بعد اللعب بـ yarn clean : ينظف فقط حوالي 70٪ مما هو ممكن باستخدام قناع الملف المذكور

إذا كنا نريد فقط كتابة تطبيق hello world بدون أي تبعيات للوحدة النمطية للعقدة ، فلماذا لا يزال الرابط يشوه كل شيء؟ الحل الأكثر حداثة هو استخدام yarn clean ، أليس كذلك؟

وحداتي node_modules هي 40 ميغا بايت والإلكترون 140 ميغا بايت

باستخدام منشئ الإلكترون وهذه الملفات 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 كن حذرًا عند شحن تطبيقك إذا كنت تستخدم libs مفتوحة المصدر ، فهناك احتمال أن تتطلب المكتبات التي تستخدمها أن يتم شحن ملف الترخيص مع جميع التطبيقات وأنت تقوم بإزالتها جميعًا بشكل أعمى.

OmgImAlexis في الواقع أنت محق في أنني يجب أن احتفظ بملفات الترخيص. شكرا!

فقط تنبيه. electron-packager ذكي بما يكفي لإزالة التبعيات المدرجة في devDependencies . لذلك قمت بنقل معظم حزمتي إلى ذلك وقمت بتجميع البرامج النصية التي أستخدمها في ملف JS واحد باستخدام Grunt. لذا يبدو الآن التعبير المعتاد الخاص بي للتجاهل شيئًا مثل "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|build.js)" . يعطيني نفس النتائج ولكنه أسهل بكثير ولا يتعين علي إضافة مسارات التبعية يدويًا إلى regex الخاص بي. حتى أنه يعمل مع الطريقة التي يخزن بها Yarn التبعيات.

لقد قمت مؤخرًا باستنساخ مثال المشروع لغرض التعلم من https://github.com/electron/simple-samples.git. لقد قمت بإنشاء تطبيق win32 x64 لمراقبة النشاط الموجود داخل المجلد المستنسخ بواسطة الأمر التالي:
حزمة الإلكترون C: userlearningnodeclonedAppsimple-sampleactivity-monitor cpu --platform = win32 --arch = x64 --ignore = "node_modules"

تساءلت أن حجم الحزمة هو 132 ميجا بايت لتطبيق بسيط فقط.
هل توجد طريقة لتقليل حجم الباقة؟

كنت سأقترح استخدام
(طلبت مسبقًا: https://github.com/electron/electron/issues/5506)

بخلاف ذلك ، نجح الاختبار الذي NW.js باستخدام UPX (أقل بنسبة 60٪ في الحجم النهائي) على الرغم من أنني لم أحاول ما إذا كان لا يزال يعمل مع أحدث إصدار ...
لذا ، إذا كان الحجم مهمًا ، فربما يمكنك التركيز على التطوير باستخدام هذا بدلاً من ذلك؟

تمكنت من الحصول على حجم توزيع 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 نفسه وشحن التطبيقات فقط؟

بقدر ما أفهم ، يتم تضمين طريقة شحن تطبيقات الإلكترون مهاجم. يبدو أنه يشحن تطبيق Java مع تضمين JRE فيه.

هل من الممكن تثبيت إطار عمل Electron على نظام التشغيل بحيث يتم استخدام جميع التطبيقات التي يمكنها استخدام هذا الإصدار؟

eladnava هل تدرك أن تطبيقك لن يعمل إذا لم يتم تثبيت الإلكترون على الجهاز المستهدف؟

@ fab1an : أعتقد أن yasinaydin يفهم ذلك. إنه يريد وقت تشغيل مشترك للإلكترون يمكن للمستخدمين تثبيته لجميع تطبيقاتهم التي تستخدم الإلكترون. تتم مناقشة هذا بالفعل في الإلكترون / الإلكترون # 673 ، حاليًا بدون حل.

@ js-choi @ fab1an لست متأكدًا تمامًا من كيفية عمله ، لكن لدي شعور بأن Electron تأتي مجمعة مسبقًا في electron-packager ، ضمن Electron Framework.framework المضمنة في التطبيق المعبأ.

لذلك ، لا يوجد سبب لتجميع electron داخل تطبيقك node_modules . أيضًا ، ليست هناك حاجة لتثبيت حزمة npm electron على الجهاز الهدف حتى يعمل أسلوبي.

تمكنت إلكترون من إنشاء تطبيق Electron بحجم 115 ميجابايت إلى 167 كيلوبايت فقط باستخدام تقنيتها. أعتقد أنه يجب دمج هذه التقنية في الإلكترون ، تطبيق hello world بحجم 100 ميجابايت ليس بالحجم الطبيعي لعرض "Hello World": +1:

spaceywolfi نظرًا لأن Electrino لا يقوم بتشغيل محرك Chrome / V8 لعرض تطبيقك ، ولكن باستخدام محرك متصفح الويب الأصلي الخاص بـ OSX (WebKit) ، لا يمكنك حقًا استخدام تطبيق Electron الخاص بك وإنشاءه باستخدام Electrino ، خاصة إذا كنت تستخدم واجهات برمجة التطبيقات الإلكترونية ، لأنها غير متوفرة هناك. على الأقل ليس بعد.

يمكنك محاولة اتباع الحيلة التي ذكرتها لتقليل الحجم الثنائي الأساسي إلى 50 ميغا بايت تقريبًا.

eladnava شكرا لك على التوضيح!

تضمين التغريدة

لست متأكدًا تمامًا من كيفية عملها ، لكن لدي شعور بأن Electron يأتي مُجمَّعًا مسبقًا في حزمة إلكترونية ، ضمن إطار عمل Electron 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 لم يستبعد هذه التبعيات تلقائيًا من الثنائي النهائي ، مما أدى إلى حجم ثنائي يبلغ 100 ميغابايت تقريبًا بالنسبة لي. بعد تثبيت هاتين الحزمتين على مستوى العالم ، انخفض الحجم الثنائي إلى ~ 50 ميجابايت.

eladnava حدث هذا على الأرجح لأنك كنت npm install packagename --save-dev فسيؤدي ذلك إلى حفظه في المنطقة المناسبة من package.json . سيظهر في مجلد node_modules ولكن ستتم إزالته بمجرد حزمه.

تضمين التغريدة

هذا ممكن بالفعل. لكنني أعتقد أنه نظرًا لأن الإصدارات الأحدث من npm بتثبيت جميع التبعيات الخاصة بك في مجلد المشروع الجذر node_modules/ ، فقد يتم تجميعها بواسطة electron-packager في الثنائي النهائي .

هل تعرف ما إذا كان electron-packager ذكيًا بما يكفي لحذف تلك التبعيات devDependencies ؟

تضمين التغريدة

هل تعرف ما إذا كانت أداة حزم الإلكترون ذكية بما يكفي لتجاهل تبعيات devDependency تلك؟

يمكن تأكيد أنه يحذف التبعيات devDependencies . حتى إذا كنت تستخدم أحدث إصدار من NPM أو Yarn.

يجب أيضًا استخدام نظام إنشاء مثل Gulp أو Grunt لتجميع تبعيات الواجهة الأمامية وإدراجها في devDependencies أيضًا. هذا لأنه قد يتم شحنها مع ملفات مصدر إضافية أو devDependencies . المرة الوحيدة التي أحصل فيها على شيء ما في dependencies هو أنني بحاجة مطلقة لشحنه. ستظل البرامج النصية الخاصة بك ترغب في العمل في سياق العقدة ، لذا ستحتاج إلى استدعاء window.module = module; module = undefined; قبل تحميل البرامج النصية المجمعة في سياق المستعرض. ثم أتأكد من أن جهاز التغليف الخاص بي يحتوي على هذا في خيار التجاهل "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)" . يؤدي القيام بكل هذه الخطوات بشكل أساسي إلى التخلص من زيادة التبعية المفرطة أو تضمين ملفات المصدر أو مجلدات الإنشاء عن طريق الخطأ.

تضمين التغريدة

في صحتك للنصائح يا صديقي!

اهلا ياجماعة،

من أجل تقليل حجم التطبيق بشكل كبير للجميع ، وحفظ النطاق الترددي للجميع ، وجعل عملية الإنشاء أسهل للجميع ، وما إلى ذلك.

ماذا عن استخدام نفس الفكرة التي استخدمتها تطبيقات Java و Java بنجاح لعقود من الزمن: اعتمد على "JRE" (والتي ستكون "ERE" في حالتنا).

بهذه الطريقة ، سيتم تثبيت ERE عالميًا على الجهاز لأول تطبيق يحتاج إليه (يمكن أتمتة عملية طلب ERE بواسطة مثبت التطبيق لكل نظام أساسي) ، وبعد ذلك كل تطبيق جديد سيستخدم فقط هذا ERE الحالي. .

سيحتاج ERE إلى ميزة التحديث التلقائي والتوافق مع الإصدارات السابقة (بدون bcb!) حتى يعمل هذا ، لكنني متأكد من أن هذا أمر تافه.

بعد ذلك ، سيزن كل تطبيق Electron مثل بضعة ميغا بايت فقط. توفير وقت المستخدمين. توفير الوقت والنطاق الترددي للمطورين وبناء التعقيد.

هل تم اقتراحه من قبل؟ إذا كان الأمر كذلك ، فماذا عن ذلك بعد ذلك؟ أعتقد أن هذه هي الطريقة الوحيدة وأفضل طريقة للذهاب.

RenaudParis لقد اقترحتها من قبل وربما أكثر من ذلك ، لكنني لم أسمع أي أعمال جادة حتى الآن.

yasinaydin لقد برزت بنفس القدر ، يجب أن يكون الناس قد فكروا في ذلك من قبل.

حسنًا ، أي مدخلات من فريق التطوير إذن؟ zcbenz هذا من شأنه أن يجعل الكثير من الناس سعداء ، وسيجعل إلكترون وقتًا طويلاً لإثبات المستقبل (لأننا لنواجه الأمر: إن تضمين إطارين داخل كل تطبيق يحد بشكل خطير من استخدام التطبيقات الأصغر ، وهذا صخب منتظم كان مستمرًا على لسنوات)

أليس JRE مثالًا رائعًا يجب اتباعه هنا؟

RenaudParis و yasinaydin ، هناك العديد من الأسباب التي تجعل تثبيت عالمي للإلكترون لن يحدث أبدًا.

أولاً ، من بين جميع تطبيقات إنتاج الإلكترون الموجودة في البرية ، ربما يوجد أكثر من 20 إصدارًا مختلفًا من الإلكترون قيد الاستخدام. ما هو الإصدار الذي تختاره عالميًا؟ إنه مجزأ على هذا النحو لأن الإلكترون لديه دورة إصدار سريعة ويريد المطورون الوصول إلى أحدث ميزات Chrome.

يتم اختبار تطبيقاتنا فقط بإصدار واحد من الإلكترون ومن أجل تنزيل 40 ميجا بايت ، فلماذا نتحمل المخاطر وتكاليف الدعم للسماح لها بالعمل على أي إصدار عشوائي آخر لم يتم اختباره؟

جعل عملية البناء أسهل للجميع

تستخدم العديد من تطبيقات الإلكترون وحدات أصلية يجب بناؤها في معظم الحالات مقابل إصدار محدد من الإلكترون قيد الاستخدام. كيف ستحل هذه المشكلة؟

لا تتردد في إنشاء إصدار عالمي من الإلكترون يمكن للمطورين استخدامه ولكن أعتقد أنك ستجد أنه بالكاد يستخدمه أي شخص للأسباب المذكورة أعلاه!

تضمين التغريدة
there are so many reasons having a global install of electron will never happen.
يبدو هذا كواحد من هؤلاء: https://www.pcworld.com/article/155984/worst_tech_predicted.html

نظرًا لأن Node / v8 أو ثنائيات الإلكترون ليست كبيرة جدًا ، يمكن لـ ERE العالمية تنزيل المكونات المفقودة لاستخدامها مرة واحدة ، إذا لزم الأمر. يمكن أيضًا تنفيذ بعض منطق الحزمة لهذه ERE العالمية ، مثل Node.js 9.x بدلاً من Node.js 9.0 ، 9.1 ، إلخ.

لا أعرف ولكن لا أعتقد أن هذا هو الموقف من القيام بالأشياء ... "أوه لا يمكن فعل ذلك. أوه إنه مستحيل. لا معنى له." بدلاً من ذلك ، يجب أن يكون "كيف يمكننا إنجاز / حل هذا x؟"

timfish ، هذا خبر محزن ... أنا شخصياً لا أهتم كثيراً بملف 40 ميغا بايت ، لكن 120 ميغا بايت (كما سمعت) مع ذلك كثير جداً بالنسبة لعالم الترحيب.

أولاً ، من بين جميع تطبيقات إنتاج الإلكترون الموجودة في البرية ، ربما يوجد أكثر من 20 إصدارًا مختلفًا من الإلكترون قيد الاستخدام. ما هو الإصدار الذي تختاره عالميًا؟

كما قلت ، التوافق مع الإصدارات السابقة سيكون مطلوبًا.

يريد المطورون الوصول إلى أحدث ميزات Chrome

ومن ثم التحسين التدريجي ... أليس كذلك؟ على أي حال ، حتى التحسين التدريجي ليس إلزاميًا إذا كان التطبيق يتطلب إصدارًا معينًا من ERE ، مما قد يؤدي إلى تحديث ERE العالمي.

كيف ستحل هذه المشكلة؟

إذا احتاج بعض الأشخاص إلى وحدات مجمعة على وجه التحديد ، فإنهم يتمتعون بحرية تضمين نسختهم المخصصة من الوحدات النمطية (والتي لن تكون متاحة على أي حال داخل ERE على أي حال) وتحديد إصدار أدنى من ERE. إذا تم تحديث ERE إلى إصدار أحدث ، أعتقد أن هناك حلين واضحين: إما أنهما يقومان بتحديث وحداتهما (كما هو الحال مع التبعيات في Node اليوم) أو يمكننا أيضًا السماح بإصدارات عالمية متعددة من ERE (مثل JRE). أعتقد أن هذه ليست قضية.

للإلكترون دورة إطلاق سريعة

هذا شيء عظيم ، بلا شك هنا. ولكن ربما يمكن للأشخاص البقاء على قيد الحياة بإصدار شهري ، وبالتالي الحد من كمية إصدارات ERE.

لا تتردد في إنشاء نسخة عالمية

نعم ... لن أفعل ذلك. لا أمتلك المهارات ، لكني كنت سأفعل ذلك لو امتلكت.

يمكنني فقط تقديم الاقتراحات التي أراها مناسبة ، والسماح للخبراء بأداء عملهم: إما أنهم يخبرونني أنني أحمق مع اقتراحاتي (وهو ما قد يكون الأمر كذلك) ، أو يعتقدون أنه قد يؤدي إلى شيء لطيف . ايا كان :)

ما زلت أعتقد أن ERE العالمي سيكون الحل الأفضل ، حتى لو كان ذلك يعني وجود العديد من EREs للاحتياجات المختلفة للتطبيقات المختلفة الموجودة هناك. لكن ، مرة أخرى ، هذه مجرد فكرة خطرت لي من المقارنة بـ JRE.

تضمين التغريدة

هذه أخبار محزنة ... أنا شخصياً لا أهتم كثيراً بملف بحجم 40 ميغا بايت ، لكن 120 ميغا بايت (كما سمعت) يعتبر أكثر من اللازم بالنسبة لعالم الترحيب.

120 ميغا بايت غير مضغوطة ، إذا قمت بضغطها فهي حوالي 40 ميغا بايت. على سبيل المثال ، يبلغ حجم VSCode 64 بت لتثبيت Windows EXE حوالي 42.8 ميغابايت.

أنا شخصياً ، بصفتي مستخدم ، أفضل دائمًا أن يكون لدي تطبيق مستقل دون الحاجة إلى إدارة JRE العالمية (أو ERE) حتى لو كان عليّ تنزيل 200 ميجا بايت بدلاً من 10 ميجا بايت.

إنها ليست 120 ميجابايت فقط ، لقد أنشأت تطبيق ويب بسيطًا كان حوالي 1 ميجابايت على خادم الويب ولكن ~ 300 ميجابايت كتطبيق Electron على OS X

بالإضافة إلى ذلك ، يصبح هذا الأمر أكثر أهمية عندما يكون هناك العديد من تطبيقات Electron التي تعمل على نفس الجهاز.
ثم سيكون أكبر بعشر مرات ، 20 مرة.
يوجد الآن العديد من التطبيقات القياسية على جهاز كمبيوتر تم إنشاؤه باستخدام Electron مثل Slack و VSCode وما إلى ذلك ، وهناك مشروعات أكبر مثل NodeOS.

يحتوي Node.js على> 500 ألف وحدة. إذا كانت Electron ستصبح أفضل وأسرع وأكثر شهرة وأصغر ، فسيكون هناك العديد من التطبيقات على سطح المكتب ، مع غيغابايت من ملفات Electron غير الضرورية.

ليس الإلكترون أفضل إطار عمل.

أفضل النظر في تقسيم الأجزاء غير الضرورية من إطار عمل Chrome مثل Flash وما إلى ذلك.

تضمين التغريدة

1 ميجابايت على خادم الويب ولكن ~ 300 ميجابايت كتطبيق Electron على OS X

تحتاج إلى تنظيف التطبيق الخاص بك قبل التوزيع (تلميح: تحقق من node_modules). على سبيل المثال ، يبلغ حجم VSCode على Windows 228 ميجابايت بعد التثبيت (التثبيت القابل للتنزيل هو 42.8 ميجابايت فقط).

لكن حجم التثبيت مشكلة واحدة فقط ، والمشكلة الأخرى هي مقدار استخدام تطبيق ذاكرة الوصول العشوائي ووقت التشغيل. في تجربتي ، بمجرد تشغيل التطبيق ، لن تكون سرعة التطبيق مشكلة.

لا يعد Electron مناسبًا للتطبيقات الصغيرة ، ولكنه يعمل مع التطبيقات الكبيرة مثل VSCode.

مشكلة أخرى هي مقدار استخدام تطبيق RAM ووقت التشغيل

mvladic ألا تعتقد أن هاتين المسألتين بالتحديد

حسنًا ، ربما لا يكون لدى الأشخاص 10 تطبيقات إلكترونية تعمل في نفس الوقت ... لكن ربما سيفعلون! من المهم تحليل التبعيات قدر الإمكان.

لقد أدركت أن Electron تم إطلاقه لأول مرة باعتباره POC ، ثم احتاج إلى إصدارات متكررة جدًا لإرضاء المطورين. ولكن ربما الآن بعد أن أصبحت Electron أكثر نضجًا ، يجب اتخاذ بعض الإجراءات لضمان أفضل {وقت تحميل واستخدام ذاكرة الوصول العشوائي وحجم التنزيل}.

مرة أخرى ، أقترح فقط حلاً (ربما يكون ساذجًا ، لا أعرف) للمشكلات التي يبدو أن مستخدمو الإلكترون يتشاجرون بشأنها منذ البداية. لكن بقدر ما أشعر بالقلق ، لا أمانع حقًا الحالة الحالية للإلكترون لاحتياجاتي الصغيرة. الإلكترون رائع ، أنا أفكر فقط في طرق لجعله أفضل.

ليس الإلكترون أفضل إطار عمل.

@ fab1an ، يعتمد على ما يحتاجه الناس. بالنسبة لي ، إنه مناسب تمامًا لاحتياجاتي ، لأنني لست متأكدًا من أن PWAs ناضجة بدرجة كافية. ولكن مرة أخرى ربما تكون Qt مناسبة بشكل أفضل لأشخاص آخرين ، فأنت محق في ذلك.

تم اقتراح وقت التشغيل ومناقشته من قبل ولا يزال مناقشة مفتوحة . لكن قول هذا هو أحد الأشياء التي يسهل قولها أكثر من فعلها. كما ترى ، لم يتمكن الجميع من الوصول إلى نفس الصفحة أو اكتشاف كيفية إخراجها بشكل صحيح من الأرض حيث ستعمل بشكل موثوق في الإنتاج. إذا كنت تعتقد أنه يمكنك المساهمة في المناقشة أو المساعدة في البدء بها ، فلا أعتقد أن أي شخص قد يمانع في الحصول على مساعدة إضافية.

يسعد الكثير من المطورين بمن فيهم أنا بإخراج تنزيل 40 ميغا وتحديثه باستخدام تحديثات دلتا أصغر. لا يواجه الأشخاص اليوم مشكلة في تنزيل برنامج 40 ميغا. وحتى البرامج الصغيرة التي يبلغ حجمها بضع ملفات ميغا قد يتم تنزيلها وتثبيتها 40 ميغا - 2 عربة ولا يبدو أن أي شخص لديه مشكلة. معها. حتى لو كان خيار وقت التشغيل متاحًا ، فمن المحتمل ألا يكون لدى المستخدم ذلك وسيتعين عليه تنزيل 40+ ميغا لتشغيل مشروعك على أي حال.

إذا لم يكن هذا التحذير هو فنجان الشاي الخاص بك ، فابحث عن خيار آخر إذا لزم الأمر. لا أقصد ذلك بصراحة ، في بعض الأحيان يتعين عليك التخلص من التقنيات لتحقيق الهدف والشروط التي ترغب في تحقيقها. لكن هذا لا يجعل من الإلكترون تقنية سيئة أو يجعلها غير قابلة للاستخدام للعديد من الآخرين. لا يُقصد من الإلكترون حل كل الحلول. وواقعيا أنها لن تفعل ذلك أبدا.

baconbrad إذا كان تعليقك التكنولوجيا المناسبة لاحتياجاتي (المحددة).

قلت فقط إنني رأيت العديد من الأشخاص يشتكون في كل مكان من حجم العبوة وكنت أعرض فقط حلاً (ساذجًا مرة أخرى) لهذه المشكلة ، والذي بدا لي مثاليًا. لكن قد أكون مخطئًا جدًا ، وعلى أي حال لن يمنعني ذلك مطلقًا من استخدام الإلكترون لاحتياجاتي المستقبلية :)

حتى لو كان خيار وقت التشغيل متاحًا ، فمن المحتمل ألا يكون لدى المستخدم ذلك وسيتعين عليه تنزيل 40+ ميغا لتشغيل مشروعك على أي حال.

نعم ، لكنني أعرف الكثير من الأشخاص ، حتى هنا في وسط باريس ، الذين لديهم اتصال إنترنت بسرعة 5 ميجابت في الثانية فقط ، وبالنسبة لهؤلاء الأشخاص ، فإن توفير 40 ميجابايت (أي 320 ميجابايت) لكل تطبيق يعني توفير دقيقتين في كل مرة يتم فيها تحديث التطبيق (لا تفعل ذلك) ننسى أن 40 ميغا بايت ستكون لكل تحديث ، وليس فقط التثبيت الأول) ، بالنظر إلى عدم استخدام اتصال الإنترنت الخاص بهم.

إنه لا يأخذ في الاعتبار مدخرات ذاكرة الوصول العشوائي ، خاصة بالنسبة لأجهزة الكمبيوتر المحمولة. مرة أخرى ، لا أشعر بالقلق شخصيًا لأن لديّ آلة جيدة نسبيًا بسعة 32 جيجا بايت من ذاكرة الوصول العشوائي ، لكنني لا أفكر في نفسي هنا ، بل أفكر في الأشخاص الذين يشكون ، وآمل أن أجد حلًا لهم.

أخيرًا وليس آخرًا ، قد يكون لديك اتصال جيد ، وكذلك أنا (اتصال سريع للغاية إذا سمحت! :)) ، وقد يكون لدينا 16 أو 32 أو 64 جيجابايت من ذاكرة الوصول العشوائي ، وهذا هو السبب في أنك (أنت) لا تفعل ذلك. لا تمانع في تنزيل 40 ميغابايت لكل تحديث ، ولكن ماذا عن المستخدمين لديك (بالنظر إلى أنك توزع تطبيقك على الأشخاص)؟

على أي حال ، لن أقاتل بشأن هذا ، كنت أسعى فقط للمساعدة ، وكما قلت أنا سعيد جدًا كما هي ، ولدي الكثير من الأشياء التي يجب أن أحضرها.

إذا اعتقد بعض الناس أنه يمكنني مساعدتهم في التفكير في حل ، فسأكون سعيدًا بمد يد العون ، ولكن بخلاف ذلك سأعود إلى العمل :)

هتافات،

شيء واحد رأيته عند نقل المزيد من التبعيات إلى devDependencies ، كلما احتاجت إلى مزيد من الوقت لبنائها.

""
✔ عملية البناء الرئيسية

• عملية عارض البناء
  ""

قضى الكثير من الوقت في "عملية عارض البناء" ، وتوقف الرمز المتحرك كما لو أنه يتعطل ولكنه لم يفعل. ثم تظهر 203778ms من تقرير العارض.

إعادة الاعتماد على التبعيات إلى التبعيات ، يعد وقت الإنشاء أمرًا طبيعيًا مرة أخرى ولكن التطبيق كبير.

إذا لم أواجه أي خطأ أثناء الإنشاء ، فهذا يعني أنه كل شيء على ما يرام ، أليس كذلك؟

karimhossenbux هذا طبيعي بالنسبة لي. هناك وظيفة سير في electron-packager تمر عبر جميع التبعيات لتحديد ما إذا كان يجب أن تكون موجودة أم لا. مع تبعيات النمط المسطح الجديد بدلاً من المتداخلة ، سيستغرق الأمر وقتًا أطول لتحديد التبعيات غير الضرورية. بقدر ما أعرف لا توجد طريقة للالتفاف على وقت البناء الإضافي.

baconbrad شكرا لك! أنا أستخدم electron-builder لكن أعتقد أنه يعمل بنفس الطريقة.

هل هناك أي أداة إنشاء حزم إلكترونية تتضمن مصدرك فقط وتنزيل الآخرين (ضروري فقط لمستخدم نظام التشغيل الحالي الذي يعمل عليه المستخدم) عندما يقوم المستخدم بتشغيل تطبيقك لأول مرة؟ سيجعل ذلك من السهل التوزيع ويجب أن يقلل حجم تطبيقك إلى حد كبير.

إلكترون ، من فضلك لا تسلك طريق "ERE". نعم ، أعلم أنك منتفخ ، لكني أحب كيف يمكن للأشخاص تنزيل تطبيقي وهو يعمل بشكل رائع دون الحاجة إلى الالتفاف حول تثبيت الأقسام أو تحديث بيئة وقت التشغيل أو أي من هذا الهراء الذي اعتقدت أننا تخلصنا منه حوالي عام 2003 .

حسنًا ، سيظل تنزيل حزمة خيارًا. لا شيء للشكوى
عن المكان :)

لو فين. 25 ماي 2018 à 21:03، لوقا Pighetti [email protected] ل
écrit:

إلكترون ، من فضلك لا تسلك طريق "ERE". نعم ، أعلم أنك منتفخة ،
لكني أحب كيف يمكن للأشخاص تنزيل تطبيقي وهو يعمل بشكل رائع
دون الحاجة إلى الالتفاف حول تثبيت الأقسام ، وتحديث وقت التشغيل
البيئة ، أو أي من هذا الهراء الذي اعتقدت أننا تخلصنا منه
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 في التبعيات يتم استيراده مرة أخرى إلى الملف التنفيذي النهائي.
(من السهل جدًا التحقق: يكفي فك الملف القابل للتنفيذ)
لذلك تذكر أن تحدد فقط libs الأساسية في التبعيات (سجل الإلكترون ، محدث الإلكترون) وأضف كل libs الأخرى في devDependencies.

عندئذٍ ، سيصبح تطبيقك 50 ميغا بايت "فقط" ...

تطبيقي صغير - ها هو الريبو. أحدث نسخة تجريبية تزن حوالي 700 ميجابايت
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

أنا أيضا أتساءل عن هذا. فيما يلي أحجام تطبيق الإلكترون الخاص بي:

  osx - 117.3 mb

لينكس 32 - 60.3 ميجا بايت
لينوكس 64 - 55.2 ميغا بايت
فوز ia32 - 47.8 ميغابايت
win x64 - 66.2 ميجا بايت
شكرا!

مدهش! هل يمكنك مشاركة معلومات حول كيفية تقليل حجم تطبيق الإلكترون إلى حجم صغير جدًا.