Главный секрет разработки хороших Electron-приложений

Автор оригинала: James Long
  • Перевод
Кое-кто люто ненавидит Electron-приложения. То, что приложение включает в себя браузер Chromium, кажется, мягко говоря, странным. Это ощущение усиливается в ходе работы с такими приложениями. Они потребляют много памяти, медленно загружаются и не отличаются особенно высокой скоростью реакции на воздействия пользователя. Непросто разработать хорошее приложение для веба. Зачем же веб-технологии притащили в настольную среду? Ведь возникает такое ощущение, что в этой среде они создают кучу проблем?

Автор материала, перевод которого мы сегодня публикуем, говорит, что не станет выступать в роли защитника Electron, хотя всё говорит об успешности этой платформы. Правда, никто не собирается сбрасывать со счетов излишества, которые присущи Electron-приложениям. Можно ли, разрабатывая такие приложения, убить одним выстрелом двух зайцев?


Некоторые из проблем Electron (большие размеры файлов, медленная загрузка) являются наследием технологий, на которых основана эта платформа. Их надо решать на низком уровне. Более серьёзные проблемы (потребление памяти, неповоротливость интерфейсов) могут быть решены на том уровне, на котором разрабатывают Electron-приложения. Однако решать эти проблемы непросто. Что если есть некий секрет, зная который можно, в автоматическом режиме, минимизировать эти недостатки?

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

Суть секрета


Секрет разработки качественных Electron-приложений заключается в выполнении основного объёма вычислений на локальной системе, в фоновых процессах. Чем меньше вы полагаетесь на облачные сервисы, и чем больше работы выносите в фоновые процессы, тем сильнее вы сможете ощутить следующие позитивные эффекты:

  • Мгновенная загрузка данных. Пользователям приложения никогда не придётся ждать загрузки данных по сети. Данные загружаются из локального хранилища. Это сразу же даёт приложению ощутимый прирост производительности.
  • Небольшие потребности в кэшировании. Клиентскому приложению не нужно особенно беспокоиться о кэшировании. Это так из-за того, что все необходимые ему данные доступны локально. Для того чтобы веб-приложение смогло бы выйти на достойный уровень производительности, ему обычно нужно загрузить в своё локальное состояние данные внушительного объёма. Это — одна из причин очень большого потребления памяти Electron-приложений.

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

Взгляните на то, какой объём памяти потребляет моё Electron-приложение — менеджер личных финансов Actual. Эта программа хранит все свои данные локально. Синхронизация данных между разными устройствами — это необязательная возможность, она не влияет на основной функционал. Полагаю, если учитывать то, что это приложение предназначено для работы с большими объёмами данных, его показатели потребления памяти говорят сами за себя.


Потребление памяти приложением Actual

Приложение, которое не выполняет каких-либо активных действий, занимает, в целом, 239.1 Мб памяти. Этот показатель может быть и больше, он зависит от того, что именно происходит в приложении, но за базу можно принять именно указанное число. Это — не идеально, но не так уж и плохо. По крайней мере — лучше, чем те 1371 Мб памяти, которые требуются на моём компьютере Slack. Надо сказать, что Slack — это нетипичный пример Electron-приложения, характеризующийся специфическими проблемами. Вокруг Electron из-за Slack поднялась некоторая шумиха. Другие приложения, вроде Notion или Airtable, потребляют примерно 400-600 Мб памяти. А это значит, что моё приложение неплохо выигрывает в этом плане и у них.

Надо сказать, что показатель в 239.1 Мб получен мной до проведения каких-либо оптимизаций. Я планирую переписать некоторые из чрезвычайно важных и требовательных к памяти фрагментов приложения на Rust. Это должно значительно уменьшить потребности приложения в памяти.

Фоновый сервер может оптимизировать собственное потребление памяти, загружая в память только нужные в некий момент времени данные. Лучше всего для хранения данных пользоваться чем-то вроде SQLite. Эта СУБД уже серьёзно оптимизирована для решения подобных задач (серьёзно — просто пользуйтесь SQLite). Кроме того, надо отметить, что перемещение различных вычислений в фоновые процессы позволяет пользовательскому интерфейсу приложения реагировать на воздействия пользователя настолько быстро, насколько это возможно.

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

