同期について本気出して考えてみた

191559bb496bcc6229a7921f64f833b6?s=47 Gazyu
January 15, 2015

 同期について本気出して考えてみた

191559bb496bcc6229a7921f64f833b6?s=128

Gazyu

January 15, 2015
Tweet

Transcript

  1. 2.

    About me twitter : @Gazyu Work : Sansan, Inc. Eight

    dev Hobby : Something make Android developer 2
  2. 5.

    データの同期 • そもそもローカルにデータとかなくていいよ派 ◦ メリット ▪ 仕組みが簡単 ▪ 基本的にユーザーは意識せず最新のデータを見れる ▪

    端末の容量を食わない ◦ デメリット ▪ 通信網内にいないと死ぬ ▪ 通信速度が遅いと死ぬ ▪ サーバが死んでると死ぬ 5
  3. 6.

    データの同期 • ローカルにキャッシュデータが有った方が良いよ派 ◦ メリット ▪ ローカルのデータはいつでも見れる ▪ データ表示スピードが早い ◦

    デメリット ▪ データを同期する機構が必要←意外と大変 ▪ 端末容量をくう ▪ 同期機構がちゃんとしてないとユーザークレーム 6
  4. 13.

    更新チェックタイミングの検討 ◦ 一定時間毎、いわゆるポーリング ▪ メリット:実装簡単 ▪ デメリット:遅延、簡単だけどちゃんとしないといけない、iOSは最近 までアプリが起動してない時同期できない ◦ サーバからのプッシュ通知(GCM,APNS)が来たら

    ▪ メリット:実装簡単、そこそこリアルタイム、端末電力消費 ▪ デメリット:激しく遅延することあり、そもそも信用性? ◦ サーバとセッションを開きっぱ(Websocket,Comet) ▪ メリット:リアルタイム ▪ デメリット:実装大変、サーバ負荷、端末電力消費高 ◦ ユーザー操作only(FB,twitter,タイムライン系?) ▪ メリット:実装簡単 ▪ デメリット:ユーザーからの理解 13
  5. 14.

    なんでポーリング? • ターゲット層の関係で自動で更新されるのは必須 • サービスの特性上そんなに更新は激しくない ◦ ≒同時に複数箇所での更新はあまりない • 設計時Push通知の信頼性が低かった ◦

    そもそもGCMじゃなくてC2DMとかの時代 • サーバの基本設計時に同期は考えられてなかった≒凝ったこと すると大規模改修が必要 • その時の工数が・・・(ゲフンゲフン 14
  6. 16.

    イベントデータに含まれるデータの検討 ◦ 更新があったという情報のみ ▪ メリット:実装簡単 ▪ デメリット:データ取得でサーバへのアクセス回数増 ◦ 更新されたデータの実体 ▪

    メリット:1回のアクセスで全部取れる ▪ デメリット:更新データ量、更新情報の生成コスト ◦ ローカルSQLiteDB用のSQL ▪ メリット:端末側楽 ▪ デメリット:端末側のDBの設計自由度がなくなる 16
  7. 19.

    余談SyncAdapterは? • SyncAdapter使ってる? ◦ Androidシステム標準の同期のための機構 ◦ なんか色々と便利にやってくれるっぽい ◦ Eightでは使ってない ▪

    設計時に情報が少なかった ▪ AccountManager+ContentProviderを使ってないシ ステムでどうなの? ▪ ユーザーに端末設定→アカウント→詳細→同期って わかりやすいのかな?? ▪ AlermManager+IntentServiceでダメな理由? • AlermMangerにもファニーなタイミングでの呼び出し有るよね 19