FacebookのHTML5アプリは何が時期尚早だったのか。「クラッシュの原因も分からないし、スクロールも遅すぎる」

Facebookは、HTML5ベースで開発したiOSのアプリの動作速度が遅くて不評を買っていたため、8月にネイティブアプリケーションとして作り直したアプリへと切り替えました。

Publickeyは先週の記事「ザッカーバーグ氏の「HTML5に賭けたのは失敗」発言には続きがある。長期的にはHTML5への期待も語る」で、このことを通してCEOのザッカーバーグ氏がHTML5についてどう考えているのか、TechCrunchのインタビューでのコメントを紹介しました。

一方で、このHTML5アプリの開発を行っていたFacebookのエンジニアTobie Langel氏は、Facebookが開発したHTML5ベースのアプリが遅かった理由は何なのか。開発上でどこに課題があったのかを、W3CのメーリングリストCore Mobile Web Platform Community Groupに、「Perf Feedback - What's slowing down Mobile Facebook」（パフォーマンスフィードバック - なにがFacebookモバイルを遅くしていたのか？）に投稿し、説明しています。InfoQの記事「Facebook:「HTML5に賭けたのは間違い」発言の技術的な理由と反応」」で紹介されていました。

こんどは現場のエンジニアの声を、投稿されたメールから見ていきましょう。

Langel氏は開発ツールやAPIがまだまだ十分ではなく、そのことが高性能なHTML5アプリを開発する上での課題だと結論づけています。

クラッシュの原因が分からない

Langel氏は冒頭でまずツールの不足を訴えています。

The lack of tooling in mobile browsers makes it very difficult to dig down and find out what the real issues are.

モバイルブラウザのツールが不足しており、それが何が本当の問題なのかという原因究明を非常に難しくしている。

これによって、クラッシュの原因すら分からないと。

The biggest issues we've been facing here are memory related. Given the size of our content, it's not uncommon for our application to exhaust the hardware capabilities of the device, causing crashes. Unfortunately, it's difficult for us to understand exactly what's causing these issues. GPU buffer exhaustion? Reaching resource limits? Something else? hard to say.

私たちが直面した最大の問題は、メモリ関連だった。あるコンテンツがあるとき、それがデバイスのハードウェア能力を枯渇させ、クラッシュさせてしまうことは珍しくない。残念ながらそのときに何がクラッシュを引き起こしたのか、GPUバッファの枯渇？ リソースの上限？ あるいは他の原因か、それを知ることは非常に難しい。

そのため、ヒープサイズ、オブジェクトカウント、ガベージコレクションサイクル、GPUバッファサイズ、リソース上限といった値を取得できることが望ましいとしています。

Facebookユーザーならお分かりと思いますが、Facebookのアプリケーションというのは基本的にタイムラインをスクロールしていくとテキストや画像が次々に表示されていきます。ということは、単純に実装すればスクロールするごとにアプリケーションの使用リソースがどんどん増えていくわけです。リソースを適切に管理することは、たしかにFacebookアプリにとって大事な要素でしょう。

スクロール性能が十分ではない

2つめの指摘は、スクロール性能が十分でなくスムーズでない、という指摘です。結局JavaScriptで全部実装したとのこと。これもFacebookのユーザーインターフェイスを考えると重要なポイントでしょう。

This is one of our most important issues. It's typically a problem on the newsfeed and on Timeline which use infinite scrolling (content is prefetched as the user scrolls down the app and appended) and end up containing large amounts of content (both text AND images). Currently, we do all of the scrolling using JS, as other options were not fast enough (because of implementation issues).

これはもっとも大きな問題の1つだ。無限にスクロールしていくニュースフィードやタイムラインの典型的な課題であり、それにつれて大量のコンテンツ（テキストや画像の両方）が含まれることになる。現在のところ、私たちはスクロール機能のすべてをJavaScriptで実現している、ほかの選択肢は十分に速くなかったためだ（実装上の問題が原因だ）

この問題に対しては、スクロール性能に影響せずにイベントを発火させたり、I/Oや計算をバックグラウンドで実現したり、スクロールする画面に対して動的にコンテンツを追加できたり、といった要件の実現が求められるとしています。

GPUがブラックボックス

3つ目の指摘がGPU。

Currently, the GPU is a black-box (which from what I understand is what vendors would like to keep it as). In truth however, developers rely on tricks[5] to force given content to be hardware accelerated. So it basically a black-box with a clunky API to add things to it.

現時点で、GPUはブラックボックスだ（ベンダーがそうしておきたいのだと私は理解している）。けれど実のところ、デベロッパーはハードウェアによる高速な描画をなんとか実現するためのトリックに依存している。基本的にはブラックボックスに対して出来の悪いAPIがあるだけだ。

結局こうした課題を克服するには、現時点でネイティブアプリケーションにするしかない、という判断でFacebookはネイティブアプリケーションへと切り替えるわけです。

しかし、この課題をそのままにするのではなくW3Cのメーリングリストで共有し議論することで（一部はすでに別のワークグループに持ち込まれているとのこと）、よりWebを進化させていくきっかけにしている。この点は素晴らしいことですし、こうして各種の標準仕様は揉まれて（遅まきながらも）進化していくのでしょう。