$30 off During Our Annual Pro Sale. View Details »

Mirrativ-android-efforts

morizooo
April 25, 2019

 Mirrativ-android-efforts

morizooo

April 25, 2019
Tweet

More Decks by morizooo

Other Decks in Programming

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