HTML5 Conference 2015 悩める組込機器向けウェブコンテンツのパフォーマンス

1. 悩める組込機器向けウェブコンテンツのパフォーマンス 2015年1月25日 HTML5 Conference 2015 @futomi futomi.hatano

2. もくじ • 組込機器とブラウザー • 組込機器ブラウザーの問題 • パフォーマンスの定義 • ページのロード • ペイント領域とGPUメモリー • 画像のロード • ビデオのロード • メモリー消費 • prototype • DOMアクセス • まとめ

3. 組込機器とブラウザー

7. SBC (Single Board Computer) Raspberry Pi B+ BeagleBone Black ODROID-U3 ODROID-C1 Cubieboard 1/2 Marsboard RK3066 Radxa Rock Lite HummingBoard i1/i2 Banana Pi KDDI Open Web Board

8. 貧弱なCPUと少ないメモリ SONY Xperia Z3 Qualcomm Snapdragon 801 CPU: 4 Core (2.5GHz) RAM: 3GB Raspberry Pi B+ Broadcom BCM2835 CPU: 1 Core (700MHz) RAM: 512MB Cubieboard 2 Allwinner A20 CPU: 2 Core (1GHz) RAM: 1GB HummingBoard i1 Freescale i.MX6 Solo CPU: 1 Core (1GHz) RAM: 512GB Alcatel One Touch Fire Qualcomm Snapdragon MSM7227A CPU: 1 Core (1GHz) RAM: 256MB 近年のスマートフォンは超贅沢品

9. 組込機器ブラウザーの問題

10. テレビブラウザーの系統スマートフォン向けブラウザー事情に酷似ウェブアプリ開発の環境が整う

11. バージョンが固定 • なかなかブラウザーは更新されない • 機器のライフサイクルが長い • 古いバージョンが長期間残り続ける • いつか勝手に解決するとは思ってはいけない... http://www.bbc.com/news/technology-20957218

12. 貧弱なCPUと少ないメモリー • 処理時間オーバー • スマートフォンではサクッと終わる処理がなかなか終わらない • アルゴリズムを考え直すか、分割して処理する必要がある • メモリーリーク • スマートフォンでは気にならなかったメモリーリークがすぐに顕在化 • JSによるメモリーのお漏らしは厳重にチェックする必要がある • ブラウザーのバグが顕著に出る • 組込機器はCPUが貧弱でメモリが少ないため、PCやスマートフォンでは顕在化しない問題が起こる

13. パフォーマンスの定義

14. パフォーマンスとは • 速く • 起動を速く • 処理を速く • アニメーションを滑らかに • 少なく • メモリ消費を少なく • CPU処理を少なく • 長く • 安定動作を長く

15. パフォーマンスとは • 速く • 起動を速く • 処理を速く • アニメーションを滑らかに • 少なく • メモリ消費を少なく • CPU処理を少なく • 長く • 安定動作を長くすべてをかなえてくれる魔法の杖は...

16. パフォーマンスとは • 速く • 起動を速く • 処理を速く • アニメーションを滑らかに • 少なく • メモリ消費を少なく • CPU処理を少なく • 長く • 安定動作を長くすべてをかなえてくれる魔法の杖は... ありません！！！

17. パフォーマンスとは • 速く • 起動を速く • 処理を速く • アニメーションを滑らかに • 少なく • メモリ消費を少なく • CPU処理を少なく • 長く • 安定動作を長くすべてをかなえてくれる魔法の杖は... ありません！！！何を捨てるのか、何を諦めるのか、を決めるのも重要しかし、ちょっとした配慮でパフォーマンスを改善

18. ページのロード

19. ネットワーク処理は高コスト • ダウンロードサイズとファイル数は少ないほど良い • HTML/CSS/JavaScriptのMinify • 極端に言えば、すべてHTMLにインラインに埋め込むのがベスト • パフォーマンスと保守性のバランスを考えましょう • 極度にMinifyツールを使うとJSが動作しない場合も • CSS Spriteもほどほどに

