Mirrativ-android-efforts

Transcript

1. Androidアプリの取り組み
   2019.04.25 morizooo
   突撃隣のアーキテクチャ
   © 2019 Mirrativ, Inc.
   

   View Slide

2. ●Profile
   ●morizooo(@morizo_999)
   ●ミラティブAndroid担当(2018/2〜)
   ●マイブーム:b-monster
   

   View Slide

3. Mirrativについて
   2.タイトル等設定 3.配信開始
   1.起動
   Mirrativスマホ1台だけでゲーム実況/ライブ配信を可能にする
   コミュニケーションサービス
   

   View Slide

4. サービスコンセプト＝友達の家でドラクエやってる感じ
   ゲームを中心に置いた「コミュニケーション空間」
   

   View Slide

5. 99
   ● 5年目アプリの現状
   ● 課題
   ● 取り組んでいること
   今日話すこと
   

   View Slide

6. 目次
   99
   アプリの現状
   

   View Slide

7. 99
   Android Gradle Plugin 3.4.0
   targetSdkVersion 28
   minSdkVersion 16(5月に21に上げる)
   support library version 28.0.3 (AndroidX)
   言語: Java 8, Kotlin 1.3.30
   主要ライブラリ: Koin, Glide, Retrofit, Gson
   開発環境
   

   View Slide

8. 99
   アーキテクチャ
   Activity/Fragment
   API Client
   Response
   (POJO)
   CustomView
   (一部だけ)
   ● いわゆるM-VC
   

   View Slide

9. 99
   ACTIVITY/FRAGMENT
   Activity/Fragment
   API Client
   Response
   (POJO)
   CustomView
   (一部だけ)
   ● ApiClientを呼び出し結果を
   Viewに表示
   ● プレゼンテーションロジックを持
   つ
   ● View,Controllerの責務を持つ
   (境目が曖昧)
   

   View Slide

10. 99
    CUSTOMVIEW
    Activity/Fragment
    API Client
    Response
    (POJO)
    CustomView
    (一部だけ)
    ● Viewのコンポーネントとして切
    り出された物
    ● Viewとしての描画の責務を持
    つ
    

    View Slide

11. 99
    API CLIENT
    Activity/Fragment
    API Client
    Response
    (POJO)
    CustomView
    (一部だけ)
    ● サーバーに対して問い合わせ
    行いResponseを取得
    ● Viewに特化したPOJOを返す
    

    View Slide

12. 99
    feature配下に機能単位にパッケージを切ってUIを配置
    → 多数の責務を持ったり、複数のパッケージに依存していたりカオス化...
    パッケージ構造
    

    View Slide

13. 目次
    99
    課題
    

    View Slide

14. 99
    ● どこに処理を書くか悩む
    ○ パッケージ構造が不明瞭
    ○ ViewとControllerがの境目が曖昧
    ● 厳密なルールがないのでActivityに処理が集中
    ○ 6000行のActivityが存在

    責務破綻
    

    View Slide

15. 99
    ● マッチョActivityを超える危険なやつら☠☠☠

    ○ 最凶のBaseクラス

    ■ 汎用的に作ろうとしてるせいでたらい回しにされる

    ■ 1000行のクラスを継承する

    ○ ロジックを持ったView

    ○ HelperがViewを持ってる

    ○ checkHogeというメソッドだが副作用がある

    責務破綻
    

    View Slide

16. 99
    ● 例:オーブ/ダイヤ問題
    ○ 開発当初はダイヤ、リリース前にオーブに変更
    ○ クライアント内ではオーブという名前
    ○ サーバー/分析ログではダイヤという名前のまま
    ○ 初見殺し爆誕
    → アンチパターンとして認識
    ユビキタス言語がぶれる
    

    View Slide

17. 目次
    99
    取り組み
    

    View Slide

18. 99
    O 開発に夢中
    KR 2019/4〜に洗い出した辛みを解消し、全platformで理想の状態を
    確立する
    全社的に開発体験を見直すときが来た
    ● 週に1日は開発体験向上活動を行う
    ● 各Platformでそれぞれ行われている
    

    View Slide

