Webの未来 〜 PNaClとasm.jsでカワルミライ -...

PNaClとasm.jsで- いま、モバイルWebの先端で起こっていること !

!

2013/11/22 Kラボ部内定例会用資料 なかざわ けい(@muo_jp) / Kラボラトリー

ずっとある要求

Web上でも爆速でプログラムを実行したい!

Web上でもネイティブ級の表現力を追求したい!

歴史(いろいろあったね)

ActiveX

Java Applet

NaCl

PNaCl

なぜ、今これが重要なのか!

Firefox 22(2013年6月)でNotificationがサポートされた

ChromeはWebKitベースのNotificationを以前からサポート

Chrome for Android(一部端末、2013年3月～)とFirefox OS上のFirefoxは WebGLをサポートしている

技術的な障壁はクリアされつつある

なかざわのスタンス(2011年7月～)

いや、でも ネイティブアプリあるじゃん?

この先、一定範囲の企業では従来のネイティブアプリベースのマネタイズが 立ち行かなくなる可能性がある

プラットフォーム決済手数料

Google Play(Google): 30%

App Store(Apple): 30%

Kindle Store(Amazon): 30%

ちなみにNTT docomoでの料金回収代行では、http://okwave.jp/qa/q318078.html によると9%+貸し倒れ分を差し引いた実効15%程度だった模様(出典としては弱い)

image: http://www.freedigitalphotos.net/images/Computers_g62-Dollar_Symbol_Computer_Key_p97450.html by Stuart Miles

なぜ決済手数料が問題かスマートフォンからアクセスできるコンテンツ量は爆発的に増大(18ヶ月後: コンテンツ総量10倍、決済規模5倍程度になってもおかしくない)

一方でコンテンツ原価は上がっていく

真にコンテンツ自体の力でお金になるアプリは極端に減る(一極集中)

それ以外のアプリは一定以上のプロモーション(広告など)を行わなければ認知すらされない時代へ本格突入する

状況変化予想(～2015年)「一部の省力開発されたアプリがまぐれ当たりを出す一方、多くのリソースを投入して開発されたハイクオリティなアプリが大規模なプロモーションとユーザデータ分析による改善によってのし上がっていくか、既存人気IPや既存人気タイトルのナンバリングまたはフランチャイズでほぼマネタイズ成功アプリが占められる」状況へ

こうなるとコスト競争の度合いが高まり、類似コスト構造を持つ企業同士では原価構造の差がKSFとなる

image: http://www.freedigitalphotos.net/images/gravestones-and-a-cross-at-a-cemetery-photo-p173028 by papaija2008

つまりこのような変化が起こる

あれ、どうせ利用者にはfacebook IDでログインしてもらうなら、別にこれWebでやってもいいよね?

あれ、どうせ広告を出稿するなら、リンク先は別にWebでもいいよね?

あれ、どうせコンビニでギフトカードを買ってWebでチャージしてもらうなら、最初からWebでいいよね?

引用元: http://www.lawson.co.jp/service/static/giftcard/

※既に、クレジットカードを持たない/使わない人々に利用してもらう策であると同時に、30%のプラットフォーム手数料を回避するための策とも言える

あれ、リッチな表現をしたいからアプリでやってたけど、HTML5でのAPIもそろそろ揃ってきしWebでいいよね?

すべての道はWebへと通ず

ユーザアカウント情報の面

広告からのユーザ動線の面

プラットフォーム手数料の面

リッチな表現の面

image: http://www.freedigitalphotos.net/images/Trains_g253-Railway_Tunnel_p42529.html by Sura Naulpradid

どうしてPNaClとasm.jsなの?

技術動向とビジネス的背景

JSランタイムの最適化が 頭打ちに近づいてきた

http://arewefastyet.com/#machine=11 octaneのスコアは横ばいに近づいている

2012年11月からの1年分 (直近計測ポイントが多い事に注意) 緑=Chrome 青=Safari 橙=Firefox(Ion) 環境: Mac OS X 32bit(Mac Pro) !※octaneは計測対象の追加などにより スコアが大きく変わっている

今日のChrome(2013/11/22)

今日のFirefox(2013/11/22)

Webブラウザがパフォーマンスを出したい主戦場が変化してきた

5年前=x86ベースのWindows PC

現在=ARMベースの携帯端末

端末部材事情CPU→プロセス微細化はそろそろ限界。マルチコア化するも、全力で回し続けると熱的にまずい(big.LITTLEなどで緩和も限界ある)

DRAM→値段上がってる(過去1年で倍ぐらい)

シリコンディスク→一定はサイクルが見えている

バッテリ→集積度はあまり上がっていない。基本的に危険物。大画面化の流れに便乗して大容量化の傾向

ディスプレイ→IGZOのような低消費電力のものがどの程度の範囲のスマートフォンに搭載されるかは未知数

ベースバンドほか→QUALCOMMのさじ加減次第(特にLTE)

端末販売の事情

消費電力/サイズ/部材グレード/重量/価格のバランス

新アーキテクチャの低価格端末はそれなりの速度

プレミアム端末と低価格端末の差はより顕著になる

欧州で昨今やたらとWindows Phoneの販売シェアが伸びている

「ベンダーによるコントロール」へのユーザ感覚の変化(過去5年間にWebブラウザが得た物)

「Webの新しい機能は、ユーザの端末に入っているバージョンが上がるまでは使えない」鉄則→Webブラウザは自動的に最新版へ更新されて当然というコンセンサス

最新コードベースが数億台の端末に対して数週間以内に適用されることを期待できる(10年前にはユーザ側拒否感が強く、難しかった)

モバイルにおいて、同種の状況がどの程度確立されるかには注視する必要がある

AndroidではChrome主体の環境が増加中、比較的実現しつつある

WebViewベース(=基本的にOSのOTA更新まで主要コンポーネントが変わらない)のサードパーティブラウザのシェア動向へ注意する必要がある

「Webで完結」の前提は、標準ブラウザシェアが85%以上あること(感覚値)

アプリを出す側の事情

プラットフォームへのロックインは避けたい

「ヨコテン」なるべくしたい

platform-independentなものはなるべくWebで、となるインセンティブはある(しかしこれをWebViewでやるのは非常に辛い道のりであった)

という現状で筋の良さそうなもの二選がPNaClとasm.js

PNaClってなにさGoogleが推している

ダウンロードしてきたLLVMのbitcodeを端末側でネイティブコードにコンパイルして実行する仕組み

実行時のメモリ保護や権限管理には、Chromeが従来からNaCl用に持っているサンドボックスを利用する

Chrome 31(2013/11/12公開)で標準サポート

asm.jsってなにさMozillaが推している

LLVMのbitcodeをJSコードへ変換すると共に型情報などのアノテーションを付け、これに対応するJS実行環境ではAOTコンパイルにより高速実行する仕組み

ArrayBufferをヒープとして利用する

Firefox 22(2013/06/25公開)で標準サポート

PNaClとasm.jsのノリPNaCl

「Androidプラットフォームのシェアが70%ぐらいあるなら、そのプラットフォームで十分高速に動けば問題ないよね」のノリ

おそらく他プラットフォームで実装されることは期待すらしてない

asm.js

「普通のJSエンジンでも実行出来て、専用最適化加えたランタイムなら更に高速に実行出来たほうが嬉しいよね」のノリ

思想はDartやTypeScriptのものに近く「純粋な演算はなるべくバリアントな型にするのを避け評価のコストを減らす」アプローチ

asm.jsのキモ

