メインコンテンツへ飛ぶ

Electron の舞台裏: 弱参照

· 読むのにかかる時間 1 分

ガベージコレクションがある言語 JavaScript は、ユーザーがリソースを手動で管理しなくてよくなります。 しかし、Electron はこの環境をホストしているため、メモリリークとリソースリークの両方を避けようと非常に慎重にならざるをえません。

この記事では、弱参照の概念と、それが Electron のリソース管理でどのように使われているかを紹介します。


弱参照

JavaScript でオブジェクトを変数に代入するというのは、必ずオブジェクトへの参照を追加していることになります。 オブジェクトへの参照がある限り、そのオブジェクトはずっとメモリに保持されます。 オブジェクトへのすべての参照がなくなる、例えばオブジェクトを格納する変数がなくなると、JavaScript エンジンは次のガベージコレクションでそのメモリを回収します。

弱参照とは、ガベージコレクションされるかどうかに影響せずオブジェクトを取得できるようにする参照です。 オブジェクトがガベージコレクションされたときにその通知もされます。 これにより、JavaScript でリソース管理を可能にします。

Electron の NativeImage クラスを例に挙げると、nativeImage.create() APIを呼び出すたびに NativeImage インスタンスが返され、これに画像データが C++ 側で格納されます。 インスタンスの処理が終わり JavaScript エンジン (V8) がオブジェクトをガベージコレクトしたら、C++ のコードが呼び出されてメモリ内の画像データが解放されるので、ユーザが手動で管理する必要はありません。

別の例としては、ウインドウ消失問題 があります。これはウインドウへの参照がすべてなくなったときにガベージコレクトされる様子を、視覚的に観察できます。

Electron での弱参照のテスト

生の JavaScript には弱参照を代入する方法がないので、弱参照を直接テストする方法はありません。 弱参照に関連する JavaScript の API だと WeakMap がありますが、これは弱参照のキーを作成するだけなので、オブジェクトがガベージコレクトされたかどうかは知ることができません。

v0.37.8 以前のバージョンの Electron では、内部の v8Util.setDestructor API を使用して弱参照をテストできました。以下のように、渡されたオブジェクトに弱参照を追加し、オブジェクトがガベージコレクションされたときにコールバックを呼び出すものです。

// 以下のコードは Electron < v0.37.8 でのみ実行できます。
var v8Util = process.atomBinding('v8_util');

var object = {};
v8Util.setDestructor(object, function () {
console.log('The object is garbage collected');
});

// オブジェクトへの参照を全て削除します。
object = undefined;
// GC を手動で起動します。
gc();
// コンソールに "The object is garbage collected" と出力されます。

注意としては、内部の gc 関数を公開させるために、--js-flags="--expose_gc" コマンドスイッチで Electron を起動する必要があります。

この API は後のバージョンで削除されました。このため V8 では実際にはデストラクタで JavaScript コードを実行できず、これをしようとしても確率でクラッシュします。

remote モジュールでの弱参照

C++ でネイティブリソースを管理する以外にも、Electron は JavaScript のリソースを管理するために弱参照が必要です。 例えば、Electron の remote モジュールはいわゆる Remote Procedure Call (RPC) モジュールで、レンダラープロセスからメインプロセス内のオブジェクトを使用できるようにます。

remote モジュールの重要な課題の 1 つに、メモリリークを避けるというものがあります。 ユーザがレンダラープロセス内のリモートオブジェクトを取得する場合、remote モジュールは、レンダラープロセス内の参照がなくなるまでオブジェクトがメインプロセスに存在し続けるよう保証しなければなりません。 さらに、レンダラープロセスでリモートオブジェクトへの参照がなくなったときに、そのオブジェクトがガベージコレクションされるようにする必要があります。

例えば、適切な実装を行わないと、以下のコードはすぐにメモリリークを起こしてしまいます。

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
remote.nativeImage.createEmpty();
}

remote モジュールのリソース管理は単純です。 オブジェクトの要求ごとにメインプロセスへメッセージが送信されます。それに対して Electron はオブジェクトをマップに保存して ID を割り当て、レンダラープロセスにその ID を送り返します。 レンダラープロセスでは、remote モジュールが ID を受け取ってプロキシオブジェクトでラップし、プロキシオブジェクトがガベージコレクションされると、オブジェクト解放のメッセージをメインプロセスに送信します。

remote.require API を例にすると、簡略化した実装は以下のようになります。

