A-6 4年に渡るLINE Androidアプリの進化とチャレンジ

セッション名：A-6 4年に渡るLINE Androidアプリの進化とチャレンジ
登壇者：Tsutomu.H氏

以下、メモと所感。
【メモ】

2011.4開発　2ヶ月でリリース

当時は情報量が少なく、開発環境も整っていなかった

当時は時間もなく、iPhone向けデザインをAndroidにそのまま適用したが

Androidは画面サイズがマチマチで、デザインが適用できないことがあった

今はGoogleのデザインガイドラインをデザイナーが読んで、デザインを作成している

現在はマテリアルデザインへの適用を実施中

 

利用者が増えることによって、クラッシュレポートが増えてきた

クラッシュレポートの対応

・リバースエンジニアリング対策でソースを難読化しているが、スタックトレースも難読化されてしまっていた

・クラス名などで検索したい

・バグトラッキングシステムと連動したい

・任意の場所でレポートしたい　→　クラッシュしないとレポートが送られないので原因がわからない

↓

現在

Crash Reporting Systemを開発し、アプリ内にCrash Report SDKを組み込んでおり、

任意のタイミングでクラッシュログを送るようにしている

 




 

■機能ごとにチーム（Planer, Designer, Developer）を分けている

gitでサブモジュールを分け、ソースも分離し、コミュニケーションを減らしている

→　素早く進行できる反面、同じようなクラスが作成され、チーム間で知識が共有されなくなった

→　現在はスピードよりも品質を重視し、チームを統合。機能ごとにチームを組み直し、リリースをすると解散、以下繰り返し

 

 

■通信方法の改善

Gatewayの導入。GateWayへのコネクションだけ維持すればよくなり、パフォーマンスが改善した。

HTTPパイプラインを導入したが、1つでも遅いリクエストがあると、その後の処理が遅くなってしまう。

→ SPDYの導入。個々のリクエストが独立している。







 

■様々な端末に対する最適化

①特殊な端末に対する最適化

Google Play Serviceが利用できない

らくらくホンなど、メーカー独自の端末はGoogle Play Serviceが使えないものがある

→　位置情報やPUSH通知が利用できない

自社で開発したPUSHサービスを利用

GCMだけでなく、独自開発のPUSHサービスを状況に応じて切り替えている

GCMが使える場合はバッテリー消費を抑えるため、自社PUSHサービスのリクエストはしない


 

②低スペック端末に対する最適化

CPUの性能を確認し、性能が低い場合にはフェードインなどのアニメーションを利用しない

メモリが少ない端末

→　メモリキャッシュの容量を減らす、画像の解像度を落とす

③バッテリー残量に対する最適化

バッテリーを多く消費する処理は、バッテリー残量を見て、

充電中でない場合には処理をさせないようにしている

現在

開発メンバー：22名

ソースコード：437000行

コミット：週200回コミット

これから

新しい機能追加や改善をしながら、リファクタリングをしていく
 
 

【所感】
Androidアプリ開発のこれまでの歩みについての説明でした。
驚いたのは、PUSH通知の利用できない特殊な端末では自前のPUSHサービスを利用しているということ。
アプリの起動時にGCMが使えるかどうかをチェックし、GCMが使えない場合には自前PUSHサービスに切り替えることでバッテリーの消耗を抑えているそうです。
あらゆる端末をカバーしなければならないサービス特有の対応方法ですね。