Даже если ваше приложение серьёзно завязано на облачные данные — вам может понадобиться фоновый процесс в том случае, если вы собираетесь работать с API Node.js. Спокойно взаимодействовать с этими API можно только из фоновых процессов. Собственно говоря, каким бы ни было ваше Electron-приложение, я полагаю, что знакомство с проектом, который мы сейчас рассмотрим, способно дать вам какие-то полезные идеи.

Приложение electron-with-server-example


Я создал приложение electron-with-server-example для того чтобы на его примере показать всё, что нужно настроить для разработки по-настоящему локальных Electron-приложений. Сделал я это в стремлении увлечь программистов созданием подобных проектов. Мне бы хотелось встретить подобный проект в то время, когда я только начинал работать с Electron.

Технические сведения о приложении можно найти в файле README. Вот общий обзор проекта:

  • В нём создаётся обычный процесс Node.js, используемый для выполнения серверного кода в фоновом режиме.
  • В нём, с помощью node-ipc, создаётся IPC-канал, который предназначен для организации прямого взаимодействия между бэкендом и пользовательским интерфейсом приложения.
  • Если проект запускают в режиме разработки, то сервер запускается не в виде фонового процесса. С ним можно взаимодействовать через отдельное окно браузера. Это нужно для целей отладки.

Теперь давайте немного притормозим и приглядимся к последнему пункту этого списка. В режиме разработки с сервером можно взаимодействовать через отдельное окно браузера?


Клиентская и серверная части приложения

Да, так оно и есть. После того, как я научился запускать фоновые процессы, я понял, во-первых, то, что в моём распоряжении имеются инструменты разработчика Chromium. А во-вторых — я понял, что я, в отладочных целях, могу пользоваться ими для отладки Node.js-кода. В результате я и говорю о том, что с Node.js можно взаимодействовать через браузер. Это позволяет использовать богатый набор инструментов разработчика браузера, основанного на Chromium, для отладки серверного кода.

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

Использование консоли


Я добавил в файл server-ipc.js команды логирования запросов и ответов. Исследовать их я могу с помощью консоли браузера.


Отладка Node.js-приложения в консоли браузера

Пошаговое выполнение кода


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


Пошаговое выполнение кода

Профилирование


Возможно это — мой любимый инструмент. Речь идёт о блестящем стандартном средстве для исследования производительности кода, которое позволяет профилировать серверную часть приложения.


Исследование производительности серверного кода

С помощью инструментов разработчика браузера можно даже исследовать то, что происходит при запуске фонового процесса (это, скорее всего, самая «тяжёлая» часть запуска приложения).

Для того чтобы это сделать достаточно запустить процесс записи показателей и перезагрузить окно. Перезагрузка приведёт к перезапуску сервера. Это ведёт нас к следующему шагу.

Перезагрузка сервера с помощью комбинации клавиш Cmd+R или Ctrl+R


Ещё одна из возможностей отладки серверного кода в браузере заключается в том, что, так как отладка сервера выполняется в окне браузера, простая перезагрузка содержимого окна приводит к перезапуску сервера! Достаточно воспользоваться комбинацией клавиш Cmd+R (или, для Windows, Ctrl+R), и в вашем распоряжении оказываются самые свежие изменения, внесённые в серверный код. При этом данные фронтенда сохраняются. Это значит, что с клиентской частью приложения можно продолжить работу, но, после перезапуска сервера, клиентская часть уже будет работать с новой версией серверного кода. Это напоминает нечто вроде «горячей» замены кода на работающем сервере.

На следующем рисунке показано, как я, изменив код сервера, перезагрузил страницу, нажав Cmd+R. После этого я продолжил работать с клиентом, который теперь взаимодействует с новой версией сервера.


Перезагрузка сервера

Исследование работающей серверной части приложения и «горячая» замена кода


Обычно я, отлаживая сервер, просто добавляю в нужные места кода команды console.log() и перезапускаю его. Но иногда, в особо сложных случаях, бывает так, что крайне полезно было бы заглянуть в то, что происходит в работающем сервере, а не перезагружать его. Возможно, что и не только «заглянуть» внутрь сервера, но и что-то в нём поменять для того чтобы посмотреть на то, как это повлияет на проблему.

В консоли можно пользоваться командой Node.js require. Это означает, что с её помощью можно подключать любые модули сервера и работать с ними в консоли.

Предположим, нам нужно поработать с модулем server-handler.js. Для этого достаточно выполнить в консоли команду let handlers = require('./server-handlers').

Создадим систему для хранения состояния сервера. В нашем случае это будет список всех данных, переданных функции make-factorial (серверное состояние реального приложения будет устроено гораздо сложнее):

handlers._history = []
handlers['make-factorial'] = async ({ num }) => {
  handlers._history.push(num)
  
}

Исследовать состояние сервера можно из консоли, подключив соответствующий модуль и взглянув на handlers._history. При желании, во время выполнения программы, мы можем даже полностью заменить реализацию make-factorial!


Исследование состояния сервера

Итоги


Взгляните на репозиторий electron-with-server-example для того, чтобы почитать о деталях реализации проекта и посмотреть код серверной части Electron-приложения.

Если вы пользуетесь Visual Studio Code, то вы, возможно, привыкли к качественной интеграции инструментов разработчика с Node.js-сервером. При таком подходе вы можете самостоятельно, отдельно от Electron-приложения, запустить сервер. После этого можно сообщить Electron о том, что нужно подключиться к процессу, владельцем которого является VS Code. Однако я предпочитаю использовать существующие инструменты разработки Electron.

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

Последние несколько лет я, разрабатывая приложение Actual, постоянно пользуюсь тем, о чём только что рассказал. И хочу сказать, что всё это мне очень нравится. Возможно, работа над Node.js-частью этого приложения стала источником самых приятных из когда-либо испытанных мной впечатлений от программирования.

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

Уважаемые читатели! Как вы относитесь к приложениям, основанным на Electron?

RUVDS.com
821,62
RUVDS – хостинг VDS/VPS серверов
Поделиться публикацией

