Electron

長年にわたり、ソフトウェア開発コミュニティでは「Electron対ネイティブ」という激しい議論が繰り広げられてきました。Visual Studio Code、Slack、Discord、Teamsなどの現代のデスクトップソフトウェアの巨人は、Web技術を使用してクロスプラットフォームのデスクトップアプリを構築できるフレームワークであるElectronの上に構築されています。 同時に、ユーザーも開発者も、Electronアプリが「肥大化している」「動作が遅い」「RAMを大量に消費する」と頻繁に不満を漏らしています。その一方で、ターゲットのオペレーティングシステム向けに特別に記述されたネイティブアプリケーション（macOS向けには Swift/Objective-C、Windows/Android向けには Kotlin/C#、Linux向けには C++/Qtを使用）が存在します。 では、パフォーマンスの差は本物なのでしょうか？それとも誇張なのでしょうか？この記事では、両方のアプローチのアーキテクチャ、メモリ使用量、起動時間、リソースの占有領域を深く掘り下げて明らかにします。 1. アーキテクチャの青写真：核心的な違い パフォーマンスのギャップを理解するには、まずこれらのアプリケーションが内部でどのように実行されているかを見る必要があります。 Electron：箱の中のWebブラウザ Electronアプリケーションは、本質的にChromium（Google Chromeの背後にあるオープンソースブラウザ）のパッケージ化されたインスタンスとNode.jsランタイムの組み合わせです。 メインプロセスがNode.js環境を実行し、アプリケーションのライフサイクルとシステム操作を管理します。 レンダラープロセスがChromiumインスタンスを実行し、Webページと同じようにユーザーインターフェイスをレンダリングします。 つまり、単一のElectronアプリケーションを実行すると、Webブラウザとバックエンドサーバーを同時に実行していることになります。 ネイティブ：ハードウェアと直接対話する ネイティブアプリケーションは、機械語に直接コン파일されるか、オーバーヘッドを最小限に抑えて動作する最適化された仮想マシン（JVMや.NET CLRなど）をターゲットにします。ブラウザコンテナ内でHTMLをレンダリングする代わりに、OS独自のUIレンダリングエンジン（macOSのCocoaやWindowsのWinUIなど）を使用します。 2. メモリ消費（RAMをめぐる議論） Electronに対する最も一般的な批判は、そのメモリ使用量です。この違いは100%本物であり、測定可能です。 Electronの基準値： 空白の、初期化したばかりのElectronアプリケーションは、通常 80MB〜120MBのRAM を消費します。これは、UIの1ピクセルを表示する前に、Chromiumのレンダリングエンジン、JavaScriptエンジン（V8）、Node.jsをメモリにロードする必要があるためです。 ネイティブの基準値： Swift（macOS用）またはC++（Windows用）で構築されたネイティブのデスクトップアプリケーションは、10MB〜15MB未満のRAM で簡単に起動して実行できます。 これを日常的な使用にスケールアップすると、3つまたは4つのElectronアプリ（Slack、Discord、VS Code、Spotifyなど）を実行するだけで、ランタイムをアクティブに保つためだけに 1.5GB〜2GBのRAM を簡単に消費してしまいます。8GB RAMのユーザーにとって、これは重大なパフォーマンスのボトルネックになります。 3. 起動時間と実行速度 コールドブート速度 Electronはブラウザエンジンを起動し、Node.jsコンテキストを初期化する必要があるため、顕著な「コールドブート」遅延が発生します。この起動時間は通常 1〜3秒 かかります。そのようなランタイム初期化のオーバーヘッドがないネイティブアプリケーションは、ほぼ瞬時に（多くの場合 100〜300ミリ秒 で）起動します。 実行とCPUオーバーヘッド Chromiumは、GoogleのV8エンジンを使用して、JavaScriptをJust-In-Time（JIT）で機械語にコンパイルします。V8はJavaScriptエンジンとしては非常に高速ですが、事前にコンパイルされた（AOT）ネイティブコード（C++やSwiftなど）の生の速度には及びません。 さらに、Electronはガベージコレクションを伴う言語（JavaScript）に依存しているため、ガベージコレクタが未使用のメモリをクリーンアップするときに、ユーザーは時折マイクロスタッター（微小なカクつき）を経験することがあります。C++のようなネイティブ言語は手動のメモリ管理を使用し、Swiftは自動参照カウント（ARC）を使用するため、どちらもガベージコレクションによる一時停止を回避できます。 4. パッケージサイズ（ディスク容量のフットプリント） アプリケーションインストーラーのサイズも、もう1つの対照的な要素です。 Electron： すべてのElectronアプリはChromiumとNode.jsを同梱する必要があるため、最小ダウンロードサイズは約 50MB〜80MB で、ディスク上では 150MB 以上に展開されます。 ネイティブ： ネイティブアプリケーションはOSの組み込みライブラリを使用するため、ランタイムを同梱する必要がありません。完全に機能するネイティブのユーティリティプログラムは、簡単に 5MB 未満に抑えることができます。 5. ネイティブが優れているなら、なぜElectronはこれほど人気があるのか？ これほど多くのパフォーマンスの欠点があるにもかかわらず、なぜ業界の巨人は依然としてElectronを選択するのでしょうか？

Electron は、HTML、CSS、JavaScript といった Web 技術を使用して、クロスプラットフォームのデスクトップアプリケーションを開発するための最も人気のあるフレームワークの 1 つです。内部的には、Node.js を実行する メインプロセス（Main Process） と、UI を描画するために Chromium を実行する 1 つ以上の レンダラープロセス（Renderer Process） からなるマルチプロセスアーキテクチャを採用しています。 セキュリティ上のリスクを排除するため、モダンな Electron アプリケーションでは、レンダラープロセスをオペレーティングシステムから隔離しています。つまり、レンダラーの UI から直接 Node.js モジュールやシステムリソース（ファイルの読み込みやデータベースへのクエリなど）にアクセスすることはできません。 このギャップを安全に埋めるために、Electron は プロセス間通信（IPC: Inter-Process Communication） を利用しています。 本ガイドでは、Electron の IPC がどのように動作するのかを解説し、本番環境でそのまま使用できる実用的なコード例とともに、3 つの基本的な通信パターンを紹介します。 1. レンダラープロセスからメインプロセスへ（単方向 / One-Way） このパターンは、レンダラーがレスポンスを待つことなく、メインプロセスにコマンドやアクションを送信したい場合に使用されます。一般的な例としては、UI 上のボタンをクリックしてアプリケーションウィンドウを最小化または閉じる操作が挙げられます。 これらが 3 つの主要なファイル（main.js、preload.js、renderer.js）でどのように実装されるかを見てみましょう。 メインプロセス (main.js) レンダラープロセスからのイベントを監視するために ipcMain.on を使用します。 const { app, BrowserWindow, ipcMain } = require('electron'); const path = require('path'); function createWindow() { const win = new BrowserWindow({ width: 800, height: 600, webPreferences: { preload: path.join(__dirname, 'preload.js'), contextIsolation: true, nodeIntegration: false } }); win.loadFile('index.html'); } // レンダラーからの 'close-app' イベントを購読 ipcMain.on('close-app', () => { app.quit(); }); プリロードスクリプト (preload.js) ipcRenderer モジュール全体をレンダラーに露出させるのではなく、contextBridge.exposeInMainWorld を使って安全なラッパー関数のみを露出させます。