UI設計の共通化で機能差異を埋めるモバイルアプリ開発

ABEMAではAndroid・iOSで同様の機能をモバイルアプリとしてそれぞれで提供しています。

以前はそれぞれでUI設計が異なっており、同様の機能を提供する際に開発期間が乖離することがあり機能差異が生まれやすい状況でした。

これまでは提供時期がずれることを許容してサービス開発を進めていましたが、UI/UX刷新の大規模なプロジェクトを進めるにあたって、AndroidとiOSで大きく提供時期が異なる見積もりになってしまい、そのスケジュールで進めるとコンテンツ訴求などが並行運用しなければならず事業的に許容できないものでした。

そのため、このUI/UX刷新のプロジェクトの中で、このプロジェクトのリリース後でもAndroid・iOSの機能差異が発生しづらい開発基盤を確立するという目標を掲げました。

このセッションでは、Android・iOSそれぞれにおける機能差異に繋がる課題に対してどのような解決を図ったか、またなぜその解決策を取ったのかを将来の展望を交えてご紹介します。

https://developer.abema.io/2021/sessions/rcpdBajCyK/?utm_medium=social&utm_source=slideshare

Transcript

2. 井原 岳志 • 2018年に株式会社サイバーエージェント中途入社 • 株式会社AbemaTV Native Team所属 • iOSチームのテックリード 木永 風児 • 2020年に株式会社サイバーエージェント中途入社 • 株式会社AbemaTV Native Team所属 • Androidチームのテックリード
3. 井原 岳志 • 2018年に株式会社サイバーエージェント中途入社 • 株式会社AbemaTV Native Team所属 • iOSチームのテックリード 木永 風児 • 2020年に株式会社サイバーエージェント中途入社 • 株式会社AbemaTV Native Team所属 • Androidチームのテックリード
4. モバイルアプリのUI / UX刷新
5. たくさんの施策が同時にリリース • テレビ機能刷新 • テレビプレビュートリミング • ボトムナビゲーション対応 • 特集エリア • 起動時表示物整理 • 作品プレビュー • チャンネル並べ替え • 1歳刻みのデモグラアンケート • 新聞型番組表 • ホーム最適化画面 • 複数選択ジャンルアンケート • ホームチュートリアル • ランディングチャンネル • Welcome画面 • マイページ画面の導線変更 • 視聴形態ラベル刷新 • タブレット最適化 • プレミアムタブ • ジャンル/ストアトップリデザイン • SLI/SLO計測 • ...
7. ABEMAにおけるモバイルアプリ • Android / iOSアプリを提供 ◦ 同一なデザインや機能を提供 • 開発言語 ◦ Android) Kotlin ◦ iOS) Swift • 開発体制 ◦ 2016年) Android / iOSチーム ◦ 2019年) Nativeチームに統合
8. モバイルアプリの機能差異 • 大小関わらず機能差異がいくつか存在 ◦ タブレットデザインの対応可否 ◦ キャスト機能の対応有無 ◦ プレイヤー再生画面のスワイプアクションの有無 ◦ 参照するデータ元の差異 • 機能差異を埋める取り組み ◦ 各エンジニアのオーナーシップ ◦ 改善Week ※現在は廃止 サブ スク 登録 コイ ン 購入 PPV TVO D 投げ 銭 ブラ ンド サー ベイ スポ ン サー ド 広告 Ch 作品 プレ ビュ ー 購 入 視 聴 マルチ アング ル Mobile App iPhone/ iPad ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ ◯ Android ◯ ◯ ◯ ◯ ◯ ◯ ◯ ☓ ☓ ◯ 施策におけるモバイルアプリ間差異
9. 機能差異がもたらす弊害 • 機能が出揃うまでコンテンツの多重運用が必要 • 互換性担保のための仕様やデザインの考慮が複雑になる • 既存の機能差異が影響して新機能の開発工数が異なる
10. 大規模プロジェクトで表面化 • UI / UX刷新プロジェクトの工数が大きく異なる ◦ Android) 10ヶ月 ◦ iOS) 6ヶ月
11. 大規模プロジェクトへ改善の盛り込み • リリース後の機能開発で工数が近づくような改善 ◦ プロジェクトのリリースを最終目標としない ◦ 共通 / プラットフォーム個別の改善をそれぞれ検討 • マイルストーンに工数として組み込む ◦ オーナーシップに依存させない
12. 共通の改善事例の紹介
13. 共通の改善事例 1. 機能の棚卸し 2. UIコンポーネントの共通化 3. 起動シーケンスの共通化 4. Imp発火条件の共通化
14. 共通の改善事例① 機能の棚卸し • ユーザー体験をシンプルにする • 運用負荷の高い機能やUI / UX刷新によって負債化しやすい機能を精査
15. 共通の改善事例② UIコンポーネント • デザインと実装のコンポーネント粒度を揃える ◦ 変更時の考慮漏れや追加開発のリスクが縮小
16. 共通の改善事例③ 起動シーケンス • 刷新プロジェクト後も起動パフォーマンスを担保できるシーケンスを実現 ◦ エラーハンドリングの方針を決めて、障害時などの対応アクションも決定 • 他デバイス開発時にも流用が可能な状態になった
17. 共通の改善事例④ Imp発火条件の共通化 • ユーザーが特定の画面に遷移したと判定する条件を再定義 ◦ 画面回転やバックフォア、スリープ状態、画面遷移形式などユーザー操作観点で整理 ◦ Android / iOSのライフサイクル挙動の差異を考慮に含め、実装に落とし込む • ユーザーが特定のビューやモジュールを見たと判定する条件を再定義 ◦ Android / iOSで発火・再発火の条件を揃える ◦ 画面固有の対応パターンを極力作らない汎用的なポリシーにする
18. iOSの改善事例
19. iOSの改善事例① アニメーション • ProtopieのInteraction Recipesを介したデザイナーとのコミュニケーション ◦ 複雑なアニメーション開発フローの確立 ◦ 変化量や時系列などがデザイナーが意図した通りに実装 ◦ iOS側で先行して検証実施
21. iOSの改善事例② ミニアプリ • 新設されるホーム画面をミニアプリ化して単体でのアプリ起動を実現 ◦ デザインやアニメーションの検証を高速化 ◦ 本体側にgit submoduleでコード注入して組み込んでビルド可能 ◦ クラス名やView階層をNativeチーム・デザイナーで議論 • リリース時にはミニアプリ化を止めて本体側に完全移行 ◦ 現状のアーキテクチャでは優先順位が低いため
22. 現状のアーキテクチャ
23. 現状のアーキテクチャ + ミニアプリ
24. Androidの改善事例
25. 井原 岳志 • 2018年に株式会社サイバーエージェント中途入社 • 株式会社AbemaTV Native Team所属 • iOSチームのテックリード 木永 風児 • 2020年に株式会社サイバーエージェント中途入社 • 株式会社AbemaTV Native Team所属 • Androidチームのテックリード
26. Androidの改善事例 NavigationComponent 🤝 SingleActivity
27. これまでのABEMA Android • 1画面につき、1つのActivity • ドロワーメニュー経由の画面遷移 • 継承(extends)による共通処理 • オリジナルなDagger Component ◦ 画面回転後も生存するScreenScope ◦ ViewPager配下のPageScope
28. これまでのABEMA Android • 1画面につき、1つのActivity • ドロワーメニュー経由の画面遷移 • 継承(extends)による共通処理 • オリジナルなDagger Component ◦ 画面回転後も生存するScreenScope ◦ ViewPager配下のPageScope
29. これからのABEMA Android • 1画面につき、1つのFragment • ボトムナビゲーション経由の画面遷移 • 委譲による共通処理 • Hiltを使用したDagger Component
30. なぜ変更する必要があったか Androidの改善事例
31. 1画面につき、1つのFragment • 下タブの実現に伴い、NavigationComponentを採用する場合はFragment化がマ スト要件 ◦ iPadはすでに下タブ化されており、機能差異の要因となっていた • PictureinPictureやミニプレイヤーなど将来的な可能性を見据える
32. ボトムナビゲーション経由の画面遷移 • よりシームレスな回遊体験をユーザーに提供する ◦ Navigation2.4.0とFragment1.4.0でMultiple back stacksにも対応👏 • navigation-composeを使ったJetpackCompose化を見据える https://medium.com/androiddevelopers/multiple-back-stacks-b714d974f134
33. ボトムナビゲーション経由の画面遷移 • よりシームレスな回遊体験をユーザーに提供する ◦ Navigation2.4.0とFragment1.4.0でMultiple back stacksにも対応👏 • navigation-composeを使ったJetpackCompose化を見据える https://medium.com/androiddevelopers/multiple-back-stacks-b714d974f134
34. 委譲による共通処理 • Activityの共通処理もFragment移行の対象になる • 画面ごとの処理を持ちやすくなり、要件に合わせたカスタマイズが容易に • テストの書きやすさが向上
35. Hiltを使用したDagger Component • 新しく画面を作るたびに依存関係の注入を手作業で行う必要があった • 複雑かつ大規模な依存関係により、改修が困難となり開発効率が低下していた ◦ ビルドエラーが頻発 ◦ 依存関係ツリーの知識が属人化 ◦ 新規参入者の学習コスト過多 https://developer.android.com/training/dependency-injection/hilt-android
36. これからのABEMA Android • 1画面につき、1つのFragment • ボトムナビゲーション経由の画面遷移 • 委譲による共通処理 • Hiltを使用したDagger Component 再掲
37. まとめ
38. まとめ • 今後の機能差異を埋める開発フロー・仕組みを検証・導入できた ◦ UIコンポーネントの見直し ◦ 起動シーケンスの見直し ◦ ログ定義 ◦ ProtopieのInteraction Recipesを活用したアニメーション実装 ◦ 開発時のミニアプリ活用 ◦ NavigationComponent 🤝 SingleActivity • 将来の展望 ◦ マルチプラットフォームの推進 ◦ 宣言的UI化 (SwiftUI / Jetpackcompose)
39. 関連セッション Multiplatform Engineering • UI設計以外でも共通化に取り組んでいます ◦ 詳しい内容は、この後のセッションにて