remote.require = function (name) {
// モジュールのメタデータを返すようにメインプロセスに伝えます。
const meta = ipcRenderer.sendSync('REQUIRE', name);
// プロキシオブジェクトを作成します。
const object = metaToValue(meta);
// プロキシオブジェクトがガベージコレクションされたときに
// オブジェクトの解放をメインプロセスに指示します。
v8Util.setDestructor(object, function () {
ipcRenderer.send('FREE', meta.id);
});
return object;
};

メインプロセスでは以下のようにします。

const map = {};
const id = 0;

ipcMain.on('REQUIRE', function (event, name) {
const object = require(name);
// オブジェクトへの参照を追加します。
map[++id] = object;
// オブジェクトをメタデータに変換します。
event.returnValue = valueToMeta(id, object);
});

ipcMain.on('FREE', function (event, id) {
delete map[id];
});

弱参照の辞書配列

先述の単純な実装では、remote モジュールを呼び出すたびにメインプロセスが新しいリモートオブジェクトを返し、各リモートオブジェクトがメインプロセスのオブジェクトへの参照を表します。

デザイン自体は問題ないのですが、同じオブジェクトを受信するために複数回呼び出すと、複数のプロキシオブジェクトが作成され、複雑なオブジェクトの場合にメモリ使用量とガベージコレクションを圧迫するという問題があります。

以下のようなコードがあったとします。

const { remote } = require('electron');

for (let i = 0; i < 10000; ++i) {
remote.getCurrentWindow();
}

まずプロキシオブジェクトを作成するためにメモリを多く使用し、そのガベージコレクションと IPC メッセージの送信に CPU(Central Processing Unit) を占有します。

明白な最適化としては、リモートオブジェクトのキャッシュがあります。すなわち、すでに同じ ID のリモートオブジェクトが存在する場合、新しいオブジェクトを作成するのではなく以前のリモートオブジェクトを返すようにします。

これは JavaScript コアの API ではできません。 通常の辞書配列を使ってオブジェクトをキャッシュすれば V8 によるオブジェクトのガベージコレクションを防げますが、WeakMap クラスではオブジェクトのみが弱参照のキーに使えます。

これを解決するために、値を弱参照として持つマップ型を追加しました。ID を持つオブジェクトのキャッシュに最適です。 これで、remote.require は以下のようになります。

const remoteObjectCache = v8Util.createIDWeakMap()

remote.require = function (name) {
// モジュールのメタデータを返すようにメインプロセスに伝えます。
...
if (remoteObjectCache.has(meta.id))
return remoteObjectCache.get(meta.id)
// プロキシオブジェクトを作成します。
...
remoteObjectCache.set(meta.id, object)
return object
}

注意として、remoteObjectCache はオブジェクトを弱参照として保管するので、オブジェクトがガベージコレクトされたときでもキーの削除は不要です。

ネイティブコード

Electron の弱参照の C++ コードに興味がある方は、以下のファイルを参照してください。

setDestructor API:

createIDWeakMap API:

2016 年 8 月号: 新しいアプリ

· 読むのにかかる時間 1 分

こちらは 8 月時点でサイトに追加された新しい Electron アプリです。


このサイトは、コミュニティからの プルリクエスト を経て新しい アプリ交流会 に更新されます。 レポジトリを Watch すれば新しい追加の通知を受け取ることができます。全て のサイトの変更に関心がない場合は、ブログ RSS フィード に登録してください。

Electron アプリを作成したり、交流会を開催したりしている場合、プルリクエスト を作成するとサイトに追加して次のまとめに載ります。

新しいアプリ

Code RPGifyRPG スタイルコーディングアプリケーション
PamFaxFAX を送受信するクロスプラットフォームアプリ
BlankUpすっきり度 +1 の Markdown エディタ
Rambox一般のウェブアプリケーションを 1 つにする、無料でオープンソースのメッセージング & メールアプリ
Gordieカードコレクションに最適なアプリ
Ionic Creator綺麗なモバイルアプリを、素早く構築
TwitchAlerts美麗なアラートと通知で視聴者を笑顔に
Museeksシンプル、クリーン、クロスプラットフォームな音楽プレーヤー
SeaPigMarkdown から HTML へのコンバータ
GroupMeGroupMe 非公式アプリ
Moeditor汎用 Markdown エディター
SoundnodeSoundnode アプリはデスクトップ向け Soundcloud です
QMUI WebQMUI ウェブデスクトップは、QMUI ウェブフレームワークをベースにプロジェクト管理をするアプリケーションです
SvgsusSVG の整理、整頓、変換
Ramme非公式 Instagram デスクトップアプリ
InsomniaREST API クライアント
CorreoWindows、macOS、Linux 向けメニューバー/タスクバー Gmail アプリ
KongDashKong Admin API のデスクトップクライアント
Translation EditorINTL ICU メッセージの翻訳ファイルエディター (formatjsio を参照)
5EClient5EPlay CSGO クライアント
Theme Juiceローカルの WordPress 開発を簡単に