AOTコンパイルフェイズ(http://asmjs.org/spec/latest/ より)

実行前にコードパスを読み切り、ネイティブコードを生成するのがポイント(Pythonに対するCythonと近い)

関数冒頭で”use asm”;というコードを含むと、最適化対応エンジンはAOTコンパイルを試みる

AOTコンパイル可能なコードパターンは限られている

静的型付けを実現するためのアノテーション

例: 関数冒頭で x = +x;とすると、最適化対応JSエンジンではこの変数をdoubleとして扱う

モジュールの構築時点でバリデーションを行うことで、ミスを検出する

動的に置き換えられる可能性のあるコードを含む場合、当該asm.jsモジュールのAOTコンパイルは失敗して通常通りインタプリタ実行される(当然、この場合でもJITコンパイルは効くがasm.jsの良さは活きない)

基本的に、人が手で書くものではない(そういう芸はあってもいい)

asm.jsモジュールの例

http://asmjs.org/spec/latest/ より

PNaClのキモどの程度の標準ライブラリを呼び出すことが出来るか

pthread(および、おそらくC++11のstd::thread)は使えそう

プロセスのforkなどは出来ない

JSとの連携部分がJNIほどダルくないか

(まだまだ調査中です)

だから私はPNaClを見ていく

Unreal EngineのPNaCl版とか、Unity Web PlayerのPNaCl版とか出ると熱い

Playground( https://github.com/KLab/PlaygroundOSS )をPNaClベースにポーティングしてみると、多分色々なことが見えてくる←今ココ

この先、注目すべき動向

基本ライン

「強力なプラットフォームを持つベンダーが自社ビジネスとカニバるエリアへどこまで攻めていくか」という話

AppleがMobile Safariでの asm.js高速化に動くかまずあり得ない

asm.jsベンチマークは、JSエンジンの力をドヤるのに用いられる多くの他ベンチマークとは明らかに異なる

「スコアで挑発されたからこっちは更に倍速にしたぜ!ﾋｬｯﾊｰ」という純粋なエンジニアリングの世界ではない

なので、もし起こったら重要な意味を持つ

Googleがasm.js用のAOTコンパイルサポートへ動くか今のところ、まずあり得ない

PNaClとDartを捨てるというジャッジに近い

C++の標準ライブラリへのコール以外に特段意味は残らない

なので、もし起こったら重要な意味を(ry

asm.js独自拡張要素asm.js専用アプリ(パフォーマンス面でなく)の登場

現在のところ「asm.jsのコードは、最適化の施されていないJSエンジンでも完全に動作する」ことが売りのひとつになっている

「じゃ、WebViewの中で」という話ではない

若干ふわっとしているけれど、これも起こると重要な(ry

Webからのプッシュ通知OS X MavericksではSafariにおいてサポートされた

Chromeはしばらく前から実装している

ではモバイルでは?まだまだ

リテンションにおいてプッシュ通知が果たす役割は非常に大きい

なので、もし起こったら重(ry

データダウンロードや オフラインキャッシュは?「WebだからF5叩けばいつでも最新コード」は場面によって真でない。

高解像度なテクスチャを利用するWebGLベースのゲームを作ろうとすると、データダウンロードタイミングは確実に問題となる(基本的にはApplicationCacheによって解決する部分)

現状は50MBが上限とされる(http://stackoverflow.com/questions/14876018/what-is-the-maximum-cache-size-for-ios6-web-apps-and-how-can-i-extend-it)が、これが引き上げられることがあるか?

「アクセスした際にすぐ最新ゲームを遊べるユーザ体験の実現」には、ユーザがWebサイトを訪れていないタイミングでのキャッシュ更新が必要

iOS 7で実装されたようなバックグラウンドダウンロードの仕組みが必要になる

データサイズによってWeb向けのアプリとインストール向けのアプリがセグメントされていくようになるのか?の判断ポイントでもある

番外編: Firefox OS事情大切なのは、Firefox OS=「変化を引き起こし、他者へ圧をかけていくプレイヤーのひとつ」ということ

端末販売者に推されるプラットフォームでなければ、引き起こした変化も他プラットフォームから無視されて消えていく

プラットフォームの成熟度は、端末販売者としての推しやすさに直結する

バリエーションの豊富な端末が多く出荷され、結果としてのバージョンアップ地獄に対する練度がどの程度まで高まっていくかを注視

番外編: Tizen事情状況がよく分からないので、変化あれば見ていく感じ

HTML5原理主義ということでもないので、PNaClアプローチが割とハマる感もする

車載端末用など、ドメイン特化するのであればまた別の考え方が必要なので引き続き見ていく。

「本気でこれ行くで」となったら本気の資本と技術を投下出来る会社が進めているので、完全な無視は筋悪

未来は僕らの手の中 (端末的な意味で)