LINE DEVELOPER_DAY の参加レポート第2弾
LINE DEVELOPER DAY_2015 Tokyo
4年に渡る LINE Android アプリの進化とチャレンジ
5つのフェーズに分けて、その時に苦労したことことや立ちふさがった問題を、
どう解決してきたか、現在はどうなっているかという内容でした
フェーズ1 2011/06リリース直前直後
背景
- 2011/04開発開始
- スマートフォンが人気がでつつある時期
- 開発開始から約1ヶ月半でリリース
- この時の開発スピードに秘訣なし 時間で殴る
苦労点,問題点
現在
- デザイナーもアプリ専門になり知識を深めデザイナーの担当を範囲拡大
- ナインパッチやデザインガイドの理解もデザイナーを中心に行うことでスムーズにいっている
フェーズ2 2011/10伸びてきたことによるレポート対応
背景
- リリースから半年で100万DL
- ユーザー増加も含めCrashReportも急増
- GooglePlayのツールでCrashReportをやっていた
問題点
- 難読化されたスタックトレースをなんとかしたい
- クラス名で検索したい
- 親クラスにバグが有るとすると、それを解決したらそれが原因のレポートを全部消したい
- BugTrackingSystemがほしい
githubのissueもCrashReportも消さないといけない。手間が多い。
- 任意の場所でレポートしたい
- 暫定対応としてクラッシュ回避をすることもあるのだが、そうするとレポートがでてこなくなる
- 根本解決もしたいので原因しらべたい！
現在
- 内製しました
- SDKと内製レポートシステム(ここで難読化解除も行う)、
- ワンクリックでBugTrackingSystem連動でJiraにチケット発行
- 検索機能も豊富！
フェーズ3 2012様々な機能をスピードを感を保ってリリースしたい
背景と最初の課題
- 様々な機能が増え、進化した年
- 1つ1つの機能はそれだけでサービスにしてもいいくらいに大きい
- でもスピードがほしい！
- あたりまえだけど人数を増やしただけではダメだよね
ここまでは、
- 開発、プランナー、デザインで協力し、細かい仕様はその場で相談して解決してた
- ただこれだと人が増えるとコミュニケーションコストが増加
解決
- 機能ごとにチームをわけることに、だが同じアプリなのでソースは一緒
- でもフローの共有もやめたい、コミュニケーションコストは最小限にしたい
- サブモジュールで管理
- 各チームは各サブモジュールだけを管理する
- 共通サブモジュールとリリースのときだけコミュニケーションをとるように
ここでさらなる問題が
早さは確保できたけど、
- 同じようなクラスが作成される
- チーム間で知識が共有されない
現在
- 今はスピードより品質が大事
- 全体としては大きなチームにした
- だが修正や機能追加ごとに小さなチームをつくり、1つの改修が終わったら解散
- これにより大きなチームで共通部分は管理され、解散のあとにチームに戻るので知識が自然に共有されていく
フェーズ4 2013通信で問題がでてきた
- 機能が増えたので接続するServerが増えてきた
- それぞれのServerにコネクションを張らないといけない
- 再利用はある程度行っていたが・・・
- さらにHTTP通信だったので、終わるまで待たないといけない->レスポンスを待つのは遅すぎる
HTTPの解決はHTTPパイプラインでよさそう・・・？
- HTTPパイプラインは順序を保たないといけない仕様のため、途中が遅いと以降すべてが引っ張られる。
- なのでこれでは根本解決にならず
- SPDYを採用
- 順序を無視できるようになり、
- 頻度の低いAPIに対してはとてもおおきな改善になりました
フェーズ5 2014様々な端末に対応する
特殊な端末に対する最適化
解決策
低スペック最適化
- 端末料金を抑えるために低スペック端末は存在し、需要も多いので無視できない
細かい対策
- cpuの性能を確認し、アニメショーンの有無を切り替え
- メモリキャッシュの容量や解像度も考慮し最適化
- スムーズにするためにキャッシュたくさん保存して、OutOfMemoryErrorでクラッシュじゃあかん
- バッテリー残量に対する最適化
- 同期処理は多くの通信が行われるので、バッテリーを消費してしまう
- 残量や充電状態をみて同期するかどうか決めている
現状のチームについて
- 開発メンバー22名
- ソースコード437000行
- 200コミット/week
今後行っていきたいこと
改善や機能追加を維持しつつ、リファクタリングを！