アクセシビリティツール

· 読むのにかかる時間 1 分

アクセシビリティの高いアプリケーションを作ることは重要です。開発者がすべてのユーザ向けのより良いアプリケーション開発を手助けする新機能 DevtronSpectron を紹介します。


Electron アプリケーションのアクセシビリティに関する懸念は、どちらも最終的に HTML であるため、ウェブサイトと同様です。 しかし、Electron アプリケーションでは、アプリケーションに監査機を指す URL がないため、アクセシビリティ監査にオンラインリソースを使用することはできません。

これらの新機能は、監査ツールを Electron アプリに提供します。 Spectron でテストに監査を追加するか、開発者向けツール内で Devtron で監査を使用するかを選択できます。 詳細は、ツールの概要を読むか アクセシビリティドキュメント をご覧ください。

Spectron

Spectron テストフレームワークで、アプリケーション内の各ウィンドウと <webview> タグを監視できます。 以下がその例です。

app.client.auditAccessibility().then(function (audit) {
if (audit.failed) {
console.error(audit.message);
}
});

この機能の詳細は Spectron のドキュメント にて閲覧できます。

Devtron

Devtronでは新機能のアクセシビリティタブが利用できます。このタブでは、アプリケーション内の監視結果をソートしたり、フィルタによって絞り込んだりできます。

devtron スクリーンショット

いずれのツールも Google が Chrome 向けに開発した Accessibility Developer Tools ライブラリを利用しています。 このライブラリが使用しているアクセシビリティ監査のルールに関する詳細は、リポジトリの wiki に記載されています。

これ以外の Electron 向けに使用可能な素晴らしいアクセシビリティツールをご存じの方は、 ぜひアクセシビリティに関するドキュメント に追加してプルリクエストをお送りください。

npm install electron

· 読むのにかかる時間 1 分

Electron バージョン 1.3.1 では、 npm install electron --save-dev とすればコンパイル済みの Electron をアプリにインストールできます。


npm install electron

ビルド済み Electron ライブラリ

Electron アプリの開発経験があれば、おそらく electron-prebuilt npm パッケージを触ったことがあるでしょう。 このパッケージはほぼすべての Electron プロジェクトにおいて不可欠なものです。 インストールされると、オペレーティングシステムを検出し、ビルド済みバイナリの中からそのシステムアーキテクチャに適したものをダウンロードします。

新しい名前

Electron のインストール過程は、新規開発者にとっての壁となりがちでした。 多くの勇敢な人々が、npm install electron-prebuilt ではなく npm install electron を実行して Electron アプリの開発を始めようとしたところ、(多くの場合、混乱の末に) それが探していた electron ではないことに気づいたでしょう。

これは、 GitHub の Electron プロジェクトが作られる前から electron プロジェクトが npm に存在していたためです。 Electron での開発がより簡単で直感的になるよう、私たちは既存の electron の所有者に連絡を取り、名前を使わせてもらえないかを交渉しました。 幸い、彼は私たちのプロジェクトに賛同しており、名前の再利用に協力して下さいました。

Prebuilt との営み

バージョン 1.3.1 では、electronelectron-prebuilt のパッケージを npm に同時公開するようになりました。 2 つのパッケージは同じです。 現在プロジェクトで electron-prebuilt を使用している数多の開発者のために、しばらくの間、両方の名前でパッケージを公開することを決めました。 新しい electron に依存するように package.json ファイルを更新することを推奨しますが、 2016 年末までは新しいバージョンの electron-prebuilt もリリースされます。

electron-userland/electron-prebuiltelectron npm パッケージに対する正規のホームリポジトリとして残ります。

謝辞

