Facebookアプリを、HTML5でどうしてサクサクにできたのか。Sencha Touch開発チームが用いた3つのテクニック

Sencha Touchの開発チームがHTML5で高速に動作するFacebookアプリを開発したことを紹介した1つ前の記事 「Facebookのモバイルアプリが失敗した理由はHTML5のせいじゃない。HTML5でサクサク動くFacebookアプリを作って見せたSencha Touch開発チーム」は、非常に多くの読者に注目されました。

この記事で紹介したSencha Touch開発チームのブログ「The Making of Fastbook: An HTML5 Love Story」の後半では、どのようなテクニックを用いて高速なHTML5アプリケーションを実現したのかも紹介されています。

この記事では、その3つのテクニックについてポイントを紹介したいと思います。タイムラインやニュースフィードのようなユーザーインターフェイスを備えたモバイルアプリケーションは、これから広く開発されていくことになるはずです。その際に参考になるのではないでしょうか。

DOMツリーを分離して小さく

1つ目のテクニックは、iframeを用いてDOMツリーを分離して小さなものにしておくことで、レンダリング速度を落とさないことでした。

Facebookアプリの典型的な処理は、ニュースフィードをどんどんスクロールしていくことです。どこまでスクロールされるか分からない無限のコンポーネントリストを実装しなければなりません。

しかしSencha Touch開発チームはこの部分の開発は容易だったと説明しています。

It started with the implementation of an Infinite List Component that handles items with unknown sizes. Only a very small set of DOM nodes is actually created to fill in the actual visible screen area. They will then be constantly recycled to render next / previous data on-demand. As a result, memory footprint is kept minimal, regardless of the amount of data in the Store. Making this work is the easy part.

どこまでスクロールされるかわからない、無限リストコンポーネントの実装では、実際には画面表示に対応した小さなDOMノード群が生成される。このノード群が次ページ、前ページのレンダリングに合わせて常時再利用されることで、どれだけデータがサーバに保存されていてもメモリ利用量を最小化する。この部分の実装は比較的容易だった。

難しいのは、多様なアイテムを高速にレンダリングさせるための部分だと。

Making it fast with the complexity and variety of items such as News Feed stories is the real challenge. The bottleneck lies within the core processes that a browser has to perform: layout and compositing.

困難なのは、ニュースフィードには多様なアイテムが含まれていることだ。ボトルネックはこの中心となるプロセスにあった。それはブラウザがこのアイテム群を組み合わせてレイアウトしなければならないところだ。

そこで用いたのが「サンドボックスコンテナ」というテクニック。

So the Fastbook app is the first to make use of a brand new “Sandbox Container” which programmatically detaches complex views and renders them into their own iframes, and thus partitioning the DOM tree.

Fastbookでは、新しい「サンドボックスコンテナ」を用いた。これはプログラム的に複雑なビューとレンダリングを独自のiframeに引き離すことで、DOMツリーを分離する。この特別なコンテナはアプリケーションレベルでは特別な操作は必要ないため、デベロッパーにはシームレスだ。

サンドボックスコンテナによって部分ごとのレイアウトが分離され、それによってプライマリのDOMツリーが最小化されたことでレンダリングの高速化が実現できたとのこと。ただしこのサンドボックスコンテナの実装自体は難しかったとのことでした。

TaskQueueで不必要なレイアウト処理を停止

2つ目のテクニックは、不必要なレイアウト処理などを止めてしまうこと。

Next, we added deeper integration to our TaskQueue, a feature we recently introduced into Sencha Touch. TaskQueue prevents the interleaving of read and write requests to the DOM, eliminating any unnecessary layouts. This, combined with the new sandboxing technique, significantly reduces costly layouts from complex views such as the Timeline and News Feed.

次に、私たちのTaskQueueとの統合を行った。これはSencha Touchで最近導入したもので、DOMへのリード／ライト要求の合間で行われる不必要なレイアウト処理を防止する。TaskQueueとサンドボックスコンテナを組み合わせることで、タイムラインやニュースフィードのような複雑なビューのレイアウトが劇的に軽くなる。

また、アニメーション処理なども不要な場合には一時停止させるとのこと。

We then added the AnimationQueue, a new class that's responsible for all animations and events, as well as scheduling heavy tasks for later execution during the CPU's idle time.

さらにAnimationQueueも追加した。すべてのアニメーションとイベントを司り、ヘビーな処理はあとでCPUがアイドルになったとき実行するようにした。

これによって、ニュースフィードが高速でスクロールしているときには、イメージのロードやレンダリングは一時停止するようです。

入出力処理はWebWorkersで止めない

3つ目のテクニックは、WebWorkersを用いてデータの受け渡し部分をUIと分離したこと。

On the other hand, there are some classes of functionality that you don't want to suspend, such as getting more data to feed the list. To help ensure this doesn't slow down scrolling, we use Web Workers. These allow us to move XHR/RPC communications away from the UI thread. Saving network request cost and JSON encoding/decoding using Web Workers makes great use of today's multi-core devices.

一方で、例えばリストへのデータ取得処理など、いくつかの機能はサスペンドさせたくない。このためにWebWorkersを用いてXHR/RPCをUIスレッドから分離した。マルチコアのおかげでネットワーク処理やJSONのエンコード／デコードはWebWorkesによって十分に確保できた。

これによって、高速なスクロールに追いつくだけのデータの入出力処理を実現することになったのだと考えられます。

WebViewではなく、Safariだから速いのでは？

この元記事のコメント欄には、読者から「Safariで実行するから速いのであって、ハイブリッドアプリにしてWebViewで実行すれば遅くなるのではないか？」という指摘も行われていました。iOSでは、WebViewのJavaScriptエンジンの実行速度がSafariに比べて遅いことが知られています。

Sencha Touch開発チームのマネージャ Jamie Avins氏は、この手のアプリではJavaScriptの実行速度よりもレンダリング処理のほうがずっと重要であること、そしてWebViewでの確認をするつもりであることを返答しています。

@hlb
The demo is really promising, but it is in MobileSafari. When you make an iOS app, you can only use WebView, which is a second-class and slower browser.

デモは非常に有望だが、しかしMobileSafariで動いている。iOSアプリではWebViewという二級品しか使うことができないはずだ。

このコメントの指摘に対してAvins氏が返答（以下は2つの返答を組み合わせています）。

Jamie Avins
hlb the issue is NOT JavaScript. It’s the DOM. The DOM engine is the *same* for both use cases.

問題はJavaScriptの部分ではなく、DOMにある。DOMエンジンはどちらも同じだ。

We’ll wrap it to verify. Try to keep an open mind that the GPU compositing is MUCH more important than the JS for this type of application.

確認のためラップしてみるつもりだ。考えてみてほしいのは、この手の処理において、GPU合成処理はJavaScript処理よりもずっと重要だという点だ。

コメント主もGPU部分が重要だという点には同意した模様。

@hlb
@JamieAvins I am totally agree with you on the GPU thing and heart HTML5, but need a fair test result to convince others

GPU関連がHTML5での核心だという点にはまったく同意する。けれどフェアなテスト環境はぜひ試していただきたい。