HTML5カンファレンス
HTML5カンファレンスでボランティアスタッフしました。 設営なのでカンファレンスが開かれている間はフリーダムです。
単純にカンファレンスにスタッフ側で関わると楽しいので、手伝える事とか有ったら参加するの良いなーとか思いました。 あとLTできる人になりたい、とも。
ざっと感想をまとめます。
WebSocket, WebRTC, Socket API, ... 最新Webプロトコルの傾向と対策(小松 健作)
今回の話題のうちSPDYの話の準備で以下の流れを押さえておくと言い。
- 不満があるよ
- HTTP遅い
- リクエストをまとめたりする
- CSS Spriteとか辛い
- TCPコネクション1つに複数HTTPSリクエストをまとめられれば自然だね これがSPDYだ!(上の方法のうちの1つだけどね)
- 単純にSPDYを使えば問題ない? <- これ!!
実例としてネットワーク遅延がある場合をエミュレートして確認していた。
- 重い画像を大量(150枚くらいだったはず)にダウンロードする状況
- ネットワークに50ms 遅延がある(OSXだとipfwでエミュレート)
結果はHTTPSが3[sec]に対してSPDYは14[sec]かかった。 SPDYの方が大分遅い。
理由は Long Fat Pipeでの遅延。 1つのTCPコネクション内で大量に通信するため、windowサイズを越えた通信ではACK待ちにより送信タイミングがコントロールされる。 そのため、ネットワーク遅延があると通信が大幅に遅れる場合があるというもの。
ref. レイヤ4 TCP ウィンド
ipfw, qdisc便利だし通信系で簡易実験する時に使ってみようと思った。
あとSPDYでもウィンドウサイズ越える様な場合で海外にサーバー置く場合とかのケースだと検証が必要とか、
世の中簡単に行かないねーって思った。
(ガンガンクライアントからコネクションを貼られないで済むからサーバーリソースは軽くなるの嬉しいかも)
モバイルHTMLテクニック(紀平 拓男)
話のテーマは「いま出来るモバイルブラウザテクニック」でした。 だいぶ泥臭く実践的な話と現状、多くの愚痴を知れた。
- モバイルHTML5
-
モバイル環境のオンブラウザなHTML5
現在は遺憾ながら、世の中HTML5は不況・ネイティブアプリ開発が活況。 海外はほぼアプリ1本だしモバイルHTMLは現状日本が先攻している。
でもブラウザだから出来るHTML5だから出来る形というのはある筈だ。 例えばMinecraftがHTML5・ネイティブそれぞれアプリが有ると仮定すると、 ネイティブアプリではSNSにシェアされた内容を遊ぶには一旦ダウンロードが発生する。 だけどブラウザアプリだったらいきなり参加出来る。 これは楽しいし少し遊んでみようと思える。とかが言われてた。
ユーザーのプレイまでのコストが小さくなる点を活かす事は出来る筈って無いようだった。 確かにほかのアプリやゲームを利用したりURLによるリソース読み込みを使うといったオンブラウザな特性を使ったゲームって あんまり無い印象がある。
とは言ってもHTMLでゲームを実装するとパフォーマンス・互換性などで不利だ。 パフォーマンスについては現状、HTML5は速度・互換性・3D/音楽の整理が進んでいる。 なので時間の問題っぽい。
テストするべき実行環境の互換性が酷い。 バグが多いよAndroid! 悲しいねって言われてた。「Androidの対応はIE6より大変だ」 これは、ハードウェアの性能を引き出すためにベンダーがブラウザのコードに手を加えているからベンチマークは良くなるのだけど、 バグが混入するという実態が引き起こしている。
さっさとChromeとか標準ブラウザじゃなくて落としてきたブラウザを使うのが普及すりゃ良いんだって言ってて、全く同意。 もしくはFFOSですかね…
高速化の話
高速化の基本
- オンメモリCanvasを使う スプライト使いましょうみたいな感じ
- drawimageなどで整数位置を避ける"pos|0" 使う 小数点に置くとアンチエイリアスが起きちゃう
- 拡大縮小を使わない ブラウザは拡大縮小が不要の場合は高速モードで動けるので凄い早くなる
- 定型のlineTo, moveToは new Function にまとめてしまう
GPUを意識した高速化
- 画像がGPUキャッシュに乗る様に使う順序を意識する
- どうすればキャッシュに乗るかはブラウザ次第
- どの画像をどのタイミングで描写するか? 意識する
- Canvasを使って作った画像はキャッシュに乗らない
- toDataUrlを使ってimageにしてしまう -> メモリを食うけど, キャッシュに乗る可能性がある
- 使わなくなったらGC対象にする様に解放する
バグの話
- JavaScriptのバグにハマる事がよく有る、徹底的にブラウザを疑う
- だいたいはベンダーの最適化コードのバグに捕まってる事が多い
- 明確に最適化出来ないとブラウザを思わせる様にすると何故か迂回出来たりする
例えばこんな事が有った
- ある2機種だけAndroidでのみ動かない
- GPU周りを疑った(理由は聞き逃した、GPU種類とベンダが共通してたとか)
- 画像の高さ・幅が2048pixを越えるとGPUに読み込まずCPUで処理される
- 崩れる画像周りのサイズを大きくしたらCPU処理になり問題が回避された
- 代入文が動かない端末が有る( a = b = c =100 みたいな連続代入)
- 雰囲気として最適化コードの一部が書き換えられスタックが破壊されてるっぽい
- なので「消すな」コメント付きの
setTimeout(\'return 0\', 0);を直前に配置
- Android を暖めたら描写が崩れる
- CPUは熱暴走しないけどGPUが熱暴走して駄目ってケース
- GPUに負荷が掛からない様に調整した
終わりに
鉄則はこれだ!
- 高速化・メモリ管理も実際のデータをもとに確認する
- ある程度は諦める
諦めるって大事ですね。
HTTP/2.0がもたらすWebサービスの進化
バッテリーが上がりそうだったので、あまりメモしてない。 HTTP2の大きな違い。テキストからバイナリに変わります。でもHTTP1.1もまだだよ
論点は色々有って全然決まってないのです。 圧縮周りでHPACKって方法を使っていてアグレッシブに圧縮するんだなって思った。
HTTP2は暗号化を必須にするか否かで協議が割れているらしい。 個人的には必須にするのは役割別な気もしている。 ただPRISM盗聴事件もあったし、その辺プロトコル屋さん達はシビアなんだろうな。
進化を続ける JavaScript 〜次世代言語のステキな機能と高速化の行方〜(浅井 智也 Mozilla Japan)
話題は2つ。
- ECMAScript6の機能
- JavaScriptがCに迫りたい
構文上の変化が遂に来るECMA6。 ブラウザの実装も徐々に進んでいる。IEは他言語などビジネスよりなのは積極的に提案・実装してくれるね。
言語機能的な変化
- 分割代入可能(オブジェクトも)
- デフォルトパラメタ(FF以外は未実装)rubyっぽい評価タイミング
- rest paramter
...restArgs - 配列の内包表記
[for (x of [1,2,3,4]) if (x\>0) x] - ブロックスコープ(let, const)
- Class入る
- Module入る
- Arrow Function入る
- Arrow Function thisを構文スコープで解決する無名関数
- Generator Functionが入る
- Promiseが入る (jQuery::Deferrd みたいな)
Rubyのブロック・無名関数のself解決が複雑な様に混乱を招くんじゃないかしらって思った。 懇親会で聴いてみたのだけど「thisの解決には不満が強いので、mapみたいに使い捨てで使う事を強く意図して導入した」って事らしい。
確かに、短命な使い方を意識しているなら良いかって思た。
use strict でArrow
Functionの代入禁止したいけど実効無いから行なわれないだろうな。。
JavascriptもCに迫りたい
FF22が asm.js を採用したって話。 これはJavaScript で早く実行される定石を明示化してまとめたサブセット言語のみたい。 ダグラスのGood Parts にあやかってFast Partsって名付けてた。センス良い。
asm.js というサブセットは指定して使うという事は既存の高速化の定石を使っている事を明示する様なもの。 型情報をコンパイル後のバイトコードから除去したりとかを行ない易くするらしい。 動的型付けの為にタグ付き共用体を使うのは重いから外せるところは外したいって事なんだけど、
asm.jsによって特定コンパイル単位内で動的特性を失うってのは英断よね。
使い方はコード内にuse asmを入れる。
ref.
Web Audio API実践的プログラミング
Audio関連APIの紹介。単純に楽しかった。 ハマりどころは
- Oscilator, とかは使い捨てなのでcrateする
- Panは3次元で2次元Panを使うのは結構難しい
- 仕様に変更があったAPIの名前は新しい方を使う (FFが古い名前だとサポートしてなかったり)
- 音のプログラミングはテストが難しい