@mafintosh には特別な感謝を捧げます。 @maxogden をはじめとする多くの 貢献者の方々 には、electron-prebuilt の作成と保守、そして JavaScript、Node.js、Electron コミュニティへのたゆまぬご協力に感謝します。

そして npm で electron パッケージを引き取らせてくれた @logicalparadox に感謝します。

プロジェクトの更新

この変更に影響される人気のパッケージを更新するために、コミュニティと協力してきました。 electron-packagerelectron-rebuildelectron-builder のようなパッケージは、古い名前をサポートしつつ、既に新しい名前で動作するように更新されています。

新しいパッケージをインストールするときに何らかの問題が発生した場合、 electron-userland/electron-prebuilt リポジトリに Issue を開いてお知らせください。

Electron に関する他の問題については、 electron/electron リポジトリを使用してください。

Electron の舞台裏: Node をライブラリとして使用する

· 読むのにかかる時間 1 分

Electron の舞台裏について説明するシリーズ、第二弾です。 イベントループの統合についてまだ読んでいない方は 最初の記事 をご覧ください。

ほとんどの人は Node をサーバサイドアプリケーションに使っていますが、Node の豊富な API セットと活発なコミュニティのおかげで組み込みライブラリにも最適です。 この記事では、Electron のライブラリとして Node がどのように使われているかを解説します。


ビルドシステム

Node も Electron も GYP をビルドシステムとして使用しています。 アプリ内に Node を埋め込みたい場合は、あなたもビルドシステムとして GYP を使用する必要があります。

GYP は初めてですか? そうであれば、この記事を読み進める前に このガイド を読んでからにしてください。

Node のフラグ

Node のソースコードディレクトリにある node.gyp ファイルには、Node をどのように構築するかが記述されており、多くの GYP 変数とともに Node のどの部分を有効にするのか、特定の設定ファイルを開くかどうかを制御しています。

ビルドフラグを変更するには、プロジェクトの .gypi ファイルに変数を設定する必要があります。 Node の configure スクリプトは、いくつかの一般的な設定ファイルを生成できます。例えば、./configure --shared を実行すると、Node を共有ライブラリとしてビルドするように指示する変数を含んだ config.gypi が生成されます。

Electron は独自のビルドスクリプトを持っているので、この configure スクリプトは使いません。 Node の設定は、Electron のルートソースコードディレクトリにある common.gypi ファイルで定義されています。

Electron と Node のリンク

Electron では、GYP 変数 node_sharedtrue に設定することで Node を共有ライブラリとしてリンクしています。このため、Node のビルドタイプは executable から shared_library に変更され、Node の main エントリポイントを含むソースコードはコンパイルされません。

Electron は Chromium に同梱されている V8 ライブラリを使用しているため、Node のソースコードに含まれている V8 ライブラリは使用しません。 これは node_use_v8_platformnode_use_bundled_v8 の両方を false に設定することで実現しています。

共有ライブラリか静的ライブラリか

Node とリンクする際には 2 つの選択肢があります。静的ライブラリとしてビルドし最終的な実行ファイルにインクルードするか、共有ライブラリとしてビルドし最終的な実行ファイルと一緒に頒布するかです。

Electron では、Node は長い間静的ライブラリとしてビルドしていました。 これはビルドがシンプルで、高水準なコンパイラの最適化が可能で、余分な node.dll ファイルいらずで Electron を頒布できました。

しかし、これは Chrome が BoringSSL を使うようになってから変わりました。 BoringSSL は OpenSSL のフォークで、いくつかの未使用の API を削除し、多くの既存のインターフェースを変更しています。 Node は依然 OpenSSL を使用しているため、コンパイラがそれらをリンクすると、矛盾するシンボルのために多数のリンクエラーを発生させてしまいます。

Electron では、Node で BoringSSL を使うことも Chromium で OpenSSL を使うこともできませんでした。そのため、Node を共有ライブラリとしてビルドするように切り替え、BoringSSL と OpenSSL のシンボルをそれぞれのコンポーネントで隠す という選択肢しかありませんでした。

この変化は、Electron にいくぶんかプラスの副作用をもたらしました。 この変更以前は、Windows 上でネイティブモジュールを使用している場合、インポートライブラリ内で実行ファイル名をハードコーディングしていたため、実行ファイル名を変更できませんでした。 Node が共有ライブラリとして構築されてからは、すべてのネイティブモジュールを node.dll にリンクしたため、この制限がなくなりました。

ネイティブモジュールのサポート

