以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

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)

以下斜め読んだ内容
  • ネイティブのiosアプリのリリース。なんで出したのか記事だした

開発ツール、開発用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

スクロールのパフォーマンス

  • このパフォーマンス上の問題についてはw3cのworking groupで議論始めてる
  • これも重要な問題の1つ
  • タイムラインを流れるnewsfeedで問題になる
    • inifinite scrollingを使ったUI
    • ユーザのスクロールに合わせてコンテンツを先読みしてコンテンツを継ぎ足してる
    • どんどん継ぎ足してると、コンテンツの総量がとても大きくなる(画像、テキスト)
    • 現時点の実装ではjsでスクロールを実装してる
      • 他の実装では速度でない
      • 他の実装では色々問題がある
  • 実装でぶつかってる問題を箇条書きで
    • フレームレートが安定しない
    • UIスレッドに遅延(もっさりする)
    • コンテンツサイズとか画像の数が増えるとGPUバッファが使い尽くししまう
    • 慣性スクロールのネイティブ実装がosによってバラバラ
    • JSで実装すると、あるosではいいが、他のosでひどいということがない
  • 必要なものを箇条書きで
    • スクロールは高速かつ滑らか
    • ユーザのengagementには必須
    • ユーザが読み込み済みコンテンツの下端に近づくと、定義済のイベントを発行され、ンテンツが先読みされ、位置が算出され、継ぎ足される
    • 滑らかなスクロールを殺すことなく、スクロール中も新規に読み込まれたコンテンツが継ぎ足される
    • i/o処理や計算をバックグラウンドで実行できること
      • 滑らかなスクロールを殺さないため
    • たくさんコンテンツがあっても滑らかなスクロールを維持できること
      • 画像が沢山あっても維持できること
  • こんなAPIが欲しい
    • クロスブラウザな、慣性スクロールをコントロールできる標準化されたAPI
    • ユーザがスクロールしてる時も「onscroll」イベントが発火できるようにする
    • フラグメント化してるコンテンツを構造化された形でクローニングできること
      • ワーカースレッドでフラグメントからドキュメントを組み立てる
      • 組み立て終わったらメインスレッドに戻してドキュメントを継ぎ足す

GPU

  • 現状ブラックボックス状態で、わずかなハックが使えるだけ
  • エンジニアはハックに頼ってハードウェアアクセラレーションを使ってる状況
  • GPUバッファのサイズはデバイスを消費してるコンテンツサイズに相対的?
    • だとすればの話だが
    • GPUの管理がブラウザに委ねられた状態が相当な間理にかなった形で続くことになる
  • とはいえGPUにアクセスできるAPIを提供する点についてはpro/con色々ある話

その他足りないもの箇条書きで

  • タッチイベントのトラッキングの精度向上。特にandroid
  • よりスムーズなアニメーション。常に重要
  • キャッシュ性能の向上
  • app cacheは実用レベルにない。使わないことにした
    • MoPad: appcache-london
    • (補足)
        • FT labがホストになって2012.8.14開催されたmeetupのログ
        • FT、Economist、facebookgoogle、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も参加