22. Google Closure Compiler https://developers.google.com/closure/compiler/

23. ペイント領域とGPUメモリー

24. Chromeデベロッパーツール 1 2 3 ペイント領域 FPS meter

25. ペイント領域とGPUメモリー • 一般的に良く言われる手法 • ペイント領域は可能な限り小さく • GPUアクセラレーションが有効な環境ならレイヤーを活用 • 動かすだけなら JavaScript のタイマーによる位置移動は避ける • CSS Transitions と CSS Transforms の活用 • 組込デバイスだと • GPUメモリーの上限が低い • レイヤー活用は必要最小限に • ペイント領域を可能な限り小さくするのは言うまでもない

26. コンテンツの移動 setTimeout() と left プロパティによるアニメーション CSS Transitions と CSS Transforms の translateX() によるアニメーション移動のたびにペイント処理が実行され不効率レイヤー処理により移動がスムーズかつGPUメモリー消費が少ない

27. レイヤーの使いすぎに注意 • 組込機器のGPUメモリーはさほど多くない • メインメモリーやGPUメモリーの速度もネックになる • 特にフルHDなど広い解像度を扱うコンテンツでは要注意 • 使いすぎると返って不効率

28. 値のリアルタイム更新 <p>経過時間： <span id="t">0</span> ミリ秒。</p> var el = document.querySelector("#t"); (function countUp(now) { el.textContent = Math.round(now); window.requestAnimationFrame(countUp); })(); 数値のみを書き換えているのに、行全体が再ペイント JS

29. 値のリアルタイム更新 <p>経過時間： <span id="t">0</span> ミリ秒。</p> var el = document.querySelector("#t"); (function countUp(now) { el.textContent = Math.round(now); window.requestAnimationFrame(countUp); })(); 数値のみを書き換えているのに、行全体が再ペイント JS

30. 浮かせる/サイズを固定する <p>経過時間： <span id="outer"><span id="t">0</span></span> ミリ秒。</p> var el = document.querySelector("#t"); (function countUp(now) { el.textContent = Math.round(now); window.requestAnimationFrame(countUp); })(); #outer { display: inline-block; width: 100px; height: 20px; position: relative; } #t { display: inline-block; width: 100px; position: absolute; text-align: right; } JS CSS

31. 表示と非表示の切替 <body> <img id="logo" src="imgs/logo.png"> <footer>...</footer> </body> var el = document.getElementById("logo"); var hidden = false; window.setInterval(function() { hidden = !hidden; el.style.display = hidden ? "none" : "block"; }, 1000); ロゴしか切り替えていないのにリフローの発生よりページ全体が再ペイントの対象に実際に見た目にリフローがなくても、ブラウザーは再レンダリングを行おうとしてしまう。 JS

32. CSSで位置固定 #logo { position: absolute; } <body> <img id="logo" src="imgs/logo.png"> <footer>...</footer> </body> var el = document.getElementById("logo"); var hidden = false; window.setInterval(function() { hidden = !hidden; el.style.display = hidden ? "none" : "block"; }, 1000); JS CSS

33. 画像のロード

34. img要素のloadイベント http://www.w3.org/TR/html5/embedded-content-0.html#the-img-element HTML5仕様曰く： If the download was successful and the user agent was able to determine the image's width and height, [...] fire a simple event named load at the img element. ダウンロードが成功し、ユーザーエージェントが画像の幅と高さを判定できたら、 [...] img要素で load という名前のシンプルなイベントを発出します。 loadイベントはレンダリング完了を表しているわけではない組込機器では、loadイベントの発生と、実際にレンダリングが完了したタイミングの差が大きく出る