Node のネイティブモジュール は、Node がロードするエントリ関数を定義し、Node から V8 や libuv のシンボルを検索することで動作します。 これは組み込み開発者にとっては少し面倒です。なぜなら、デフォルトではライブラリとして Node をビルドする際に V8 と libuv のシンボルが隠されており、ネイティブモジュールはシンボルを見つけられずロードに失敗するからです。

そこで、ネイティブモジュールを動作させるために Electron では V8 と libuv のシンボルを公開しました。 V8 では、Chromium の設定ファイル内の全シンボルを強制的に公開する ことで実現しています。 libuv の場合、BUILDING_UV_SHARED=1 定義を設定する ことで実現しています。

アプリで Node を起動する

Node をビルドしてリンクする全作業の後は、最後の段階としてアプリで Node を実行します。

Node は、自分自身を他のアプリに組み込むための公開 API は多く提供していません。 通常は、node::Startnode::Init を呼び出すだけで Node の新しいインスタンスを起動できます。 しかし、Node ベースで複雑なアプリを構築する場合は、node::CreateEnvironment のような API を使用して全ステップを正確に制御する必要があります。

Electron で Node を起動する際には、公式の Node バイナリに近いメインプロセスで動作するスタンドアロンモードと、ウェブページに Node API を挿入する組み込みモードの、2 つのモードがあります。 この詳細は後々の記事で解説する予定です。

2016 年 7 月号: 新しいアプリと交流会

· 読むのにかかる時間 1 分

Electron コミュニティでの活動を強調するために、月刊のまとめを始めます。 各まとめには、新しいアプリ、今後の交流会、ツール、映像などが掲載されます。


このサイトはコミュニティからのプルリクエスト を通して新しい アプリ交流会 で更新されます。 レポジトリを Watch すれば新しい追加の通知を受け取ることができます。全て のサイトの変更に関心がない場合は、ブログ RSS フィード に登録してください。

Electron アプリを作成したり、交流会を開催したりしている場合、プルリクエスト を作成するとサイトに追加して次のまとめに載ります。

新しいアプリ

Demioインバウンドセールスとマーケティング向けに制作されたオンラインセミナープラットフォーム
ElectorrentuTorrent サーバー用リモートクライアントアプリ
PhoneGapウェブ技術で綺麗なモバイルアプリを作れるオープンソースフレームワーク
WordMarkMarkdown ライター向けの軽量ブログ記事エディター
UbAuthOAuth 2.0 による Uber アプリケーションのアクセストークン作成をする開発者支援アプリ
HyperTermHTML/JS/CSS ターミナル
MarpMarkdown プレゼンライター
Glyphr Studio趣味でフォントデザインをしている人に焦点を当てた、無料でウェブベースのフォントデザイナー
BitCryptWindows 向けのシンプルなファイル暗号化アプリケーション
TrymSVG アイコンの表示、最適化、変換に役立つ macOS 向けの綺麗で小さなアプリ
BookerMarkdown を活かすテキストエディタ
PhonePresenter賢いプレゼン操作リモコン
Youtデスクトップで YouTube のプレイリストを見る新しい方法

新しい交流会

Electron オープンソースデスクトップフレームワークイギリスのロンドン

Electron の舞台裏: メッセージループの統合

· 読むのにかかる時間 1 分

Electron の舞台裏について説明するシリーズ、第一弾です。 この投稿では、 Electron が Node のイベントループをどのように Chromium と統合しているかを紹介します。


これまで、Node を GUI プログラミングに使う試みは数多くありました。GTK+ のバインディングでは node-gui が、 Qt のバインディングでは node-qt があります。 しかし、GUI ツールキットは独自のメッセージループを持っているにもかかわらず、Node は独自のイベントループに libuv を使用しています。メインスレッドは同時に 1 つのループしか実行できないため、本番環境ではどちらも動作しません。 そのために、Node で GUI のメッセージループを共通化して実行するための仕掛けとして非常に短い間隔のタイマーでメッセージループをポンピングすると、GUI のレスポンスが遅くなり、多くの CPU リソースを占有してしまいます。

Electron の開発中にも同じ問題が発生しましたが、 Node のイベントループを Chromium のメッセージループに統合するという、逆の方法を取りました。

メインプロセスとレンダラープロセス

メッセージループの統合についての詳細の前に、 Chromium のマルチプロセスアーキテクチャについて説明します。

