Tobie Langel「ios向け旧facebookアプリが遅かった件」
2012.9.15 public-coremob@w3.orgへのポスト
Perf Feedback - What's slowing down Mobile Facebook from Tobie Langel on 2012-09-15 (public-coremob@w3.org from September 2012)
- facebookがiosアプリをネイティブで作りなおした件について
- facebook.comにもポストした内容から、さらにパフォーマンスに話を絞って掘り下げた内容書いてて面白い
- この投稿自体にはレスが付いてないがinfoQがこのポストをネタに記事書いてて勉強になった
以下斜め読んだ内容
- ネイティブのiosアプリのリリース。なんで出したのか記事だした
- Under the hood: Rebuilding Facebook for iOS
- facebookが直面したパフォーマンス上の問題
- 詳しい説明が欲しいというリクエストが多い
- ということでポストした
開発ツール、開発用API
- ツールが無さすぎで、問題の切り分け大変すぎ
- facebookが直面してる問題はメモリに関係してるとみていた
- コンテンツのサイズがある大きさにになる
- アプリがデバイスのハードウェアのリソースを使い尽くしてクラッシュする
- こんなことがよく起こっていた
- 何が原因でクラッシュが起こってるのか突き止めるのがとても難しい状況だった
- GPUバッファを使い尽くしたからなのか
- リソース制限に到達したからなのか
- 他に原因があるのか
- 見極めるのが難しい
- デバイスに開発ツールが付属してない
- リモートでアクセスできるツールがない
- html5ベースのアプリ開発してるときに知りたかった(が手の届かなかった情報
- ヒープサイズ
- オブジェクトの数
- GCのサイクル
- GPUバッファのサイズ
- リソースの制限
- こういう情報は開発を終えた後でも有益な情報なはず
- 例えば。linkedin
- リソース制限(=メモリに載せれる画像の量)をチェックするために、ハックしてしのいでる
- LinkedIn for iPad: 5 techniques for smooth infinite scrolling in HTML5 | LinkedIn Engineering
- (補足)
- ネイティブのAPI( UITableViewController、 UITableView、 UITableViewCells)で享受できる高いパフォーマンスやメモリ効率の良さ
- これをhtml5ベースのipadアプリでどうやって手にするか
- linkedinのipadアプリの目玉UIのinfinity swipeの実装に施したハックの数々
- スクリーンの外にある要素に対して、スクリーンに近い順に、画像置換(src値のreplace)、隣のページへdisplay:none、さらに横のページにはページをremove
- 「display:none」とsrc置換の2つでクラッシュするケースの8割は解決できた
- 小技としてimgにwidth/height指定してauto-scale発動回避とか、css box-shadow禁止とか
- 没案として、UIWebVeiw複数使ったらダメだったとか
- linkedinはそうやってアプリのクラッシュを回避してると記してる
- (補足)
- デバイスのメモリリソース情報についてアクセスできるAPIがあった方がいい
- 認証必須だとしてもAPIがあった方がいい
- fps
- ハードウェレベルでのfpsが測定できない
- これはアプリのテストに致命的
- ACTION-27: Fluidity of motion and consistency of framerates from Robert Shilston on 2012-08-13 (public-coremob@w3.org from August 2012)
- 例えばUIデザインでinfinite scrollingにするかpagenationにするか決めたい時とか
- fingerprintingの点で注意すべきなのは承知してる
スクロールのパフォーマンス
- このパフォーマンス上の問題についてはw3cのworking groupで議論始めてる
- これも重要な問題の1つ
- タイムラインを流れるnewsfeedで問題になる
- inifinite scrollingを使ったUI
- ユーザのスクロールに合わせてコンテンツを先読みしてコンテンツを継ぎ足してる
- どんどん継ぎ足してると、コンテンツの総量がとても大きくなる(画像、テキスト)
- 現時点の実装ではjsでスクロールを実装してる
- 他の実装では速度でない
- 他の実装では色々問題がある
- 実装でぶつかってる問題を箇条書きで
- 必要なものを箇条書きで
- スクロールは高速かつ滑らか
- ユーザのengagementには必須
- ユーザが読み込み済みコンテンツの下端に近づくと、定義済のイベントを発行され、ンテンツが先読みされ、位置が算出され、継ぎ足される
- 滑らかなスクロールを殺すことなく、スクロール中も新規に読み込まれたコンテンツが継ぎ足される
- i/o処理や計算をバックグラウンドで実行できること
- 滑らかなスクロールを殺さないため
- たくさんコンテンツがあっても滑らかなスクロールを維持できること
- 画像が沢山あっても維持できること
- こんなAPIが欲しい
- 現状ブラックボックス状態で、わずかなハックが使えるだけ
- エンジニアはハックに頼ってハードウェアアクセラレーションを使ってる状況
- David Walsh考案
- Force Hardware Acceleration in WebKit with translate3d
- GPUバッファのサイズはデバイスを消費してるコンテンツサイズに相対的?
- だとすればの話だが
- GPUの管理がブラウザに委ねられた状態が相当な間理にかなった形で続くことになる
- とはいえGPUにアクセスできるAPIを提供する点についてはpro/con色々ある話
その他足りないもの箇条書きで
- タッチイベントのトラッキングの精度向上。特にandroidで
- よりスムーズなアニメーション。常に重要
- キャッシュ性能の向上
- app cacheは実用レベルにない。使わないことにした
- MoPad: appcache-london
- (補足)
-
- FT labがホストになって2012.8.14開催されたmeetupのログ
- FT、Economist、facebook、google、Lanyrdなどモバイル用html5アプリ経験のあるエンジニアが参加
- 事例紹介し、オフラインのストレージ機能のハマった点、ハック、どこに使ってるかとかと共有
- ノウハウ共有から進んで、app cacheが本来持つべき機能(jsからキャッシュの更新・削除できるapi用意するetc.)、ダメなとこ(master entriesは元凶だ、etc.)、詰め切れてないとこ(キャッシュの適切なサイズについて「これくらいだろ?」という感覚が共有できてないetc.)
- w3cに整理整頓されたver.あり
- Meeting notes 14 August 2012 - Fixing Application Cache Community Group
-
- (補足2)mountain viewでも同じ趣旨のmeetupが2012.9.24に。twitter,MSも参加