【GDG DevFest Tokyo 2019】 ネイティブアプリとWebアプリの差を埋めるには：Project Fuguとマルチスレッドプログラミング 【まとめ記事】
ふぐ美味しい、週7でメンヘラしてます。
この記事はGDG DevFest Tokyo 2019でのセッション「ネイティブアプリとWebアプリの差を埋めるには：Project Fuguとマルチスレッドプログラミング」のまとめになります。
このブログに書いてることを元に話している音声を用意したので
バックグラウンドで再生しながら読んでもらえたら嬉しいです。
忙しい方は、音声だけでも、ブログだけでも大丈夫です。
目次の横の数字は再生位置です。
音声はこちらです。
- はじめに[00:56]
- セッション概要 [02:12]
- Webはできることが少ないと思われている[03:16]
- Webで大事なこと [03:45]
- ネイティブとの谷を埋める [04:23]
- Project Fugu [04:58]
- Webブラウザはワンオペ [07:06]
- 実験段階のAPI [10:38]
- WebAssembly(WASM) [11:32]
- おわりに [14:53]
はじめに[00:56]
私のレベル感だけお伝えしておきます。
- お仕事
- Webフロントエンジニア
- Webデザイナー
- 関係ありそうな経歴
- 2018/06~ 初めてHTMLを触る
- 2018/07~ 渋谷のスタートアップで半年インターン
- 2019/02~ 体調考慮してフルリモート
- 2019/04~ 独学でデザイン勉強してお仕事貰う
(こんな感じですので、解釈間違いもあるかと思います。その際は、教えて頂けると嬉しいです。聴きながらのメモを元に書いているので曖昧なところもあると思います。)
それではまずこのセッションについてです
セッション概要 [02:12]
ネイティブアプリとWebアプリの差を埋めるには：Project Fuguとマルチスレッドプログラミング
ネイティブアプリにできるけれどもWebアプリにはできない
ということはいくつかあります。
ファイルシステムへのアクセスや、C++で書かれたコードの実行、マルチスレッドプログラミングなどはその典型例と言えるでしょう。
この差を埋めるため、いくつかの仕様が提案され、その実装がおこなわれています。
このセッションではPWA、Project Fugu、WebAssembly、Web Workerといったキーワードを軸に、ネイティブアプリとWebアプリの差を埋めるために行われている活動についてご紹介します。
GDG DevFest Tokyo 2019 | 清水智公
Webはできることが少ないと思われている[03:16]
ネイティブアプリ開発者からの意見
- ブラウザの制限キツい
- パフォーマンスを活かしきれていない
ネイティブで出来るのにWebではできないことが沢山あると思われています。
本当にできないのかを辿ると行き着くのは、Webで大事なことだそうです。
では、Webで大事なこととは？
Webで大事なこと [03:45]
安全性
誰でもどこにでもアクセスできるので
プライバシーやセキュリティーを守ることが大事ユースケース
誰でもアクセスできるので
ITリテラシーの低い人でも操作しやすくすることが大事
Webで大事なことから見えてきたのは
ネイティブとの違いでそれは、自分のものかそうでないか。
ネイティブとの谷を埋める [04:23]
その大きな成果の一つがPWA
PWAできること [04:29]
こちらは実際のセッションでのスライドです。
- ユーザーのエンゲージメントに関する部分はできる
- プッシュ通知
- インストールなど
『もっといろんなことができるようにしたいよね』
そこで生まれたのがProject Fuguだそうです。
Project Fugu [04:58]
Webでもっといろんなことできるようにしよう！というものです。
Project名由来 [05:03]
Fuguは魚のふぐから来ています。
ふぐは調理方法を間違えると死にます。有害です。
Project Fuguも使い方を間違えるとユーザーに害が大きいので
そこからFuguだそうです。
Fuguでできるようになること [05:23]
- 連絡先にアクセスして固定の人に送る
- Webでファイルのディレクトリーツリー表示
- ディレクトリー開くとその配下を読み込める
- ブラウザでcodeのedit可能
- ペリフェラルアクセスなど
Project Fugu APIの一覧
Project Fuguからこのページに行けます
このページではFuguの新機能を試すことができます。
フィードバックも送ることができます。
Googleさん側からのお気持ち
『沢山面白いことは考えているのですが
利用してもらって、フィードバックをもらわないと
よりいいものは作れない。
Twitterも見てるのでリプ飛ばしてください。』
沢山試してフィードバッグ送ってねということだと思いました。
ちなみにこちらからFuguのストイックなスプレッドシートが見れます。
(Fuguの開発途中のものやリリース予定)
Webブラウザはワンオペ [07:06]
こちらは実際のセッションでのスライドです。
60fpsの場合、1つの処理に与えられる時間は16ms
その間でイベント処理、スクリプト実行、レンダリング、描画を行います。
ブラウザは原則ワンオペなので特殊な重い処理が
通常の処理を阻害してしまうので時間内に終わらないのです。
スレッドが欲しい
ゲーム関係のエンジニアから言われることだそうです。
スレッドとは？[07:45]
スレッド（thread）とは、CPU利用の単位。
プロセスに比べて、プログラムを実行するときのコンテキスト情報が
最小で済むので切り替えが速くなる。
スレッドは、thread of execution（実行の脈絡）という言葉を
省略したものである。
スレッド (コンピュータ) | Wikipedia)
Wikipedia先生的にはこういうことみたいです。
スピーカーの清水さんは
呼ばれた関数の履歴だと思ってくださいと言っていました。
この記事では、スレッド＝呼ばれた関数の履歴ということで進めます。
JavaScriptは単一スレッド環境なので
複数のスクリプトを同時に実行することが不可能です
そこでWeb Workerの出番です。
Web Worker [08:30]
Web Workerとは？[08:31]
Web Worker は、ウェブコンテンツがスクリプトをバックグラウンドのスレッドで実行するためのシンプルな手段です。
Worker スレッドは、ユーザーインターフェイスを妨げることなくタスクを実行できます。
加えて、それらは (responseXML 属性や channel 属性は常に null ですが) XMLHttpRequest を使用して入出力を行うこともできます。
生成された Worker は、生成元が指定したイベントハンドラーへメッセージを送ることにより JavaScript コードへメッセージを送ることができます (その逆も可能です)。
Web Worker の使用 | Mozilla
つまり、JavaScriptをマルチスレッドで実行できるようにする仕組みです。
Web Workerを使用することでワンオペから解放されます。
Comlinkの使用でWorkerAPIを使うときに幸せになる [09:08]
『Worker API使うときに幸せ、まじおすすめです』 とのことです。
Comlinkとは？ [09:22]
Comlink makes WebWorkers enjoyable.
Comlink | GitHub
ちょっとよくわからないので、いろいろ調べてみました
- WebWorkersを簡単にかけるProxyを使用したライブラリ
- postMessageなどのメッセージングを隠してくれるもの
- メッセージベースのAPIをただの値を扱うかのように置き換えたもの
- 異なるrealmのオブジェクトを非同期に扱うライブラリ
まとめると...
WebWorkerはメッセージシステムを利用してメインスレッドとの間でデータ送信をしている。
そのメッセージを隠して値だけを表示させるようにしたproxyでかかれてるWeb Wokersを簡単にかけるようにしたライブラリ
つまり、Worker API使うときに幸せ、まじおすすめということですね。
(不安すぎるので皆さんも個人で調べてみてください)
実験段階のAPI [10:38]
Atomics.wait() [10:45]
Atomics.wait() は静的なメソッドで、Int32Array 中の指定された位置に指定された値が保存されているかどうかを検証し、検証できるまでスリープ、もしくはタイムアウトします。
返り値は "ok"、"not-equal"、"timed-out" のいずれかです。
Atomics.wait() | Mozilla
検証するまでは寝かせときます。
Atomics.notify() [11:00]
The static Atomics.notify() method notifies up some agents that are sleeping in the wait queue.
Atomics.wait() | Mozilla
『寝ている人に起きろ！』という感じだそうです。
この二つを上手く使い必要に応じて
読み取るスレッドを分けるのかなと感じました。
(ここもかなり不安です)
WebAssembly(WASM) [11:32]
asm.jsを人の手で書くにはまるで綱渡り
それは、辛いのでWebAssemblyを使うと幸せ
とのことです。
asm.jsとは？ [11:45]
JavaScriptの高速化技術です。
その後WebAssemblyが登場したので
asm.jsに取り組む意味は薄くなったそうです。
もっと気になる方はこちらをみてください。
WebAssemblyとは？ [12:17]
WebAssemblyとは、ブラウザ上で動作するアセンブリ言語である。
特徴は、ブラウザ上でバイナリーフォーマットの形で実行可能なこと。
バイナリーフォーマットの形で実行可能なので
JavaScriptにはできない複雑な処理や重い処理を高速化してできる。
WebAssemblyを使うと幸せにつながる。
また、WebAssemblyはアセンブリ言語なので手元で書いたファイルを
ブラウザでコンパイルしてブラウザ経由で
Arudinoなどに転送して動かすこともできるそうです。
WebAssemblyによって
かなり色々な方向に可能性が広がったように感じました。
その一つとして
Web×Vimを実現したWebAssemblyの使用例が紹介されていました.
Web上でVimが使える!? [13:14]
『皆さんがどのEditorを使っているかは聞きません。
Vimというものがあるらしいですね
VimというものがWebで使えるのがこちらWeb×Vimですね』
『これ面白いのが作者がこれをReact Componentで作っているところですね
React Componentとしても使用できます』
えっ！？ってなりますよね笑
この使用例の話は会場もとても盛り上がっていました笑
SMIDのサポート提案 [13:55]
This repository holds a proposal for adding 128-bit SIMD support to WebAssembly.
SIMD proposal for WebAssembly | GitHub
WebAssemblyに128bitのSIMDのサポートを追加する提案です。
SMIDとは？ [14:16]
Single Instruction/Multiple Dataの略
コンピュータやマイクロプロセッサで並列処理を行なうための
設計様式の一つで、一つの命令を同時に複数のデータに適用し
並列に処理する方式。
SIMD | e-words
WebAssemblyに128bitのSIMDのサポートを追加されると
数値演算を並列に処理するので、ハードウェア並みの速さです。
全英語ですが、この記事がわかりやすかったので載せておきます。
おわりに [14:53]
全てのブラウザに対応してない問題 [14:58]
WebAssemblyはまだ新しい技術でもあり対応が追いつかないようです。
今の所、そのままで動かせるのはChromeだけだそうです。
Google i/OでWebAssemblyをリアルタイムで使用 [15:18]
MIDIキーボードで鳴らした音と同じ音がスマホから鳴るというものです。
31:16までは実際にコードを書いているところなので
忙しい方はそこから見るのをおすすめします。
Sonic Boom! Audio Programming on Android and Chrome (Google I/O'19)
以上になります。
ここまで読んでいただきありがとうございます。
(サムネイルの文字に脱字がありました。GDG DevFst Tokyo 2019→GDG DevFest Tokyo 2019です。申し訳ございませんでした。)
