SlideShare a Scribd company logo
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でいいよね?

※既に、クレジットカードを持たない/使わない人々に
利用してもらう策であると同時に、30%の

プラットフォーム手数料を回避するための策とも言える

引用元: http://www.lawson.co.jp/service/static/giftcard/
あれ、リッチな表現をしたいからアプリでやっ
てたけど、HTML5でのAPIもそろそろ
しWebでいいよね?

ってき
すべての道はWebへと通ず
ユーザアカウント情報の面
広告からのユーザ動線の面
プラットフォーム手数料の面
リッチな表現の面

image: http://www.freedigitalphotos.net/images/Trains_g253-Railway_Tunnel_p42529.html by Sura Naulpradid
どうしてPNaClとasm.jsなの?
技術動向とビジネス的背景
JSランタイムの最適化が
頭打ちに近づいてきた
2012年11月からの1年分
(直近計測ポイントが多い事に注意)

緑=Chrome
青=Safari
橙=Firefox(Ion)
環境: Mac OS X 32bit(Mac Pro)
!
※octaneは計測対象の追加などにより
スコアが大きく変わっている

http://arewefastyet.com/#machine=11
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-maximumcache-size-for-ios6-web-apps-and-how-can-i-extend-it)が、これが引き上げられることがあるか?
「アクセスした際にすぐ最新ゲームを遊べるユーザ体験の実現」には、ユーザがWebサイトを訪
れていないタイミングでのキャッシュ更新が必要
iOS 7で実装されたようなバックグラウンドダウンロードの仕組みが必要になる
データサイズによってWeb向けのアプリとインストール向けのアプリがセグメントされていくよ
うになるのか?の判断ポイントでもある
番外編: Firefox OS事情
大切なのは、Firefox OS=「変化を引き起こし、他者へ圧をか
けていくプレイヤーのひとつ」ということ
端末販売者に推されるプラットフォームでなければ、引き起
こした変化も他プラットフォームから無視されて消えていく
プラットフォームの成熟度は、端末販売者としての推しやす
さに直結する
バリエーションの豊富な端末が多く出荷され、結果としての
バージョンアップ地獄に対する練度がどの程度まで高まって
いくかを注視
番外編: Tizen事情
状況がよく分からないので、変化あれば見ていく感じ
HTML5原理主義ということでもないので、PNaClアプ
ローチが割とハマる感もする
車載端末用など、ドメイン特化するのであればまた別の
考え方が必要なので引き続き見ていく。
「本気でこれ行くで」となったら本気の資本と技術を投
下出来る会社が進めているので、完全な無視は筋悪
未来は僕らの手の中
(端末的な意味で)

More Related Content

Webの未来 〜 PNaClとasm.jsでカワルミライ - いま、モバイルWebの先端で起こっていること