9/30に開催されたGeckoと仲良くなりたい人主催 FxOS Gecko勉強会のざっくりまとめです。
各プレゼンの資料はFirefox OS(モバイルクリエイターズ(仮))の「2013/9/30 Geckoと仲良くなりたい人主催 FxOS Gecko勉強会」から辿れます。
会場は六本木のMozillaさんのオフィスでした。
Gecko入門
概要
Q. なぜ今Gecko勉強会なのか？
A. 前回の勉強会でにしむねあさんがやろうと言ったので。
ソースコードベースの話になるので、皆さんが調べるときの参考にもなるのでは。
Geckoは「Firefox OS」を理解する上で避けては通れない。
Web技術との接点。
WebベースのOS
Firefox OSとChrome OSはいずれもブラウザベースで、Web標準技術が中心。
Androidが登場した頃は、まだHTML（HTML5）をベースとするのは早すぎた。
なのでAndroidは、ユーザに一番近いところでJava（）を使っていた。
Chrome OSは、Androidと同じところ（モバイル）を狙うと共食いになるのでラップトップを狙った。
Firefox OSの場合、既にAndroidが登場していて、そこに市場があった。
Firefox OSが展開する市場はモバイル／ローレンジ。
Firefox OSはOSの上にブラウザが直接載ったシンプルな構成（中間のレイヤがない）なので、HTML5の動作という意味ではAndroidに比べて格段にパフォーマンスが得やすい構成となっている。
ベースのアーキテクチャの復習
Gaia、Gecko、Gonk。
GaiaはUIとか。
今回のテーマであるGeckoは、Web標準を支える実装がすべて入っている。
レイアウト、JavaScriptエンジン、ネットワーク、グラフィックスタック。ブラウザそのもの。
GonkはLinuxとの差を吸収する層。
init.rc（initプロセス）のところが特徴。
ソースの取得
git cloneしてチェックアウト。
（具体的なコマンドはスライドの12ページを参照）
./config.sh galaxy-nexus」はリポジトリが死んでいた。
（Mozillaの浅井さん補足）
firefox OSの開発者は、今はNexus 4を使って開発している。
なので、1.2以降はNexus 4で動かすのが安定している。
（ここまで補足）
B2G/の構成
概ねAndroidと同様。
Firefox OSで追加されたディレクトリはgaia、geckoなど。
Firefox OSで不要なコードは削られている。
toolsには手が入っていた。
下回り（ハードウェア制御とかに近い方）はgonk-miscにガバッと入っている。
メディア関係はframeworksに入っている。
B2G/gecko/の構成
geckoディレクトリは中に64個も入っていた。
全部確認するのは諦めた。（補足：ひだかさんがソース確認に着手したのは前日の夜中）
geckoディレクトリの構成はスライドの15ページ。
（どうでもいいメモ）
xulrunnerの読みは「ずーるらんなー」。
HAL
B2G/halはgeckoのHAL（Hardware Abstraction Layer＝ハードウェア抽象化層）。
Sensor、Switch、FMRadio、Eventpollingとかその辺。
基本的な制御シーケンスは、GaiaからGonk、HAL層。
以下はスクリーンの明るさを弄るSetLight()のコールグラフ。
（スライドの20ページ目）
gaia/apps/system/js/setting.js // この辺は辛め
└gecko/dom/base/Navigator.cpp
└gecko/dom/power/PowerManager.cpp
└gecko/hal/sandbox/Sandboxhal.cpp // ここを通るかどうかは保証がない
└gecko/hal/gonk/Gonkhal.cpp のSetScreenBrightness
└gecko/hal/gonk/Gonkhal.cpp のSetLight
HALは「純粋なHAL」ではなく「DAP（Device APIs？）の低レイヤ層に集める」という目的のもの。
デバイスを直接叩くようなコードはxpcomディレクトリの方にいる。
ただ、昔のコードはdomの方にいたりする。
（質疑応答：Mozillaのどなたか（失礼）が回答されていた内容）
Firefox OS（Firefox？）で出てくるIDLは3つある。
一つはXPIDLと呼んでいるもの。（XPIDL、XPCOM）
2つ目はWebIDLで、これはまさにWebとバインディングするためのもの。（WebIDL bindings）
PIDLはプロセス間通信用。（ググったけど見つからない……）
Firefox OS パッケージ型アプリ インストールの仕組みを調べてみた
にしむねあさん。
FxOS Gecko勉強会のトリガーになった方。
パッケージ型アプリの種類
Firefox OSのパッケージ型アプリ（packaged apps）は、Certified、Privileged、Webの3つがある。
それぞれ権限が異なる。
Certifiedは、メーカがプリインしない限りはどのような方法でもインストールできない。
Privilegedは、Marketplaceからのインストール、あるいはSimulatorからPUSHでインストールすることが可能。配布元のURLのチェックが行われるので、闇マーケット（補足：悪いことしてアプリ引っこ抜いて勝手に公開、みたいな）からのインストールは不可。
Webは制限がないが、アプリが使用できるAPIが制限される。
（補足：逆に言うと、WebよりPrivilegedやCertifiedのほうが使用可能なAPIが多い）
パッケージ型アプリのインストールのシーケンス
スライドの9〜10ページ参照。
Mini Manifest
詳細は11ページ。
GeckoがMarketplaceからアプリのインストール要求を受けたとき、Marketplaceから最初に（アプリ本体のzipを取得する前に）取得する情報。
アプリ自体の情報はアプリのzipに同梱されているmanifest.mfに記載されているが、Mini Manifestは事前にチェックするための情報が格納されている。
Firefox OS Simulatorによるインストールのシーケンス
スライドの15〜16ページ。
ホストPCと端末をUSBで繋ぐ。
するとホストPC上のSimulatorからPUSHできるようになる。
2つのチャンネルを使う。
zipを転送するところはadb（Android Debug Bridge）。
インストール要求のところはMozilla Debuging Protocol（tcp:6000）。
非公式なインストール
アングラな話。
Androidのroot化ツール（の一部）を使うことで、本来認められていないアプリをインストールすることができる。
Certifiedアプリをウェブサイトからインストールする方法
20ページ。
端末をroot化する。
端末からomni.jaファイルを抜き出す。
omni.jaの中にあるWebapps.jsmを抽出する。
権限チェックのところを削る。
書き換え済みのomni.jaを端末に戻す。
＼(^o^)／
CertifiedアプリをFirefox SimulatorからPUSHする方法
21ページ。
ウェブサイトからのインストールと同様、omni.jaを書き換えて端末に戻す。
変更するファイルはdbg-webapp-actors.jsで、Certifiedのチェックを行っている箇所を削る。
非公式インストールを防ぐには
Firefox OSの製品向けビルド時はadbのshell、pullコマンドを無効化する。
ただ、Androidでもいまだにroot化はなくなっていないのでいたちごっこか。
詳しく知りたい方はFxOSコードリーディングで。
（質疑）
パッケージを解凍して書き換えて再パックした場合は、署名が異なるのでインストールチェックで弾かれる。
「署名がついていないアプリ」はインストールが許される。
「署名が付いていて、かつ署名が不正な場合」はインストールできない。
（小休止）
ここから下の後半2セッションは理解が追いつかなかったので、的外れなことを書いているかも知れません。
もし誤っている記述がございましたら、そっと@rkisatoまで一報いただければ修正させていただきます。
せっかくだから俺はこのNPAPIの話をするぜ
この日、自分的にかなりハードルが高かったセッションその2。
@TNarutoさん。
お話を伺うのは初めてかあっても2回目ぐらいなんですが、煽っていくぅぅ系の方な印象でした（失礼）。
すごくプレゼン慣れされた方でした。
前置き
TIZENをやるために某社（社名書いて良かったら直します）に在籍しているものの、仕事で全然やっていない。
NPAPI歴は浅い。（但しご当人の主観）
Geckoのソースを読む時間がなかったため、NPAPI（えぬぴーAPI）の状況をまとめる。
Android向けにNFCをWeb APIから触りたいという話があって、NPAPIを使えればいけるのでは、ということで開発したものの、これは鬼門だらけの開発だった。
Android＋NPAPI。
JavaからC、CからJava。JNI経由でCのプラグインからNFCを叩く。
大変な作業だった割に情報がないので勉強会で発表した。
その時の発表資料はhttp://www.slideshare.net/TNaruto/android-web-kit。
NPAPIとは
NPAPIは複雑で面倒なプラグインシステム。
面倒なのにいまだに使われているのは、現状これに変わる代替がないから。
FlashやUnityやSilverlightはNPAPIで作られている。
Google Chrome
GoogleはNPAPIに限界を感じたようで、PPAPI（ペッパープラグインAPI）を作った。
Chromeでは来年からNPAPIを排除する方向になっている。
Mozilla Firefox
FirefoxはNPAPIのサポートを続ける。
MozillaはPPAPIの開発には参加していない。
更にNPAPIをGecko Plugin APIと呼ぶぐらい愛している。
その割に、次のバージョンからはクリックしないとプラグインを実行できないようになるが。
iOS
FlashはアレなのでHTML5をプッシュ。
2009年から2010年あたりからFlashを排除していて、これはつまりNPAPIの排除。
Android WebKit（Blink）
NPAPIのロードが可能である。
オフィシャルにサンプルも用意されている。
但しAndroidを弄れないとロードすることができない。
もし近い将来、WebKitからBlinkに置き換えられたらどうなるか？
ChromeはNPAPIを排除する方針である。
そしてBlinkはChromeのためのレンダリングエンジン。
ロードさせるのも大変なので、今後使えるか不透明。
Android界のNPAPIの救世主
救世主が表れた。
Android版のFirefox。
これはAndroid Webkitのプラグインロード部分をぱくってそのままの形でインスパイアしてNPAPIロードを実現している。（取り消し線のところは概ね原文を再現）
Android Firefox上でNPAPIが使える？
AndroidでNPAPIが使いたいときはFirefoxを選べば良い？
艦これとかできる、ニコ動も動く。
Firefox OS
Firefox OSはWebがプラットフォーム。
NPAPIは実はネイティブなわけで、つまりFirefox OSの仮想敵ではないか？
ソースコードは見ていないけど、NPAPIにはそれほど積極的ではないのでは、という印象。
（補足：Mozillaの浅井さん）
NPAPIをやりたい人は勝手にどうぞ、というところ。
ここまでのまとめ
モバイルプラットフォーム全体としては、NPAPIを収束させる方向へ向かっていた。
ここで突然のTIZEN
ところが。TIZENがNPAPIをサポートすると言い出した。（Tizen 2.0）
バイナリのみとはいえ、プラグインのサンプルもオフィシャルに出している。
Firefox OSのスタンス
Firefox OSとしては、需要があるものはやる。
しかし今のところ、そういう（NPAPIを続けてほしいという）声はない。
まとめ
NPAPIを使いたい場合は、PCもモバイル（Android）もFirefoxに落ち着く。
NPAPI SDK
https://code.google.com/p/npapi-sdk/
ここにNPAPI SDKが置いてある。
NPAPI Scripting
3種類のフレームワークがある。
・LiveConnect
・XPConnect
・NPRuntime
NPAPIは複数の実装方法があり、情報が錯綜している。
現在のスタンダードは、3つ目に上げたNPRuntimeの利用。
XPConnectはこの後のプレゼンででPiroさんから発表がある。
ここではNPRuntimeについて解説する。
NPRuntimeのサンプル
ビルドしてmozillaのlibの下へつっこんでブラウザからプラグインを確認。
NPAPIの今後
Webプラットフォームを使ったR&D案件でNPAPIを使うという話になった。
PulseAudioで、オーディオのアウトプットの出力をスピーカからBluetoothヘッドセットへ切り替えたい。Webアプリから。
PulseAudioを触るNPAPIプラグインを作ればどうか？
このやり方は、サーバを立ててIP振り分けて、とか面倒なことをやるよりもインストールが簡単で、セキュリティの懸念する範囲も狭い。
今後は2つの使われ方が出てくるのではと考えている。
一つはプラットフォームとしての利用。
HTML5でできることがFlashかUnityで今できること以上にならない限り、、NPAPIはなくならない。
もう一つがWeb APIのラピッドプロトタイピング向け。
レンダリングエンジンの仕組みを知らなくても、WebIDLとかを知らなくてもプラグインをコンパイルするだけで使えるのは利点。
一時凌ぎ的なAPIとして使える。
NPAPIは完全に代替できる仕組みがないので、NPAPI上のプラットフォームは使い続けざるを得ない。
NPAPIを過去のものとして放棄するより、NPAPIで何ができるかを知っておいた方が有益。
（質疑応答の回答：これもMozillaの方の回答だったかも）
NPAPIは、その昔にobjectタグやembeddedタグで違うことをしたいという目的で作られた。
当時はJSと連携してというような考え方はなかったので、NPAPIにそうした思想が入っていないのは当然。
ものすごく今更なXPCOMとXPConnectのおはなし
自分的にかなりハードルが高かったセッションその2。
@piro_orさん。
前置き
普段のはFirefoxのアドオンをいろいろ使っている。
仕事でもFirefoxやTHunderbirdのアドオンを作ったりソースコードを調査したりしている。
GeckoのDOMのjavaScriptバインディングについて
XPCOMとXP。
C++などで開発した機能をjavaScriptから使えるようにする（＝バインディングする）。
「History of Mozilla’s DOM bindings」にこれまでの歴史が載っている。
midl
→XPIDL+XPConnect
→nsDOMClassInfo
→webIDL+nsWrapperCache
XPConnectで何ができるか
C++で作った機能をJavaScriptから使えるようになる。
Firefox OSアプリというよりFirefox OS自体のハック向けの話になる。
XPCOM
言語やプラットフォームに依存しない形式でコンポーネント定義したり。
XPIDL
.idlと付いているファイルはこれ。
XPCOMコンポーネントのインタフェースを定義するファイル。
XPConnect
C++とJavaScriptを繋ぐ境界。
mozillaのソースコード全文検索には、以下のサイトが使える。
Mozilla Cross-References
一つ前の版のようだが、登壇者はこれを好んで使っている。
XPCOM全盛期の背景事情
昔は今よりC++の比率が高かった。
JavaScriptは遅かったので、JavaScriptはあくまでグルーとして使っていた。
XPCOMは、C++でのクロスプラットフォーム開発をしやすくするためのもの。
XULRunner。（個人メモ：ここの話聞きそびれたかも）
XPCOMコンポーネント同士はXPCOMの呼び出し規約に従っている。
XPCOMコンポーネントはWindows用の処理やMac OS用の処理や…があって、ブラウザから環境によって呼び分ける。
XPConnectはC++とJSの境界で働く。
XPCOMとXPConnectが使われている（た）部分の例としては、DOM APIの実装。
今はだいぶWebIDLへ置き換えられている。
メソッド呼び出しやプロパティアクセスを仲介する。
DOMNode.appendChild()など（現在はWebIDL）は、呼び出し元によって許可・不許可を判断している。
XPCOMコンポーネントをJSのスクリプトから参照する。
XPCOMとWebIDLの違い
戻り値が異なる。
XPCOMの時は例外処理を使わずに状態を表現できるよう、戻り値に状態を含めていた。
XPIDL
コマンドラインハンドラが実装しなければならないインタフェース。
XPCOMコンポーネント同士のやり取りではXPCOMコンポーネントレベルの要求しかしない、つまり各コンポーネントの開発言語が別でもOK。
XPCOM周りを押さえることで、Firefox OSの低レイヤの開発に食い込むことができる。
その他のトピック
・js-ctypes。JavaScriptからネイティブ製ライブラリの機能を直接呼ぶ機能。
・window.consoelog()やwindow.performanceのようなWeb APIをJSで定義する方法。
その他
登壇の@piro_orさん著のFirefox Hacks Rebooted、買ってね。
（質疑応答）
プレゼンの中でC++の例外の話があったが、MozillaではC++の例外は遅いのですべて殺している。
個人的まとめ
序盤のひだかさんからにしむねあさんあたりでハードルが上がってきて、NarutoさんとPiroさんのあたりは口からエクトプラズム出かかっていました。
今まで知らなかった（どちらかというとFirefox OSよりFirefox、あるいはいわゆるブラウザの）歴史や作りの一端を知ることができて大変勉強になりました。
プレゼンいただいた皆さん、どうもありがとうございました！
あと例によって大変そうだっためこさん、会場を快くお貸しいただいた浅井さん、いつもどうもありがとうございます！
コメントを残す