Комментарии 35

    –2
    Главный секрет разработки электрон приложений это найти и подобрать достаточное количество костылей, чтобы оно заработало одинаково везде. Взять тот же драг энд дроп файлов из ОС в электрон и обратно, профилируй это не профилируй один черт нормально это под тремя осями не работает.
      +6
      Уважаемые читатели! Как вы относитесь к приложениям, основанным на Electron?

      Skype,… Ну і как можно относится к приложениям, которие лагают на топовом железе?
      Да у нас проблема с мультиплатформеним GUI, но костили в виде Electron і других не сильно то помогают.
      Наверное нужно создавать что на подобиии NET Только для GUI (GUI STANDART) на основании какойто разметки. И главное добится что б оно работало на всех платформах.
        +1
          +1
          Я слежу за етим проектом, Пока он в стадии альфа-бетта.
          Хотя идеи очень интересные. Надеюсь он взлетит. Но пока…
          +5
          Но с другой стороны есть VS Code
            +2
            Который безбожно выжирает оперативку на моем ноуте.
            Chrome c 5-6 закладок + VS Code — гарантированный висяк системы на 4Gb оперативки.
            На работе на 8Gb — еще куда ни шло… Но дома — либо интернет либо VS Code.
              +3

              Справедливости ради, продукты JetBrains потребляют ещё больше ресурсов. Мне в одно время пришлось перейти на VSCode по этой причине.

                –1
                Так это сравнение редактора с IDE. А вот если сравнить с саблаймом.
                  0

                  Конечно Sublime быстрее и легче, это другой класс ПО, VSCode даёт более продвинутые возможности при работе с JS и TS. Sublime уместно сравнивать с редакторами типа Atom и Notepad++.

              0

              Видимо, в отделе разработки VSCode понимают, что девелоперы прожорливым монстром пользоваться не будут, вот и работают над оптимизациями.


              А в отделе разработки Skype – и так сойдет!

                +1
                Сам то VS Code еще куда ни шло… Но голый он — простой текстовый редактор с некоторыми доп возможностями (никак не IDE).

                Что-то потребное из VS Code получается путем добавления плагинов. И вот с плагинами (мне не так важно кто именно из них) они начинают жрать память как черная дыра.
                +1
                Но с другой стороны есть VS Code
                Который жрет ровно столько же, сколько полноценные среды разработки, но при этом не предоставляет всех их возможностей
                0
                Вроде же Skype на React: dev.skype.com/react.
                +2
                Вы вообще представляете, как работает электрон? Чудо не то, что скайп лагает — чудом было бы, если бы он не лагал.
                +8
                Надо сказать, что показатель в 239.1 Мб получен мной до проведения каких-либо оптимизаций


                У меня тоже есть приложения для личных финансов. Написано на wxWidgets. Жрет аж 10Мб памяти и столько же на диске.
                  +3
                  Речь не о том, что это мало для приложения такого рода, а о том, что это мало для Electron приложения. Автор не пытается никого убедить, что Electron это технология без слабых сторон.
                  +3
                  Как вы относитесь к приложениям, основанным на Electron?

                  Зависит от конкретного приложения. Например, VSCode вполне неплох, Slack и Postman начинают иногда тупить на ровном месте, анимации (зачем они вообще) дергаться и т.д. Ну а новый Skype это просто «шедевр» — печатаешь текст, на 5 секунд все фризится, потом отпускает. При этом в эти момент нагрузки нет вообще никакой, а железо такое, что спокойно тащит несколько копий IDEA и Хром с парой десятков вкладок.
                  Про повышенное потребление памяти писать бессмысленно — это специфика технологии. Правда, когда Slack начинает занимать 1Гб становится страшно…
                    +3
                    Главный секрет в том что это должно быть действительно десктопное приложение. То есть приложение предоставляющее дополнительный функционал по сравнению с обычной веб страницей за счет возможности интеграции с операционной системой что недоступно для браузеров (используя Node.js который встроен в Electron) и за счет возможности внедрения в оригинильную веб страницу произвольного кода что дает возможность расширить функционла на десктопе. К сожалению, как правило, это не так.
                      +1
                      Написать шустрое приложение на Electron довольно просто. Достаточно всего лишь выкинуть на хрен все фреймворки и всю работу с DOM.
                      По сути, весь UI должен состоять из одного большого Canvas на всё окно, где уже вручную рендерим всё что нужно.
                      Если в приложении идёт обработка большого количества мелких элементов данных, то хорошо бы ещё собственный сборщик мусора написать вместо дефолтного.
                      Правда, если всё это проделать, то неизбежно возникает вопрос: а в чём тогда смысл Electron? Ведь то же самое гораздо проще оказывается сделать при помощи C++/Qt.
                        +7
                        Главный секрет разработки хороших Electron-приложений

                        Не писать никаких Electron-приложений


                        Как вы относитесь к приложениям, основанным на Electron?

                        Думаю, и так понятно. Если вы пользовались когда-то приложениями вроде Slack или нового Skype, то ответ вполне однозначный — вы их скорее всего ненавидите.


                        Если вы пользовались VSCode, не всё так однозначно, но много ещё таких приложений вы знаете?


                        Если я вижу, что приложение на Electron, скорее всего я не буду его использовать.

                          +1
                          Skype версии 8 сделан на Electron?!
                          Аплодисменты!
                          Это их лучшая версия за 10 лет! Без шуток, я не любил скайп до этой версии.
                          На стареньком Core 2 Duo работает без лагов, хотя старые версии постоянно зависали и делали что-то непонятное.
                          С аудио оборудованием работает прекрасно! Раньше каждый запуск был мукой с выбором и проверкой гарнитуры :)
                            0
                            Skype версии 8 сделан на Electron?!
                            Аплодисменты!
                            Это их лучшая версия за 10 лет! Без шуток, я не любил скайп до этой версии.
                            Почему бы просто не пользоваться web.skype.com в браузере?
                              0
                              А и такая есть? :)
                              Не знал… десктоп клиент просто работает без нареканий пока
                              Видел только потуги сделать web-интерфейс к скайпу на outlook.com, но он не работал.
                            +1

                            Проблемы электрон уйдут, когда встроят наконец браузер в ОС, ну или хотя бы пока не сделают единый распространяемый фреймворк включающий хром, тогда не будет этого выжирания памяти каждым приложением, из-за того, что каждый поднимает свой инстанс chrome-окружения. Естественно, если не встраивать .net framework в ОС, а запускать его рантаймом с каждым приложением, то будут те же самые выдирания памяти и большие дистрибутивы.

                              +1

                              Надеемся на https://github.com/GoogleChromeLabs/carlo – похожий на Electron проект, который подцепляет Chrome из системы, вместо того чтобы тащить свой.

                                0
                                Зачем встраивать браузер в ОС? Не проще ли просто писать программу под эту ОС? Например, на Qt. И работать оно будет быстрее и прослойку в виде браузера тянуть не надо.
                                  +3
                                  Для программы на QT все равно придется делать отдельную Web версию (если такая требуется), а c Электроном получаем все платформы “одним махом”.
                                    +1
                                    Только работает оно так, что проще использовать веб версию, чем ставить себе ещё один браузер с каждым таким поделием. Я, например, использую веб версию слака вместо его десктоп варианта на электроне. Потому что реально минусов больше чем плюсов. И я с удовольствием пользуюсь десктопным приложением телеграма, потому что оно реально удобнее и функциональнее, чем веб версия. Ощутите разницу, как говорится)
                                  –1
                                  Проблемы не в electron, проблемы в html+DOM+JavaScript. Это худшее, что можно было придумать для UI. Современные фреймворки это отчасти исправляют, но до обычных компонентов типа Borland VCL им по удобству и скорости разработки бесконечно далеко.
                                    0
                                    Так это и есть основная идея electron — сайт запихнуть в окошко и обозвать приложением. По сути костыль, который незаменим в некоторых ситуациях, но не применим для всех подряд.
                                      0
                                      Да? Я вижу предложение «теперь разрабатывать десктопные приложения также легко, как и сайты!»
                                      И ладно бы для электрон приложений ionic использовали… А то костылят не по-человечески.
                                        0
                                        Вы видите то что хотите, но не то что есть в реальности.

                                        Запихнуть сайт в окошко != разработать хорошее полнофункциональное приложение. Это вынужденный костыль.

                                        З.Ы. Да и сделать хороший сайт не так уж и легко, как кажется.
                                  +1
                                  Читая подобные статьи и понимая, что вот это вот все сегодня самая настоящая норма, невольно задаешься вопросом где же мы свернули не туда.

                                  Электрон это рак. Причин лично я вижу несколько.
                                  1. Банально — потребление ресурсов, производительность, объем дистрибутивов.
                                  2. Полное игнорирование всех UX-паттернов на каждой конкретной ОС — у каждого приложения свой дизайн, чаще всего сделанный с нуля.
                                  3. Разработчики под электрон часто вообще не понимают что они делают, потому что большая часть из них приходит из веб-девелопмента, не имеет опыта разработки нативных приложений на десктоп и не знает особенностей конкретных ОС. Приложения задумываются и пишутся как сайты.
                                  4. Постоянное сглаживание углов из-за мнимой унификации всего и вся. Зачем иметь десктоп-кодера, если у нас вот тут есть js-программисты на фронт и бэк, а то и вообще целый мифический фулстэк? Зачем писать что-то нативно, если можно быстро набросать что-то под электрон? Зачем вообще что-то писать, если можно наше веб-приложение с парой небольших костылей выдать за десктопное?
                                  5. Частично следует из всего предыдущего — софт идет по пути упрощения и урезания функционала. Шаг влево или вправо невозможен в принципе.

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

                                  Но я прекрасно понимаю, что пути назад нет, добро пожаловать в js-мир :)
                                    +2

                                    Как уже выше писали, секрет разработки хороших приложений под Electron — не использовать Electron вообще. Единственный виденный мною вменяемый представитель — VSCode. MS Teams, с которым имею несчастье работать — унылое, неудобное, кастрированное, лагающее и жрущее ресурсы гуано мамонта. Чатик, кушающий 400Мб оперативы в фоне и подгружающий историю сообщений на каждый чих — держать в памяти больше текущей видимой страницы он не способен в принципе.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое