Взгляните на структуру кода Thunder

Electron

задний план

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

Случайно узнал, что клиент Thunder тоже разработан на основе Electron, тогда код легко дергается. (Сначала поговорим о том, почему некий Лей в этой новой версии должен копировать интерфейс DingTalk. С годами некий Лей не знает, что он собирается делать, и каждая версия отвратительна)

Демонтаж изделий

Немного базовых знаний

Десктопные приложения, построенные на основе стека фронтенд-технологий Electron, по сути загружают локальные файлы ресурсов фронтенда, причем эти файлы обычно упаковываются в формате asar (по аналогии с iso-образами windows), а потом фронтенд реализуется подвешиванием в памяти во время выполнения Чтение файлов ресурсов, таких как js/css/html/img.

Значит, asar может читать исходный код по своему желанию, если вы найдете способ его смонтировать? нет. В то же время asar предоставит набор методов шифрования для предотвращения произвольной распаковки, что и делает Feishu, и его нельзя распаковать напрямую через asar Extract. Однако, если бинарные файлы, созданные node и rust, упакованы в asar, они не могут быть связаны с этими бинарными файлами, поэтому их необходимо отделить от asar, в результате чего некоторые js-файлы все еще остаются открытыми. Но даже если js не выставлен, все равно есть способ его взорвать.

Ах, я сбился с пути, не будем о Фейшу, сегодня главное блюдо - Гром.

Как управляются внешние файлы ресурсов Xunlei?

Я слишком много думаю. Извините, Сюньлэй Мэйчуань Кузи весь разбросан там, и нет смысла использовать упаковку / шифрование asar.

открытый подглядывать

Теперь, когда js открыт, нечего делать, просто вставьте код напрямую. Все мы знаем, что у Electron есть процесс рендеринга и процесс Node.На следующем шаге нам нужно угадать, какой файл отвечает за основной процесс рендеринга? Ну не гадайте, названия очень понятные, просто main-renderer (процесс рендеринга главного окна). Откройте и найдите html-файл (js также может) и вставьте следующую строку

Дважды щелкните, чтобы начать, окно отладки выходит, вы можете примерно увидеть общую структуру страницы

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

Интерфейс просмотра отдельного окна - окно на самом деле в 4 раза больше плавающего окна, серая часть - это вся область BrowserWindow, используемая этим "маленьким" плавающим окном

немного защиты

С точки зрения кода процесс nodejs имеет только один файл main.js , который является продуктом сборки webpack.Глядя на исходный код, параметр webPreference BrowserWindow здесь отключает devTools.В результате вы не можете просматривать ни одно окно набрав openDevTools прямо в командной строке.

Конечно, неважно, что здесь обфусцировано, в конце концов, это все еще открытый текст, просто измените 1 на 0 и включите его (двойной восклицательный знак/true/1 подойдет, просто радуйтесь). Однако из-за того, что в Thunder слишком много окон, всплывающее окно загрузки является независимым окном, папка выбора является независимым окном, а также всевозможные рекламные окна.Есть много пунктов конфигурации, которые необходимо изменить, которых здесь нет.Всего окон 10.Этот пункт настройки включается по мере необходимости(возможна и пакетная замена,только будьте внимательны).

Структура процесса

Эээ... Тогда что делать... Вроде и нечего смотреть, код запутан, а файла карты нет. А код front-end части ничего не говорит о техническом содержании, которое одинаково для любой веб-страницы. Затем посмотрите на разделение труда.

дерево процессов

В дереве процессов видно, что почти все процессы - это Thunder.exe.Видно, что Thunder.exe используется как запись распределения процесса (аналогично шлюзу сервера, а не непосредственно самому бизнесу). запускается пользователем, параметры -- StartType:DesktopIcon, затем он вызывает две группы процессов, один из которых является основным процессом Electron, основной процесс вызывает соответствующий рендерер, а затем загруженный сервис SDK DownlaodSDKServer.

Тогда взаимосвязь процесса Thunder почти ясна: несколько окон Electron соответствуют одному DownloadSDK.

способ общения

Так как же процесс Electron (независимо от основного процесса или процесса рендеринга, вместе именуемого электронным процессом) взаимодействует с DownloadSDK?

Взаимодействие между процессами обычно реализуется в виде каналов ipc. Однако Thunder, похоже, не следует рутине: его DownloadSDK является консольной программой, а это означает, что он, скорее всего, будет взаимодействовать через stdio (последующее доказательство — нет).

Наблюдая за дескрипторами, открытыми процессом, я увидел очень странное явление: DownloadSDK не открывал ни одного ipc-канала, но интерфейсный процесс открывал

передний конец ipc

И имя процесса-обработчика, открытого Электроном, я проверил, оказалось, что оно все используется процессом Электрона, и это все процессы.

Тогда можно смело предположить: мультиоконность фронтенда реализована самодельным ipc каналом, а ipc это путь 1 сервера к N клиенту, то скорее всего сервер будет на главном окне , которая является предыдущей статьей Видя это и очевидный процесс основного рендеринга и просматривая его через консоль, верно, что метод net nodejs создает сервер и предоставляет объект с именем __xdasIPCServerInstance в глобальной среде для внешнего интерфейса. js, то есть jsapi.

В маленьком окне нет указанного выше экземпляра сервера, но есть соответствующий экземпляр клиента

Связь с DownloadSDK