Electron には、メインプロセスとレンダラープロセス、2 種類のプロセスがあります (これはとても単純化してあります。詳細は マルチプロセスアーキテクチャ を参照してください)。 メインプロセスはウインドウの作成など GUI が動作するための責務を担い、レンダラープロセスはウェブページの実行とレンダリングだけを行います。

Electron では JavaScript を使ってメインプロセスとレンダラープロセスの両方を制御できるように、両方のプロセスに Node を統合する必要があるのです。

Chromium のメッセージループを libuv に置換

最初の試みは、 Chromium のメッセージループを libuv で再実装することでした。

レンダラープロセスは、メッセージループはファイル記述子とタイマーだけをリッスンしていたので簡単でした。

しかし、メインプロセスではとても困難でした。 各プラットフォームは独自の GUI メッセージループを持ちます。 macOS の Chromium は NSRunLoop を使う一方、 Linux では glib を使います。 ネイティブ GUI のメッセージループからファイル記述子を抽出して libuv の繰り返しに与えるために多くのハックを試みましたが、それでもうまくいかないエッジケースに遭遇しました。

最終的に、短い間隔で GUI メッセージループをポーリングするタイマーを追加しました。 この結果、プロセスは一定の CPU 使用率を消費し、操作によっては長い遅延が発生してしまいました。

別のスレッドで Node のイベントループをポーリング

libuv が成熟するにつれて、別のアプローチができるようになりました。

libuv にバックエンドファイル記述子の概念が導入されました。これは libuv がイベントループのためにポーリングするファイル記述子 (またはハンドル) です。 バックエンドファイル記述子をポーリングすることで、 libuv で新しいイベントが発生したときに通知を受けられるようになりました。

そこで Electron では、バックエンドファイル記述子をポーリングするために別のスレッドを作成しました。これは libuv API の代わりにシステムコールでポーリングしていたのでスレッドセーフでした。 そして、 libuv のイベントループで新しいイベントがあるとき、メッセージが Chromium のメッセージループに送信され、 libuv のイベントはメインスレッドで処理されるようになりました。

このようにして、 Chromium や Node にパッチを当てることを避けつつ、メインプロセスとレンダラープロセスで同じコードを使用できました。

コード

メッセージループの統合の実装は electron/atom/common/ 下の node_bindings ファイルで見ることができます。 これは Node を統合したいプロジェクトでも簡単に再利用できます。

更新: 実装を electron/shell/common/node_bindings.cc に移動しました。

Electron の Podcast

· 読むのにかかる時間 1 分

Electron のはじめかたをお探しですか? リリースされたばかりの 2 つの新しい Podcast を、どういうもので、なぜ作られたか、どうやって使うのかについて、その概要をお教えします。


現在、こういったものがあります。

Hanselminutes: クロスプラットフォームの Electron アプリを作る

Electron は "ただのフレーム内のChrome" なのか、それともそれ以上のものなのか? Jessica が Scott を導く形で、Electron プラットフォームが開発業界のどこに適合するのかを的確に説明します。


JavaScript Air: Electron アプリ

Electron は、ウェブ技術を使用してマルチプラットフォームのデスクトップアプリを作成する、妥当で人気な方法の一つになりつつあります。 このすばらしい技術に参加して、Electron を使ってデスクトップでの開発者のエクスペリエンスとユーザのエクスペリエンスを強化する流れを見てみましょう。


Electron のはじめかたをお探しの方は、最初のものを試してみてください。 2 つ目は、Nylas の Evan Morikawa による素晴らしい助言と共にアプリ構築について詳しく説明しています。

現在、来月公開予定の 2 つのポッドキャストに取り組んでいます。最新情報は Twitter アカウント @ElectronJS でお知らせします。

Electron 1.0

· 読むのにかかる時間 1 分

過去2年間、Electron は HTML、CSS、JavaScript を使用したクロスプラットフォームのデスクトップアプリケーション開発を支援してきました。 私たちのフレームワークと、それを作成したコミュニティで大きな節目を共にできるということで興奮しています。 Electron 1.0 のリリースは electronjs.org からご覧いただけます。


Electron 1.0

Electron 1.0 は、API の安定性と成熟度における大きな節目です。 このリリースでは Windows、Mac、Linux 上で真にネイティブに近い動作のアプリを構築できます。 新しいドキュメント、新しいツール、新しい Electron API 概略アプリにより、Electron アプリの構築がこれまで以上に簡単になりました。

