HTML5 Conference 2013に行ってきたので全体の感想と面白かったセッションの情報を公開します

去年に引き続き、HTML5 Conference 2013に行ってきました。運営に携わった皆様お疲れさまでした。

ということなので、全体の感想とセッションの感想・アウトラインメモを公開します。

目次

  1. 全体の感想
  2. 面白かったセッションの感想とアウトラインメモ
    1. ようこそ、HTML5裏APIの世界へ
    2. 実践的なモバイルHTML5テクニック

全体の感想

今回良かったところを挙げると以下の3つかなと思います。

  • ネットワーク環境の改善
  • 食べるところが少なすぎるのを補うおにぎりやドーナツ類、そしてレッドブルの提供
  • マイクロバスがちゃんと定期的に来ていた気がする

特にネットワーク環境は、前回は提供されたWifiがほとんどつながらず、SSIDの数がカオスな状況になっていましたが、今回は少なくともTwitterをストリーミングさせて見ていても問題ない(サムネイルなども引っかかりなく表示される)感じでした。これは本当にネットワーク担当エンジニアが凄いとしか言いようが無いですね。ありがとうございます。

あと、昼ごはんを食べずに来てしまい、かつバスの中でマックテロを喰らい、お腹が空いて終わりまで持つのかこれという状況になってしまいましたが、おにぎりとドーナツの提供があり、なんとかなりました。ちなみにおにぎりは3個いただきました。あと、1Fの入り口付近でPixelGridの2人と寒い思いをしていたらカイロを提供されて助かりました。ありがとうございます。

なお、今回悪かったところを1つだけ挙げると、最後のクイズが20人限定の参加となってしまったところです。とはいえ、前回全員参加の早押しクイズでカオスになったのと、2000人という規模を考えると、しかたないのかなと思います。特に代案も浮かびませんし…


面白かったセッションの感想とアウトラインメモ

ここからは自分が面白いと感じたセッションの感想とアウトラインメモを公開します。

ようこそ、HTML5裏APIの世界へ

  • スピーカー: 羽田野 太巳(@futomi)
  • 資料: http://www.slideshare.net/futomihatano/html5api-28774403
  • 感想: 今まで存在を知らないAPIばかりが紹介され、そしてデモもあり、とても分かりやすくかつ何に使えるか実際の使用用途を考えられてよかったなーと思ったセッション。WebAudio API PannerNodeなんかは加工されていない救急車のサイレン音が、APIを通すことによりドップラー効果がついたように聴こえ、本当にすごいと思うとともに、ゲームアプリで使えるかも?と感じました。「真面目なアニメーション」と「WebSocket, WebRTC, Socket API, ... 最新Webプロトコルの傾向と対策で迷ったもの」と当セッションでどれに行くか迷ったけど、自分的にはこれに行って正解でした。

マニアなAPIとは

  • 使ってもすごさが分からない
  • 仕事になるかも分からない
  • なくなるかもしれない

マニアレベル1(割とモテ系)

WebRTC DTMF(Dual-Tone Multi-Frequency)

  • 早い話がSkypeをWebで
  • 映像/音声/データのP2P接続
  • IP電話の知識が必要(特に呼制御)
  • ダイヤルトーンを発信できる(自動音声応答装置の代わりになる)
  • 電話を持たなくても、ブラウザーからコールセンターに電話できるようになるかも

WebAudio API PannerNode

  • 音源の生成や合成
    • ゲーム系コンテンツにいいかも(iOSなどで複数音源の同時再生に重宝する)
  • 高精度な再生タイミング
  • 各種オーディオエフェクトやアナライザー(楽器のチューナーなど精度重視なところには向いていない)

本格的なオーディオ信号処理

  • 立体音響
    • PannerNode
    • ドップラー効果のデモすごい!(音源にドップラー効果を付けてなくてもWebAudio API通すと効果がつく)

Media Source Extensions

  • IEのみ?
  • HTTPアダプティブストリーミング配信
  • セグメントに分割されたビデオデータをvideo要素に流し込むだけのAPI
  • MPEG-DASH
    • HTTPベースのAdaptive Streaming
    • 普通のウェブサーバーでも動作
    • XML baseのメタ情報(MPD)
    • プレイヤーは自分で作らないといけない
    • エンコーディングの知識が必要
    • GPAC MP4Box(セグメントファイルの自動生成)

Media Capture and Streams

  • Chromeのみ
  • Windowsで実行するとOSごと死ぬらしい
  • デモ: スクリーンキャプチャーのなかでスクリーンキャプチャー(合わせ鏡的な)
  • サイネージの監視やヘルプデスクでも使えるかも

マニアレベル2(縁の下の力持ち)

Encoding

  • 文字コードのデコード、エンコード

Web Cryptography API

  • データの暗号化・複合化(公開鍵方式)
  • 使われているサイトもあるらしい

DOMMatrix

  • 行列計算
  • グラフィックにおける座標変換

Transferable objects

  • データ転送(WebWorker的な)

マニアレベル3(使用用途が分からない系)

Clipboard API

  • どんなものがペーストされたか分かる
  • Web上でやる意味 is 分からない

Base64 utility methods

  • エンコードとデコード
  • 現状対応しているのはASCII文字だけ(バイナリどころか2byte系も入らない)