19. 99
    ● 最凶のActivityを倒す
    ● Android Architecture Componentsの導入
    ● 各層の責務の意識合わせ
    ● パッケージ構造の整理
    ● 不要なライブラリの撲滅
    ● Kotlin化する
    ANDROIDの取り組み内容
    

    View Slide

20. 99
    ● 一番でかいやつを倒せられればなんとかなるだろう理論
    ● 不要な機能の削除(複雑な仕様を減らす)
    ○ ユーザー利用状況踏まえて機能を削除
    ● Viewに分離
    ○ CustomViewで小さなコンポーネントにしていく
    ● Android Architecture Components の ViewModelの利用
    ○ 状態管理を改善する
    最凶のACTIVITYを倒す
    

    View Slide

21. 99
    ● 公式の設計に役立つライブラリ

    ● 推奨アーキテクチャとしてMVVMが紹介
    されている

    

    ANDROID ARCHITECTURE COMPONENTSの導入
    https://developer.android.com/jetpack/docs/guide
    

    View Slide

22. 99
    ● ViewModel, LiveDataを利用

    ○ Activity<->View間の状態管理が楽になる

    ○ View用のプロパティ置き場として活用(M-VCのまま)

    ANDROID ARCHITECTURE COMPONENTS
    

    View Slide

23. 99
    ANDROID ARCHITECTURE COMPONENTS利用例
    

    View Slide

24. 99
    ● Model
    ○ クライアントに特化したAPIをサーバーで返しているので、
    Responseは基本的にそのまま描画するだけ
    ○ iOS/Android/Webでビジネスロジックが各プラットフォームに
    書かれないようにする
    ○ クライアント上にしか存在しないモデルも勿論あるので、そち
    らはビジネスロジックを持つ
    各層の責務
    

    View Slide

25. 99
    ● View
    ○ Viewは情報を表示するだけ
    ○ プレゼンテーション/ビジネスロジックを持たない
    ○ Modelを直接参照してはだめ
    各層の責務
    

    View Slide

26. 99
    ● Controller
    ○ Modelを取得(APIリクエスト実行)
    ○ Viewに描画するデータを設定する
    ○ Viewのコールバックのハンドリング
    ○ 一旦Fatにして整理できたら分解する
    各層の責務
    

    View Slide

27. 99
    天下一パッケージ武道会の結果、機能単位から
    レイヤー単位にフラットに変える方針に
    パッケージ構造
    機能単位 レイヤー単位 機能+レイヤー
    ？
    将来的には機能毎に
    multimodule化する想定
    

    View Slide

28. 99
    ● Android Annotations
    ○ 昔は便利だったが今ではフレームワークの進化で不要
    ○ 学習コストを掛ける時間がもったいない
    ○ 既存コードの意図がわからず解読する時間がかかる
    ○ Staticになってテストし辛い部分もあるので消し去る
    → コードネーム:チョベリバ(死語)
    不要なライブラリの撲滅
    

    View Slide

29. 99
    ● Java<->Kotlin間の脳内コンテキストスイッチをなくす
    ● 親まで辿ってnullチェックするのがしんどい
    ● 仕様を理解する上で良いタスクになる
    ○ 副業で依頼しやすい
    ● Authorが自分になるので圧倒的当事者意識
    KOTLIN化
    

    View Slide

30. 99
    ● 現状は苦しいアーキテクチャになっている
    ● GUI/システムアーキテクチャを変更出来る段階ではない
    ○ 既存のコードを責務を意識して改善する
    ● 過去のコードに感謝し、スケールできるように改良を続けてい
    く
    ● 一緒に改善していく仲間を探しています！！！
    まとめ
    

    View Slide

31. 積極採用中！
    © 2019 Mirrativ, Inc.
    

    ◆体験入社/副業制度あります！

    改善が好きな方！！！一緒にやりませんか！！！

    

    View Slide