初めての Electron アプリを素早く構築するには クイックスタートガイド を参照してください。

Electron で次に何を作るのか、楽しみにしています。

Electron の道のり

私たちは 2 年と少し前に Atom を立ち上げた時に Electron をリリースしました。 当初 Atom Shell という名前だった Electron は、Atom のために構築したフレームワークでした。 当時の Atom は Electron が提供する特色と機能性のきっかけを生み、Atom の初期リリースを後押ししていました。

いま Electron を突き動かしているのは、メールチャットGit アプリ から、SQL 分析ツールtorrent クライアントロボット まで、あらゆる開発者や企業のコミュニティの成長です。

この 2 年間、企業とオープンソースプロジェクトの両方で、アプリケーション基盤として Electron が採用されています。 この 1 年間で、Electron は 120 万回以上ダウンロードされています。 素晴らしい Electron アプリを こちらでご紹介 します。 あなたのアプリがまだない場合は追加しましょう。

Electron のダウンロード数

Electron API デモ

1.0 のリリースに合わせて、Electron API を調べたり、Electron アプリをネイティブ風にする方法の詳細を学べる新アプリをリリースします。 1.0 のリリースに合わせて、Electron API を調べたり、Electron アプリをネイティブ風にする方法の詳細を学べる新アプリをリリースします。

Electron API デモ

Devtron

Electron アプリのデバッグに役立つ新しい拡張機能も追加しました。 Devtron はオープンソース拡張機能です。 Chrome デベロッパー ツール の拡張で、Electron アプリのインスペクト、デバッグ、トラブルシューティングを支援する設計です。

Devtron

機能

  • Require グラフ は、メインプロセスとレンダラープロセス両方の、アプリの内部と外部ライブラリとの依存関係の視覚化に役立ちます。
  • IPC モニタ は、アプリ内のプロセス間で送受信されたメッセージを追跡して表示します。
  • イベントインスペクタ は window、app、process などのコア Electron API にアプリが登録しているイベントやリスナーを表示します。
  • アプリリンター はあなたのアプリのよくある間違いや機能の欠損をチェックします。

Spectron

最後に、Electron アプリの統合テストフレームワーク Spectron の新バージョンをリリースします。

Spectron

Spectron 3.0 は Electron API 全体を包括的にサポートするため、さまざまなシナリオや環境でアプリケーションを動作検証するテストを、より迅速に記述できます。 Spectron は ChromeDriverWebDriverIO をベースにしているため、ページナビゲーション、ユーザー入力、JavaScript 実行といった API も備えています。

コミュニティ

Electron 1.0 は、何百人もの開発者によるコミュニティの努力の成果です。 コアフレームワーク以外では、Electron アプリの構築、パッケージ、デプロイを容易にするライブラリやツールが何百とリリースされています。

新しい コミュニティ ページでは、開発中の素晴らしい Electron のツール、アプリ、ライブラリ、フレームワークを多数掲載しています。 ElectronElectron Userland といった Organization を覗けば、こういった素晴らしいプロジェクトをいくつか見られます。

Electron は初めてですか? Electron 1.0 の紹介ビデオはこちらです。

Electron 0.37 の新機能

· 読むのにかかる時間 1 分

Electron 0.37 が先日 リリースされました。Chrome 47 から Chrome 49 へのメジャーアップグレードと、いくつかの新しいコア API が入っています。 この最新リリースでは、Chrome 48Chrome 49 に搭載されているすべての新機能が搭載されています。 これにより、CSS カスタムプロパティ、ES6 サポートの強化、KeyboardEvent の改善、Promise の改善、その他多くの新機能が Electron アプリで利用可能になります。


新機能

CSS カスタムプロパティ

Sass や Less のようなプリプロセス言語を使用したことがある方は 変数 に慣れていると思いますが、これを用いてカラースキームやレイアウトなどの再利用可能な値を定義できます。 変数は、スタイルシートを DRY に保ちメンテナンス性を高めるのに役立ちます。

CSS カスタムプロパティは、再利用可能という点ではプリプロセスでの変数に似ていますが、JavaScript で操作できる という更に強力で柔軟性の高い独自性があります。 この小さいながらも強力な機能により、 CSS ハードウェアアクセラレーション の恩恵を受けながら、ビジュアルインターフェイスに動的な変更を加えられ、フロントエンドコードとスタイルシートとの間でコードの重複を減らせます。