Это выглядит очень странно. Интерфейсные процессы взаимодействуют через самодельный конвейер ipc, но у них нет никакого конвейера связи с DownloadSDK. Они оба подключены и не требуют пояснений? Ааа... программисты материалисты!

Итак, как проверить, как он взаимодействует с интерфейсным процессом? Поскольку внешний интерфейс предоставляет экземпляр SDK сервера, это означает, что DownLoadSDK должен быть представлен на нем как jsapi через прокси. Вы можете использовать [создать api задачи загрузки], чтобы следовать подсказкам. Глядя на экземпляр сервера в главном окне, действительно есть этот метод: createTask , который должен быть API-интерфейсом, используемым внешним интерфейсом для создания задач загрузки.

Неудобно искать код в браузере хрома, я переключился на vscode, чтобы посмотреть исходный код, искал позицию объявления функции createTask и увидел этот абзац (для контроля пробела, здесь часть кода удалена)

createTask(e, t) {
        return n(this, void 0, void 0, function* () {
          .....
          }
          switch (e) {
            case h.DownloadKernel.TaskType.P2sp:
              ...
            case h.DownloadKernel.TaskType.Bt:
             ...
            case h.DownloadKernel.TaskType.Emule:
             ...
            case h.DownloadKernel.TaskType.Group:
              ...
            case h.DownloadKernel.TaskType.Magnet:
             ...
            default:
              i = !1;
          }
          return (
            ...
            _.fireTaskEvent(h.DownloadKernel.TaskEventType.TaskCreated, [
          );
        });
      }

Он не запустился, что подтвердило мою предыдущую гипотезу.Этот __xdasIPCServerInstance является прокси-сервером, который инкапсулирует загрузку sdk во внешний интерфейс.

Продолжайте проверять, как обрабатывается этот fireTaskEvent, процесс чтения кода громоздкий, просто не упоминайте его, просто посмотрите на эти два куска кода (с удалениями и доработкой)

// 片段一
(e.getDownloadSdkVersion = function () {
  let e = a.join(__rootDir, "../bin/SDK/DownloadSDKServer.exe");
  return v.getFileVersion(e);
}),

// 片段二
y = l.default(o.join(__rootDir, "../bin/ThunderHelper.node"));
let F = "/ssdkver " + u.DownloadKernelManager.getDownloadSdkVersion();
B.push(F)
y.shellExecute(0, "open", o, B, H, "SW_SHOW");

Очевидно, что DownloadSDK запускается и передается через дополнительный модуль nodejs ThunderHelper.node.

Мы знаем, что nodejs может обеспечить совместное использование памяти с помощью ffi и других методов, чтобы достичь цели связи между двумя процессами без прохождения через каналы, такие как pipe/sock. Наблюдая за взаимосвязью вызова и обработкой Thunder.exe с помощью инструментов, связь между ними становится более ясной с первого взгляда: интерфейсный процесс Electron загружает процесс DownloadSDK и реализует его через канал памяти \Sessions\5\ Связь BaseNamedObjects\xx@22123720|SendShareMemory, дескрипторы находятся во взаимно однозначном соответствии.

Суммировать

После долгого времени я немного опустошен, в чем дело?

  • Отношения структуры кода Xunlei легкие для узла и тяжелые для внешнего интерфейса.Вся загрузка узла, управление процессами и многооконное взаимодействие размещаются в процессе главного окна внешнего процесса. Что касается этой практики, я уважаю, но не согласен с ней. Интерфейсный процесс не должен делать слишком много низкоуровневого взаимодействия, особенно однопоточный язык вроде js, который естественно неэффективен, а главное окно используется так часто, что не боится зависания.

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

  • Можно похвалить использование аддона узла для связи с DownloadSDK.Хотя это отраслевой стандарт (Feishu использует Rust, базовый принцип аналогичен), но бизнес, за который я сейчас отвечаю, этого не делает.Так что стыдитесь и дайте ему недурно

  • Версия Electron, используемая Thunder, — 9.2.1, и версия vscode также является этой версией, так здорово! Мне очень любопытно, почему промышленность использует эту версию.На самом деле, последняя версия электрона 9.x была обновлена ​​​​до 9.3.3 (28 октября 2020 г.) Есть ли в этой версии 9.2.1 какая-то магия, которая заставляет промышленность ее использовать ?

  • Вот примечание: Electron не поддерживает windows7 (не-sp1) и ниже, начиная с 6.0.

  • Я установил последнюю версию Thunder с помощью установщика Thunder в системе win7 и обнаружил, что электрон использует версию 1.8.6.

  • Переработан главный вход Electron.Программа Thunder.exe сделала много чего кроме запуска фронтенда.Эта кастомизация неплохая,потому что может управлять разными модулями процесса,и не будет множественного независимого процесса. Насколько я видел, многие приложения Electron не были настроены.

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

насчет нас

У нашего отдела есть несколько настольных приложений с большой пользовательской базой и большими задачами.Мы набираем экспертов с электронным опытом или передовыми технологиями. Я часто занимаюсь забавной настольной практикой, а также копаюсь и изучаю программирование приложений. Если вы заинтересованы, пожалуйста, свяжитесь со мной, пожалуйста, разбейте мое резюме! Личное сообщение мне для контактной информации! Вы можете общаться, возможно, вы станете коллегой, это не так сложно, как вы думаете!

Вы все еще помните, что я сказал в начале о сборе исходного кода Feishu? Хочу это увидеть? Отправьте свое резюме, если хотите, хахаха

Категории