コード共通化の取り組み_headphones_connect

Transcript

1. Sony | Headphones Connect コード共通化の取り組み ソニー株式会社
2. Copyright 2024 Sony Corporation 2 自己紹介 • 氏名：福田真哉 • 所属：ソニー株式会社 ソフトウェアエンジニア • 経歴：組み込みソフト開発・Android/iOS アプリ開発 • 現在：Sony | Headphones Connect の開発に従事
3. Copyright 2024 Sony Corporation 3 Sony | Headphones Connect (HPC) について • ヘッドホンのコントロール（機器設定など） • ヘッドホンの利用状況（時間・楽曲など）の可視化 • センシングによるノイズキャンセリングの自動化 • ダウンロード数：5000万以上
4. Copyright 2024 Sony Corporation 4 システム概要（ヘッドホンのコントロール） Sony製ヘッドホン 通信路 Android: Bluetooth Classic SPP (Serial Port Profile) iOS: iAP (iPod Accessories Protocol) 設定変更指示 (例: ノイズキャンセリングをOFFに変更) 状態変更通知 (例: ノイズキャンセリングがOFFに変化した) 01010111 11010111 SPP, iAP 上のシリアル通信でヘッドホンを制御 制御メッセージは独自バイナリフォーマット 制御メッセージは独自バイナリーフォマット (* 兄弟アプリの資産を流用. JSON や Protocol Buffers ではない.) Headphones Connect (Android/iOS アプリ)
5. Copyright 2024 Sony Corporation 5 課題 • Android, iOS それぞれ実装していた • 不具合がそれぞれの実装で発生し、対応工数が増大していた 開発速度・品質を向上させるため、 Android / iOS コード共通化の検討を開始 App Logic UI/View 通信制御 App Logic UI/View 通信制御 Android iOS
6. Copyright 2024 Sony Corporation 6 技術選定のポイント 1 OSごとの最新UI表現に追従したいか？ • OSごとの最新UI表現に追従したい場合は、UI実装の共通化をしない方が良い • UI の変化は激しいため、柔軟に追従できるようにしたい • Headphones Connect では、「OS に合わせたUI表現とすることで、普段使いの アプリと同じ使い勝手にしたい」という方針がある • 選定する技術で必要十分なUI表現できる場合、UI実装の共通化が可能 • UI実装を共通化すれば、シングルコードベースにできるメリットがある 「UI実装の共通化はしない」を選択 OSごとの最新UI表現に追従できるようにするため
7. Copyright 2024 Sony Corporation 7 技術選定のポイント 2 各Platform の最新APIを簡単に使うことができるか？ • Platform 固有APIを簡単に呼び出すことができるか？ • ラッパー・アダプターを実装する必要があるか？ • OSS等のプライグインの対応を待つ必要があるか？ • OSがバージョンアップされた時に、最新APIへの追従が早いか？追従不要か？ 「最新のAPIを簡単に使える」ことを重視 ラッパー実装やプラグイン対応を待たず、最新APIを使いたい
8. Copyright 2024 Sony Corporation 8 技術選定のポイント 3 将来性・メンテナンス状況。廃れた時にどうするか？ • UIの流行・共通化技術の変化は早いため重要な観点 • 第三の言語 (Dart, C#, JavaScript 等)で実装されている場合、Android も iOS も 新規に実装する必要がある • Platform ネイティブな言語 (Kotlin,Java,Swift) で実装されていれば、もう一方だけを 新規に実装すれば良い 「Platform ネイティブな言語で実装できる」を重視
9. Copyright 2024 Sony Corporation 9 技術選定のポイント 4 Android/iOSアプリ開発以外の知識が必要か？ • 第三の言語で実装されている場合、その言語の習得が必要 • 以下の場合、第三の言語を使う技術の採用も可能 • 既存の資産がある • 他の環境（サーバーサイド）との共通化が可能 • チームメンバーがその言語を使うことができる 「Platform ネイティブな言語で実装できる」を重視 第三の言語を選択するメリットがないため（Web との共通化などはない）
10. Copyright 2024 Sony Corporation 10 技術選定のポイント 5 ゼロから作るか？部分的に置き換えていくか？ • すでに運用中のアプリであれば、部分的に書き換えられる必要がある • 新規プロジェクトであれば、ゼロから作ることができる 「部分的に置き換えることができる」を選択 すでに運用中のアプリであるため
11. Copyright 2024 Sony Corporation 11 技術比較 技術分類 UI実装共通化 Platform API 利用 アプリ開発以外の 追加知識 部分適用 ネイティブ言語系 (KMP, J2ObjC) × 対象外 なし ◦ C++ × 対象外 C++, JNI ◦ Flutter ◦ ラッパー Dart Web 系 (React Native 等) ◦ ラッパー Web, JavaScript Game Engine 系 ◦ ラッパー C#, C++, etc... 「ネイティブ言語系」を採用 OSごとのUI表現への追従・Platform API 利用の簡便性をとるため
12. Copyright 2024 Sony Corporation 12 共通化の工夫 • Android / iOS 依存を切り離す設計・抽象化を行う 共通ロジック UI (Android) UI (iOS) その他API (Android) その他API (iOS) 通信 (Android) 通信 (iOS) Activity Fragment ViewController Bluetooth Handler SharedPreference GCD UserDefaults EAAccessory Platform 依存部分 Platform 非依存部分
13. Copyright 2024 Sony Corporation 13 ステップ 1: 通信制御実装の共通化 App Logic UI/View 通信制御 Android iOS App Logic UI/View 通信制御 Before After App Logic UI/View 通信制御 App Logic UI/View Android iOS
14. Copyright 2024 Sony Corporation 14 ステップ 1: 通信制御実装の共通化 Platform 依存部分を抽象化し、通信制御実装を共通化 BluetoothAdapter BluetoothServerSocket BluetoothDevice BluetoothSocket InputStream OutputStream byte[] read write EAAccessoryManager EAAccessory EASession NSInputStream NSOutputStream (uint8_t *) data read write Kotlin/Java • Platform依存のBluetooth通信部分を、Byte 配列の読み書きに抽象化 • ヘッドホン制御メッセージバイナリ生成、メッセージシーケンス制御を Kotlin/Java で実装しiOS側で利用 Android iOS Platform 依存
15. Copyright 2024 Sony Corporation 15 ステップ 1: 通信制御実装の共通化（関連する取り組み） App Logic UI/View 通信制御 App Logic UI/View Headphones Connect (Android) Headphones Connect (iOS) Test App 接続テストアプリ(Android) Sony製ヘッドホン • 切り出した通信制御実装を用いて、独立した接続テストアプリを開発（1クリックの自動Unit Test） • アプリのUIではわからない、通信プロトコルレベルのテストが可能になった • ヘッドホンとの結合テストを早期実施可能になった。UI完成まで待たなくて良い。 接続テストアプリにより早期結合テストが可能になり、開発生産性を向上
16. Copyright 2024 Sony Corporation 16 ステップ 2: UI ロジック, App ロジックの共通化 Android iOS App Logic UI/View 通信制御 Before After App Logic UI/View Android iOS View (Passive View) Native implementation 通信制御 View (Passive View) Native implementation Presenter Model MVP 設計を適用し、UI ロジック、App ロジックを共通化 Passive View にすることでView のテストを不要とした
17. Copyright 2024 Sony Corporation 17 効果 • コード量削減 • iOS のコードを55%削減 • 不具合減少 • 共通化した箇所について、Android/iOS バラバラに不具合発生することは無くなった • 接続テストアプリにより、結合問題の早期発見・減少に繋がった • Unit Test • 共通部分がAndroid 非依存なので、JUnit によるテストが書きやすくなった • UIの振る舞いについてテスト可能になった • Presenter をAndroid 非依存にすることで JUnit でテスト可能
18. Copyright 2024 Sony Corporation 18 課題 • 共通化対象の見極め • UIに近いPresenter まで共通化対象にしたことのデメリットがあった • MVPであるため、Jetpack Compose, Swift UI などの適用が難しい • 最新技術を使いやすくするために、UI共通化を見送ったはずだったが、、 • ネイティブアプリのライフサイクルとの相性が悪い • Presenter の show() と、onResume()/viewWillAppear() の競合 • 共通設計の維持 • 設計スキルが必要なため、機能拡張・変更時に維持し続けることができるか • 大人数開発では設計をシンプルに保つことが重要
19. Copyright 2024 Sony Corporation 19 まとめ • 共通化技術選定のポイントを紹介した • OSごとの最新UI 表現に追従したいか？ • Platform APIを簡単に利用できるか？ • 将来性・メンテナンス状況・廃れた時にどうするか？ • Android/iOS アプリ開発以外の知識が必要か？ • 部分置き換え可能か？ • Sony | Headphones Connect でのコード共通化事例を紹介した • ネイティブ言語系技術を採用し、Platform 依存部分を抽象化する設計 • 通信制御実装とUIロジック, Appロジックの共通化を行なった • 設計改善・コード量削減・不具合減少を実現、さらにUnit Test が書きやすくなった • 接続テストアプリにより早期結合テストが可能になり、開発生産性が向上した • コード共通化は、設計スキルが必要 • 共通設計適用範囲の見極め • 共通設計の維持