CSS カスタムプロパティの詳細は、MDN の記事Google Chrome のデモ を参照してください。

CSS 変数の動作

シンプルな変数の例として、アプリ内での実行時の変更を見ていきましょう。

:root {
--awesome-color: #a5ecfa;
}

body {
background-color: var(--awesome-color);
}

変数の値は直接 JavaScript で取得や変更ができます。

// 変数の値 '#A5ECFA' を取得
let color = window
.getComputedStyle(document.body)
.getPropertyValue('--awesome-color');

// 変数の値を 'orange' に設定
document.body.style.setProperty('--awesome-color', 'orange');

変数の値は、デベロッパー ツールの Styles セクションからも編集でき、素早いフィードバックと微調整ができます。

Styles タブの CSS プロパティ

KeyboardEvent.code プロパティ

Chrome 48 では、新しい code プロパティが KeyboardEvent イベントで利用できるようになりました。これは、オペレーティングシステムのキーボードレイアウトとは独立した、押された物理キーです。

これにより、Electron アプリにカスタムキーボードショートカットを実装する際に、マシンや構成の違いに影響されずに正確で一貫性のあるキーボードショートカットを実装できるようになります。

window.addEventListener('keydown', function (event) {
console.log(`${event.code} was pressed.`);
});

こちらのサンプル で実際にどうなるのか確認できます。

Promise 拒否イベント

Chrome 49 では、拒否された Promise が処理されなかった場合に通知される window のイベントを 2 つ追加しました。

window.addEventListener('unhandledrejection', function (event) {
console.log('A rejected promise was unhandled', event.promise, event.reason);
});

window.addEventListener('rejectionhandled', function (event) {
console.log('A rejected promise was handled', event.promise, event.reason);
});

こちらのサンプル で実際にどうなるのか確認できます。

V8 での ES2015 アップデート

現在、Electron に入っている V8 のバージョンでは、ES2015 の 91% を取り入れています。 ここでは、フラグやプリコンパイラ要らずですぐに使える面白い追加機能をいくつか紹介します。

デフォルト引数

function multiply(x, y = 1) {
return x * y;
}

multiply(5); // 5

分割代入

Chrome 49 で 分割代入 が追加され、変数や関数パラメータの代入が非常に簡単になりました。

これにより、Electron の require はより簡潔でコンパクトな代入になりました。

ブラウザプロセスの Require
const { app, BrowserWindow, Menu } = require('electron');
レンダラープロセスの Require
const { dialog, Tray } = require('electron').remote;
その他の例
// 配列を分割して 2 つ目の要素を飛ばす
const [first, , last] = findAll();

// 関数の仮引数の分割
function whois({ displayName: displayName, fullName: { firstName: name } }) {
console.log(`${displayName} is ${name}`);
}

let user = {
displayName: 'jdoe',
fullName: {
firstName: 'John',
lastName: 'Doe',
},
};
whois(user); // "jdoe is John"

// オブジェクトの分割代入
let { name, avatar } = getUser();

新しい Electron API

以下にいくつかの新しい Electron API を示します。それぞれの新しい API は、Electron リリース のリリースノートで確認できます。

BrowserWindowshow イベントと hide イベント

これらのイベントは、ウインドウが表示や非表示になったときにそれぞれ発生します。

const { BrowserWindow } = require('electron');

let window = new BrowserWindow({ width: 500, height: 500 });
window.on('show', function () {
console.log('Window was shown');
});
window.on('hide', function () {
console.log('Window was hidden');
});

OS X 向けに appplatform-theme-changed

このイベントは、システムの ダークモード テーマが切り替えられたときに発生します。

const { app } = require('electron');

app.on('platform-theme-changed', function () {
console.log(`Platform theme changed. In dark mode? ${app.isDarkMode()}`);
});

OS X 向けに app.isDarkMode()

このメソッドは、システムがダークモードの場合は true を返し、それ以外では false を返します。

OS X 向けに BrowserWindow の scroll-touch-begin イベントと scroll-touch-end イベント

これらのイベントは、スクロールホイールイベントフェイズの開始や終了でそれぞれ発生します。

const { BrowserWindow } = require('electron');

let window = new BrowserWindow({ width: 500, height: 500 });
window.on('scroll-touch-begin', function () {
console.log('Scroll touch started');
});
window.on('scroll-touch-end', function () {
console.log('Scroll touch ended');
});