Your SlideShare is downloading. ×
Webの未来 〜 PNaClとasm.jsでカワルミライ - いま、モバイルWebの先端で起こっていること
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

25,617
views

Published on

社内ミーティングでの発表用に作成した資料です

社内ミーティングでの発表用に作成した資料です


0 Comments
63 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
25,617
On Slideshare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
62
Comments
0
Likes
63
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. PNaClとasm.jsで - いま、モバイルWebの先端で起こっていること ! ! 2013/11/22 Kラボ部内定例会用資料 なかざわ けい(@muo_jp) / Kラボラトリー
  • 2. ずっとある要求 Web上でも爆速で
 プログラムを実行したい! Web上でもネイティブ級の
 表現力を追求したい!
  • 3. 歴史(いろいろあったね) ActiveX Java Applet NaCl PNaCl
  • 4. なぜ、今これが重要なのか ! Firefox 22(2013年6月)でNotificationがサポートされた ChromeはWebKitベースのNotificationを以前からサポート Chrome for Android(一部端末、2013年3月∼)と
 Firefox OS上のFirefoxは
 WebGLをサポートしている 技術的な障壁はクリアされつつある
 
 なかざわのスタンス(2011年7月∼)
  • 5. いや、でも ネイティブアプリあるじゃん? この先、一定範囲の企業では従来の
 ネイティブアプリベースのマネタイズが
 立ち行かなくなる可能性がある
  • 6. プラットフォーム決済手数料 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
  • 7. なぜ決済手数料が問題か スマートフォンからアクセスできるコンテンツ量は爆発的 に増大(18ヶ月後: コンテンツ総量10倍、決済規模5倍程度 になってもおかしくない) 一方でコンテンツ原価は上がっていく 真にコンテンツ自体の力でお金になるアプリは
 極端に減る(一極集中) それ以外のアプリは一定以上のプロモーション(広告な ど)を行わなければ認知すらされない時代へ本格突入する
  • 8. 状況変化予想(∼2015年) 「一部の省力開発されたアプリがまぐれ当たりを出す一 方、多くのリソースを投入して開発されたハイクオリティ なアプリが大規模なプロモーションとユーザデータ分析 による改善によってのし上がっていくか、既存人気IPや 既存人気タイトルのナンバリングまたはフランチャイズ でほぼマネタイズ成功アプリが占められる」状況へ こうなるとコスト競争の度合いが高まり、類似コスト構 造を持つ企業同士では原価構造の差がKSFとなる image: http://www.freedigitalphotos.net/images/gravestones-and-a-cross-at-a-cemetery-photo-p173028 by papaija2008
  • 9. つまりこのような変化が起こる
  • 10. あれ、どうせ利用者にはfacebook IDでログインし てもらうなら、別にこれWebでやってもいいよね?
  • 11. あれ、どうせ広告を出稿するなら、 リンク先は別にWebでもいいよね?
  • 12. あれ、どうせコンビニでギフトカードを
 買ってWebでチャージしてもらうなら、
 最初からWebでいいよね? ※既に、クレジットカードを持たない/使わない人々に 利用してもらう策であると同時に、30%の
 プラットフォーム手数料を回避するための策とも言える 引用元: http://www.lawson.co.jp/service/static/giftcard/
  • 13. あれ、リッチな表現をしたいからアプリでやっ てたけど、HTML5でのAPIもそろそろ しWebでいいよね? ってき
  • 14. すべての道はWebへと通ず ユーザアカウント情報の面 広告からのユーザ動線の面 プラットフォーム手数料の面 リッチな表現の面 image: http://www.freedigitalphotos.net/images/Trains_g253-Railway_Tunnel_p42529.html by Sura Naulpradid
  • 15. どうしてPNaClとasm.jsなの?
  • 16. 技術動向とビジネス的背景
  • 17. JSランタイムの最適化が 頭打ちに近づいてきた 2012年11月からの1年分 (直近計測ポイントが多い事に注意) 緑=Chrome 青=Safari 橙=Firefox(Ion) 環境: Mac OS X 32bit(Mac Pro) ! ※octaneは計測対象の追加などにより スコアが大きく変わっている http://arewefastyet.com/#machine=11 octaneのスコアは横ばいに近づいている
  • 18. 今日のChrome(2013/11/22)
  • 19. 今日のFirefox(2013/11/22)
  • 20. Webブラウザがパフォーマンスを 出したい主戦場が変化してきた 5年前=x86ベースのWindows PC 現在=ARMベースの携帯端末
  • 21. 端末部材事情 CPU→プロセス微細化はそろそろ限界。マルチコア化するも、全力で回 し続けると熱的にまずい(big.LITTLEなどで緩和も限界ある) DRAM→値段上がってる(過去1年で倍ぐらい) シリコンディスク→一定はサイクルが見えている バッテリ→集積度はあまり上がっていない。基本的に危険物。大画面化 の流れに便乗して大容量化の傾向 ディスプレイ→IGZOのような低消費電力のものがどの程度の範囲のス マートフォンに搭載されるかは未知数 ベースバンドほか→QUALCOMMのさじ加減次第(特にLTE)
  • 22. 端末販売の事情 消費電力/サイズ/部材グレード/重量/価格のバランス 新アーキテクチャの低価格端末はそれなりの速度 プレミアム端末と低価格端末の差はより顕著になる 欧州で昨今やたらとWindows Phoneの販売シェア が伸びている
  • 23. 「ベンダーによるコントロール」へのユーザ感 覚の変化( 過去5年間にWebブラウザが得た物) 「Webの新しい機能は、ユーザの端末に入っているバージョンが上がるまでは使え ない」鉄則→Webブラウザは自動的に最新版へ更新されて当然というコンセンサス 最新コードベースが数億台の端末に対して数週間以内に適用されることを期待でき る(10年前にはユーザ側拒否感が強く、難しかった) モバイルにおいて、同種の状況がどの程度確立されるかには注視する必要がある AndroidではChrome主体の環境が増加中、比較的実現しつつある WebViewベース(=基本的にOSのOTA更新まで主要コンポーネントが変わらない)の サードパーティブラウザのシェア動向へ注意する必要がある 「Webで完結」の前提は、標準ブラウザシェアが85%以上あること(感覚値)
  • 24. アプリを出す側の事情 プラットフォームへのロックインは避けたい 「ヨコテン」なるべくしたい platform-independentなものはなるべくWebで、とな るインセンティブはある(しかしこれをWebViewでや るのは非常に辛い道のりであった)
  • 25. という現状で筋の良さそうな もの二選がPNaClとasm.js
  • 26. PNaClってなにさ Googleが推している ダウンロードしてきたLLVMのbitcodeを端末側で
 ネイティブコードにコンパイルして実行する仕組み 実行時のメモリ保護や権限管理には、Chromeが従来 からNaCl用に持っているサンドボックスを利用する Chrome 31(2013/11/12公開)で標準サポート
  • 27. asm.jsってなにさ Mozillaが推している LLVMのbitcodeをJSコードへ変換すると共に型情報な どのアノテーションを付け、これに対応するJS実行環 境ではAOTコンパイルにより高速実行する仕組み ArrayBufferをヒープとして利用する Firefox 22(2013/06/25公開)で標準サポート
  • 28. PNaClとasm.jsのノリ PNaCl 「Androidプラットフォームのシェアが70%ぐらいあるなら、その プラットフォームで十分高速に動けば問題ないよね」のノリ おそらく他プラットフォームで実装されることは期待すらしてない asm.js 「普通のJSエンジンでも実行出来て、専用最適化加えたランタイ ムなら更に高速に実行出来たほうが嬉しいよね」のノリ 思想はDartやTypeScriptのものに近く「純粋な演算はなるべくバリ アントな型にするのを避け評価のコストを減らす」アプローチ
  • 29. asm.jsのキモ AOTコンパイルフェイズ(http://asmjs.org/spec/latest/ より) 実行前にコードパスを読み切り、ネイティブコードを生成するのがポイント(Pythonに対するCythonと近い) 関数冒頭で”use asm”;というコードを含むと、最適化対応エンジンはAOTコンパイルを試みる AOTコンパイル可能なコードパターンは限られている 静的型付けを実現するためのアノテーション 例: 関数冒頭で x = +x;とすると、最適化対応JSエンジンではこの変数をdoubleとして扱う モジュールの構築時点でバリデーションを行うことで、ミスを検出する 動的に置き換えられる可能性のあるコードを含む場合、当該asm.jsモジュールのAOTコンパイルは失敗して 通常通りインタプリタ実行される(当然、この場合でもJITコンパイルは効くがasm.jsの良さは活きない) 基本的に、人が手で書くものではない(そういう芸はあってもいい)
  • 30. asm.jsモジュールの例 http://asmjs.org/spec/latest/ より
  • 31. PNaClのキモ どの程度の標準ライブラリを呼び出すことが出来るか pthread(および、おそらくC++11のstd::thread)は使えそ う プロセスのforkなどは出来ない JSとの連携部分がJNIほどダルくないか (まだまだ調査中です)
  • 32. だから私はPNaClを見ていく Unreal EngineのPNaCl版とか、Unity Web Playerの PNaCl版とか出ると熱い Playground( https://github.com/KLab/ PlaygroundOSS )をPNaClベースにポーティングして みると、多分色々なことが見えてくる←今ココ
  • 33. この先、注目すべき動向
  • 34. 基本ライン 「強力なプラットフォームを持つベンダーが自社ビジ ネスとカニバるエリアへどこまで攻めていくか」と いう話
  • 35. AppleがMobile Safariでの asm.js高速化に動くか まずあり得ない asm.jsベンチマークは、JSエンジンの力をドヤるのに 用いられる多くの他ベンチマークとは明らかに異なる 「スコアで挑発されたからこっちは更に倍速にしたぜ! ヒャッハー」という純粋なエンジニアリングの世界ではない なので、もし起こったら重要な意味を持つ
  • 36. Googleがasm.js用の
 AOTコンパイルサポートへ動くか 今のところ、まずあり得ない PNaClとDartを捨てるというジャッジに近い C++の標準ライブラリへのコール以外に特段意味 は残らない なので、もし起こったら重要な意味を(ry
  • 37. asm.js独自拡張要素 asm.js専用アプリ(パフォーマンス面でなく)の登場 現在のところ「asm.jsのコードは、最適化の施されてい ないJSエンジンでも完全に動作する」ことが売りのひ とつになっている 「じゃ、WebViewの中で」という話ではない 若干ふわっとしているけれど、これも起こると重要な(ry
  • 38. Webからのプッシュ通知 OS X MavericksではSafariにおいてサポートされた Chromeはしばらく前から実装している ではモバイルでは?まだまだ リテンションにおいてプッシュ通知が果たす役割は非常 に大きい なので、もし起こったら重(ry
  • 39. データダウンロードや オフラインキャッシュは? 「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向けのアプリとインストール向けのアプリがセグメントされていくよ うになるのか?の判断ポイントでもある
  • 40. 番外編: Firefox OS事情 大切なのは、Firefox OS=「変化を引き起こし、他者へ圧をか けていくプレイヤーのひとつ」ということ 端末販売者に推されるプラットフォームでなければ、引き起 こした変化も他プラットフォームから無視されて消えていく プラットフォームの成熟度は、端末販売者としての推しやす さに直結する バリエーションの豊富な端末が多く出荷され、結果としての バージョンアップ地獄に対する練度がどの程度まで高まって いくかを注視
  • 41. 番外編: Tizen事情 状況がよく分からないので、変化あれば見ていく感じ HTML5原理主義ということでもないので、PNaClアプ ローチが割とハマる感もする 車載端末用など、ドメイン特化するのであればまた別の 考え方が必要なので引き続き見ていく。 「本気でこれ行くで」となったら本気の資本と技術を投 下出来る会社が進めているので、完全な無視は筋悪
  • 42. 未来は僕らの手の中 (端末的な意味で)