マニアレベル4(モテ系になるかも)

Screen Orientation

  • Firefoxのみ
  • オリエンテーションを固定
  • つまり画面固定がブラウザのみでできる
  • FullScreen APIを使ったときのみ使える

MediaStream Recoding

  • Firefox Auroraのみ
  • 録画と録音
  • Blobオブジェクトとして試せる

Web Animations 1.0

  • 実装ブラウザーはない代わりにweb-animations-jsというpolyfilがある
  • タイムライン制御フレームワーク
  • 連続処理と並列処理
  • ビデオを扱うかのごとく使える

実践的なモバイルHTML5テクニック

  • スピーカー: 紀平 拓男(@tkihira)
  • 資料: http://www.slideshare.net/takuokihira/html5-conference-2013
  • 感想: 紀平さんはインストールが嫌という主張を前からしていて、Webでいろいろ頑張っているイメージなので、日頃Webで出来るゲームアプリを提供している立場上、興味があって話を聞きにいってみましたが、かなり泥臭いことをしていることが伺えて、本当にすごいと思うとともに、この今の状況が少しでも改善されないものかと改めて思ってしまいました…少しでもAndroid 2.xのシェアが減るのと、Android 4.4(KitKat)の対応端末が増えることを祈りたいですね。

※上に挙げている資料を見ることをおすすめいたします。下記のアウトラインメモは概要を掴みたい時にお読みください。

話す内容

モバイルブラウザで今できること

今の状況

  • 残念ながらネイティブ >>> Webアプリ

Webアプリの利点と欠点

  • 遅い、互換性がない、ハードウェアに密着した処理がつらいという欠点が目立ってしまっている状況
  • エンジニアもあまりいない…
  • しかしインストール不要というメリットは大きい
    • ゲームをプレイして、URLをシェアするだけで友人の現在のプレイが見られる!

ネイティブアプリでは実現できないメリット

  • TwitterのURLや広告をタップで即座にアプリが起動される
  • アプリ内でURLを発行することにより、独自のシーンでアプリが起動(Google Spreadsheetがいい例)

モバイルWebの基礎

  • PCにはブラウザがそんなにない(メジャーなので5種類くらい)
  • モバイルにはブラウザがもっとない(Safari, Android Legacy Browser, Android Chrome etc..., しかも全てWebkit)
  • 対応が楽…なんて嘘!

Androidの互換性

  • メーカーが自社端末に合わせて最適化したAndroidを搭載
    • 最適化の末にバグを埋め込む
  • 端末の数だけ独自ブラウザがある状況
  • IE6より対応が大変!

リッチな表現の作り方

  • Canvas
    • 互換性のバグを踏みにくい
    • 細かい最適化を自力で頑張れる
    • 作りこむならCanvas
  • CSS(+DOM)
    • 慣れ親しんだ形式、コードが読みやすい
    • ブラウザの高速化恩恵を受けられることが多い
    • ちょっとしたアプリならCSS

オンメモリCanvasの利用

  • 何度も描画に利用する部分をメモリ上に退避して、それを描画に利用

drawImage

  • 画像を描画する際、小数点の位置に描画しない
    • 小数点の位置に描画するとアンチエイリアシングがかかる
    • 描画のスピードが遅い
  • 拡大、縮小をせずに描画する

new Functionによるオーバーヘッドの削減

  • 同じ図形をパス(moveToやlineTo)を駆使して描画する場合に、描画用データを毎回解析せず、最初に文字列として関数を作成して、それを関数化することでオーバーヘッドを防ぐ

GPUを意識した高速化

  • GPUキャッシュに描画する画像が乗るように意識する
    • 一定時間の間にブラウザに使われる画像を意識
  • CanvasはGPUキャッシュに乗ることはない。これ以上変更しないというCanvasはimg要素に変換する

互換性問題の解決

  • 何か問題が起こったら、ブラウザを過信しない。徹底的に疑う
  • ブラウザの気持ちになって考える
    • 内部でどのような処理をしているせいでこうなったか
    • 全体からコメントアウトしていって問題箇所を発見するか、小さなサンプルを作って、最小単位で問題を探る

メモリの問題

  • メモリを使い過ぎない
    • iOSは落ちる、Androidはサボる
  • メモリリークをしない
    • ブラウザのガベージコレクションに回収されるよう気をつける
    • メモリを確認して、メモリが微増するところを突き止める

バッテリーの問題

  • 描画する部分が大きければ大きいほどバッテリーの消費が大きくなる
  • 描画しないところは描画系のコマンドを呼び出さないようにする

鉄則

  • 高速化もメモリ管理も、実際のデータをもとに確認
  • どうしようもないこともある。非対応端末に突っ込む勇気

デモ

ダンジョンポッパー - Mobage(モバゲー)by DeNA(Canvasで頑張った例)

まとめ

  • アプリでは絶対に達成できないメリットもブラウザにはありつつ、デメリットが多くある状況
  • HTML5らしさを出したWebアプリはほとんど出ていない(日本がモバイルHTML5が一番進んでいる)。なので今がチャンスかも
  • 将来、ネイティブアプリからWebに置き換わるのはほぼ確実
  • HTML5のメリットをフル活用して、欠点の少ないアプリを簡単に作れるようになったら世界を制すことができる