35. 巨大な画像のロード直後の処理 • img要素のloadイベント発生直後に重い処理をするとペイント処理とかぶってしまいブラウザーが固まる場合がある • ペイントが完了したというイベントは取れない • 手を抜くなら、こうするしかない... imgElement.onload = function() { window.setTimeout(function() { // 何か次の処理 }, 100); }; JS

36. ビデオのロード

37. 組込機器には大敵なビデオデータ • 再生開始タイミングのパフォーマンスを気にするなら <video preload="auto"> • たとえ再生されなくてもバッファリング分のメモリーを消費 • 複数のビデオを事前に用意するのは厳しい • メモリーにやさしい方法を選ぶなら <video preload="none"> • 再生開始のタイミングがかなり遅れる • どうしても事前にビデオの寸法と尺を知りたいなら <video preload="metadata">

38. MP4の再生開始パフォーマンス • ファイルの最後にメタ情報が格納されている • これによって再生開始が大幅に遅れる • ブラウザーの挙動 1. ファイルの先頭を読み取る 2. メタ情報がないと判定し、ファイルの末尾を読み取る 3. ファイルの先頭に戻ってバッファリング分のビデオデータをダウンロードする

39. • エンコード時にFast Startを有効にする • メタ情報がファイルの先頭にセットされる • ブラウザーの読み取り回数が1回で済む • 再生開始パフォーマンスが向上する Fast Start

40. メモリー消費

41. メモリーリークの確認 Heap、Documents、Nodes、Listenersすべての推移の確認が重要

42. ノコギリ型のメモリー消費 • ガベージコレクションは負荷が高いためアニメーションを妨げる • 一般的にノコギリ型のメモリー消費は良くないと言われるが、それはデバイス環境とユースケース次第 • メモリーが少ない環境では、早めにガベージコレクションを発生させ、ピークを抑えるほうが良い場合もある

43. prototype

44. prototypeを使わない場合 var MyWallet = function(init_price) { this.price = init_price; this.earn = function(price) { this.price += price; if(this.price > 1000) { this.pay(this.price - 1000); } }; this.pay = function(price) { this.price -= price; }; this.look = function() { return this.price; }; }; JS

45. prototypeを使った場合 var MyWallet = function(init_price) { this.price = init_price; }; MyWallet.prototype.earn = function(price) { this.price += price; if(this.price > 1000) { this.pay(this.price - 1000); } }; MyWallet.prototype.pay = function(price) { this.price -= price; }; MyWallet.prototype.look = function() { return this.price; }; JS

46. メモリー消費に違いが出る（極端な例） var list = []; for( var i=0; i<100000; i++ ) { var w = new MyWallet(0); list.push(w); } prototypeを使わない場合 prototypeを使った場合 62MB 32MB JS

47. DOMアクセス

48. JavaScriptライブラリー • 使わない機能もテンコ盛り • 使わなくてもメモリーに展開されてしまう • できる限り機能を限定したライブラリーが良い • おすすめのJSライブラリーは...

49. http://vanilla-js.com/

50. 全機能にチェックを入れても、gzipでたったの25バイト展開したら、なんと0バイト

52. みなさん、もうお気づきですね Vanilla JS はジョークサイトです DOM 操作は素で書くのが最もパフォーマンスに優れます

53. まとめ

54. • 流行りのライブラリーやプログラミング手法が良いとは限らない • メモリーが潤沢な環境を前提としていないかを考えるべき • レガシーな手法も見直そう • メモリーが少ない時代に考えられた手法は今なお組込デバイスでは有効

56. ご清聴ありがとうございました @futomi futomi.hatano

HTML5 Conference 2015 悩める組込機器向けウェブコンテンツのパフォーマンス

HTML5 Conference 2015 悩める組込機器向けウェブコンテンツのパフォーマンス

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

Similar to HTML5 Conference 2015 悩める組込機器向けウェブコンテンツのパフォーマンス

Similar to HTML5 Conference 2015 悩める組込機器向けウェブコンテンツのパフォーマンス(20)

More from Futomi Hatano

More from Futomi Hatano(13)

Recently uploaded

Recently uploaded(12)

HTML5 Conference 2015 悩める組込機器向けウェブコンテンツのパフォーマンス