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

以下、メモと所感。

【メモ】

2011.4開発 2ヶ月でリリース

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

 

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

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

 

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

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


IMG_1649
 

 

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

 

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

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

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

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

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

現在

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

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

 
IMG_1651IMG_1652
IMG_1653
IMG_1654

 

 

機能ごとにチーム(Planer, Designer, Developer)を分けている

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

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

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

 
IMG_1655
 

 

通信方法の改善

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

 

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

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

IMG_1656
IMG_1657
IMG_1658
IMG_1659
IMG_1660
IMG_1661
 

 

 

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

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

Google Play Serviceが利用できない

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

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

 

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

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

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

IMG_1662
 

 

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

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

 

メモリが少ない端末

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

 

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

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

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

 

 

現在

開発メンバー:22名

ソースコード:437000行

コミット:週200回コミット

 

これから

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

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