行ってきましたレポ。
大学の授業みたいで懐かしい感があったｗ
言うまでもなく1限は滑り込みセーフです。
以下、聞いたやつリスト。
- 基調講演
- Room A: プリンより滑らか。スムーズなアニメーションの作り方。
- Room C: Web: Reboot
- Room E: 2015年これからの日本のWebサイトパフォーマンスについて
- Room B: Web Audio API、 Web MIDI API を使ったサウンドプログラミング
- Room A: HTML5ハイブリッドアプリ開発のベストプラクティス
- スペシャルセッション
基調講演
慶応大学の村井教授から。
指先サイズのCPUが、HTMLやHTTP/TCP/IPを解釈する時代がきました。
Internet of Things(IoT)から、Web of Things(WoT)へという話。
日本はアメリカに比べて、ITサービス企業 : ユーザー企業のエンジニアの就業比が低い。
これからのWebを活用するならユーザー企業では・・みたいな。
Googleの及川さんからは、2015年のWebの展望について。
今年はWebの在り方が変わる一年。
PCが単にhttpでServerにリクエストするだけの今までから、
ServiceWorkerやらWebSocketなPCはもちろん、
PCだけでなく様々なハードがあちこちのリソースとつながるこれから。
ITデータを活用できてる日本企業は少ないとも。
これからのWebはIT企業からじゃなくて、ユーザー企業から！って感じなんですかねー。
プリンより滑らか。スムーズなアニメーションの作り方。
業務的にこの分野はホット(色んな意味で)なので、期待してたけど・・！
アニメーションの実行の裏側で、ブラウザは何をしているか、
どうすれば滑らかなアニメーションを実行できるかという話。
Reflowについて
パフォーマンスに関わる重要な部分。
例えばmarginは、変更すると周りの要素にも影響がある -> Reフローを引き起こす。
これに注意する。
ちなみに、FireFoxのDevToolsにはReflowをログで出す機能があって、中々良い感じっぽかった。
- margin-leftの変更はReflowを引き起こす
- pos: rel/abs + leftを変更してReflowするかは、ブラウザ次第
- transformはブラウザ問わずReflowしない
そのほか、getComputedStyleとかReflowするAPIを使ってしまうともちろん遅い。
滑らかアニメは描画コストを削るべし
どうすればいいかの以下3つ。
1. 領域を縮める
"Show print rectangle"ってオプションがDevToolsにあるはず。
それで、動かす必要のない部分は動かさないようにする。
2. 軽い処理にする
box-shadow/radius/blurとか、描画コストが重いものは使わない。
SVGもiframeで使うのは重いがimgなら軽い(今のFFは特に軽い)ってかpngでやる。
案外見せかけで騙せる部分は多いはず。
より軽いアニメーションとは
transform/opacityであれば、コンポジターで対応できるので、
jsアニメーションよりもcssアニメーションのほうがスムーズ。
コンポジターってなんぞやって思ったけど、
さっきの例みたくGPUのComposite Layerで処理できるやつらってことかしら？
2015年これからのWebパフォーマンスについて
パネルディスカッションって行くまで知らんかった・・。
なんかただ立ち見がでるほど激混みしてた。
大手ECサイトのダウンロード時間を比較する
PC@IEだと、
- 国内: 2s-
- 国外: 1s以下
海外はやいですね。
Mobile@iPhone6/3Gだと、
- 国内: 7.4s-
- 国外: 1.71s以下
日本氏ー！
というわけで、パフォーマンス後進国ですと。
パフォーマンスチューニングとは
Amazon.co.jpのファーストペイントまでの時間の例。
2015/01/22までは2.5s以内だったが、この日を境にバラけてきてる。
原因はさておき、長期的に観測してないとこの事実には気付けない。
パフォーマンスチューニングは単発でやるのではなく、長期的に取り組むべきもの。
"機能"とは別に"性能"の観点で、品質管理をすべき。
ネットワークをこえて、速いか遅いかまで確かめてこそのパフォーマンス。
普段の開発(日中)は速くても、実際に使われるであろう時間帯(夜とか)に遅いなら、その速さには意味が無い。
こういうものには、統計学的アプローチが有効。
パネル
の内容に関しては知ってることばかりであまり収穫なしでした。
・・・奥さんやっぱPerl書いてる場合じゃないっすよ！
最後に、制限があるほうがクリエイティビティは発揮できる！論のもと、
以下のページ容量を目安にしてみると良いのではって言ってた。
- PCなら1MB
- Mobileなら100KB
お、おう・・。
Web Audio API、 Web MIDI API を使ったサウンドプログラミング
完全に趣味ですが、最近は音関連に熱があるので聞いてみた。
内容に目新しいのはなかったけど、MIDI鍵盤買おうかなって思った。
スライドはこちら。
HTML5ハイブリッドアプリ開発のベストプラクティス
ハイブリッドアプリとは
HTML5 x JavaScriptが動くWebViewを、ネイティブでくるむもの。
XamarinとかTitaniumとかとは違う。
ハイブリッド or ネイティブ？判断ポイント5つ
1. 本当にハイブリッドで大丈夫か？
実装を共通化することが目的であればOK。
ゆくゆくは各OSに特化・・みたいな話になるならNG。
UI/UXを徹底的に・・！みたいなのものもちろんNG。
5. その他
- Cordovaのドキュメントは読むべし
- 各ネイティブの知識はあったほうがベター(どうブリッジしてるかの部分など)
- Web側のパフォーマンスに関する知識
周辺機器もご一緒に
Cordovaを使う上で
デバッグの仕方
- Android4- x Chromium WebView
- Android4.4-
この条件なら、Chrome DevToolsで見れる！
iOSならSafariで見れる。
WindowsならGapDebugってのがオススメだそうな。
開発体制
だいたいこんなウェイトのチームが理想。
- UIデザイナー: 20-40%
- フロントエンドエンジニア: 50-70%
- 各OSのネイティブエンジニア: 5-20%
セキュリティ
潜在的なバグを回避するため、できれば最新のものを使う。
AndroidならChromium WebViewを使うなど。
XSSも、JavaScript使うなら当然気をつける。
アプリのロジック漏洩に関しては、
Webと同じでソースコード圧縮するしかない。
暗号化するソリューションもあるよ！
いま感じる課題
- 開発スキル・チーム体制
- メンテナンス
- 情報不足
質問タイムあったら聞きたいことあったのにー。
他の会場の参考になる案件たち
みなさんお疲れさまでしたー。