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

2012年9月26日

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

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

Perf Feedback - What's slowing down Mobile Facebook from Tobie Langel on 2012-09-15 (public-coremob@w3.org from September 2012)

一方で、この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を進化させていくきっかけにしている。この点は素晴らしいことですし、こうして各種の標準仕様は揉まれて(遅まきながらも)進化していくのでしょう。

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : Facebook , HTML5 , モバイル



≫次の記事
「クラウドにこそ必要なSIがある」、地場の小規模SI案件などが増加。サイボウズが支援プログラムを発表
≪前の記事
[速報]アドビがHTML5とモバイルにフォーカスした新ツール群「Adobe Edge Tools & Services」を発表。アニメーション作成、レスポンシブデザインなどが効率的に

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus